Subject: [dnsext] publishing policy attributes in the DNS

From: Joe Abley <[email-masked]>
Date: Mon, 1 Oct 2012 09:39:07 -0400

Hi all,

This (below) came up in the last-call comments for draft-ietf-dnsop-dnssec-dps-framework.

I seem to recall numerous ad-hoc suggestions for publishing policy attributes in the DNS, over the years. For example:

 - (for signed zones) what DPS revision corresponds to the way this zone was signed?
 - (for signed zones) what observed signature validity can be considered normal, as an aid to those who do automatic surveys of remaining signature validity and alarm on possible problems?
 - what second-level, third-level, etc subdomains are operated as part of this registry?

No doubt there are others. It seems to me that we might consider standardising some kind of POLICY RRtype (or multiple RRTypes) that could be used to signal these kinds of things. Such RRSets would be informational and optional, and would not change existing query processing rules.

(I realise that this working group is either already dead, or is being encouraged to die, but this mailing list seems like a reasonable venue to discuss the idea.)

Good idea? Bad idea?

Joe

Begin forwarded message:

> From: Fredrik Ljunggren <[email-masked]>
> Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-dps-framework-10.txt
> Date: 30 September 2012 13:10:14 EDT
> To: SM <[email-masked]>
> Cc: [email-masked]
> X-Mailer: Apple Mail (2.1486)
> 
> 
> On 2012-09-30, at 18:09, SM <[email-masked]> wrote:
> 
>> I found the following text from the Introduction Section more informative:
>> 
>> 'users who rely on signed responses from the DNS ("relying parties")
>>  to evaluate the strength and security of the DNSSEC chain of trust'
>> 
>> 'for scrutinizing the trustworthiness of the system'.
>> 
>> It doesn't make sense to say "Interested parties must stay informed" as the "advance notice of amendments" in Section 4.1.4 sounds like a minor detail.
>> 
>> I don't have any strong opinion about any of this.  The document is useful to me irrespective of what's in Section 7.
> 
> 
> I think it is a fair point to make from Russ, that there are (currently) no standardized in-band methods to determine under what policy a zone manager i currently operating. To find a DPS for a particular zone you may have too google it. I'm all for standardizing a DP/DPS pointer which can be published at the apex of the zone, but that's another RFC, in another WG, another day. First we need to build the concept of the DP/DPS.
> 
> Thanks for your support.
> 
> - Fredrik
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 01 Oct 2012 10:14:59 -0400

This topic is within scope of the mailing list, so discuss away.

Olafur

On 01/10/2012 09:39, Joe Abley wrote:
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Oct 2012 07:30:49 -0700

> No doubt there are others. It seems to me that we might consider standardising some kind of POLICY RRtype (or multiple RRTypes) that could be used to signal these kinds of things. Such RRSets would…

Then what value would they have? This is a serious question. Every time someone brings up the idea of "non-normative policy publication" in security WGs, there is an agreement that we could probably describe some policy well enough to publish it, and we could probably describe an interoperable transport for the policy. Then there is general agreement that it is worse than useless because no only does no one want it actionable (as you say above, "informational and optional, and would not change existing query processing rules"), but some implementations will ignore that and try to enforce some things anyway. So its security that breaks some things without helping any others.

> (I realise that this working group is either already dead, or is being encouraged to die, but this mailing list seems like a reasonable venue to discuss the idea.)

Bad idea unless the policy information is actionable in a way that everyone agrees would help security. If that is the case, an individual submission that is discussed on this list after the WG dies should be just fine.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Mon, 1 Oct 2012 10:43:31 -0400

On 2012-10-01, at 10:30, Paul Hoffman <[email-masked]> wrote:

>> Such RRSets would be informational and optional, and would not change existing query processing rules.
> 
> Then what value would they have? This is a serious question.

Your question (and following commentary) suggests that non-compulsory extensions to the DNS have no value, and also assumes that there needs to be a security benefit to this kind of idea for it to be worth pursuing.

There are other places where (for some TLDs) optional protocol elements can be made mandatory. There's also no shortage of examples of zone operators doing optional things because they are perceived to be useful, not because some RFC says they are mandatory.

The three examples I gave were measures that I think would have non-zero operational benefit, even if they were not universally deployed.

(I presume your comment related to the "informational and optional" aspect, and did not speak to the specific utility of the three examples.)

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 1 Oct 2012 11:07:58 -0400

Emphatically no hat.

> No doubt there are others. It seems to me that we might consider standardising some kind of POLICY RRtype (or multiple RRTypes) that could be used to signal these kinds of things. Such RRSets would…

For one proposal along these lines, see
http://tools.ietf.org/html/draft-sullivan-domain-origin-assert-01.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Oct 2012 10:02:46 -0700

> Your question (and following commentary) suggests that non-compulsory extensions to the DNS have no value, and also assumes that there needs to be a security benefit to this kind of idea for it to…

That is not what it is meant to suggest.

> There are other places where (for some TLDs) optional protocol elements can be made mandatory.

Please say more.

> There's also no shortage of examples of zone operators doing optional things because they are perceived to be useful, not because some RFC says they are mandatory.

And no shortage of examples where applications and DNS implementations misinterpret these "useful" things.

What is the operational benefit of this? Do you want a validating resolver to give different answers based on different values?

This is the type of policy that the websec WG has grappled with for years; they are getting close to being finished.

Andrew Sullivan has proposed this, but few people have commented on it.

> (I presume your comment related to the "informational and optional" aspect, and did not speak to the specific utility of the three examples.)

It speaks directly to the first one, and probably to the second. I think the third is important but don't understand why others don't.

I would say that "informational" is harmful unless you specify exactly how the information is used by someone who sees it.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Mon, 1 Oct 2012 13:10:25 -0400

>> There are other places where (for some TLDs) optional protocol elements can be made mandatory.

As an example, gTLDs are operated by registries under contract with ICANN. Those contracts can specify that particular protocol-optional elements are included in their published zones.

> And no shortage of examples where applications and DNS implementations misinterpret these "useful" things.

That's why it's great to have standards!

> What is the operational benefit of this? Do you want a validating resolver to give different answers based on different values?

Nope, I want operators to be able to locate the DPS that corresponds to a particular signed zone easily. Right now you have to fight with search engines, and there's no real guarantee that whatever you find is the policy used to sign that particular zone.

> I would say that "informational" is harmful unless you specify exactly how the information is used by someone who sees it.

Then let me clarify; the goal is to allow information to be published (hence "informational") in a structured and well-defined way, to minimise confusion and maximise the possibility that consumers of that information will understand its meaning and intended use.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 1 Oct 2012 10:25:08 -0700

> Nope, I want operators to be able to locate the DPS that corresponds to a particular signed zone easily. Right now you have to fight with search engines, and there's no real guarantee that whatever…

Ah! I have no problem with that. Sorry if I got twitchy about the security aspect; I've been in too many IETF meetings where the purpose of publishing a security policy was the eventual automatic processing of it.

> Then let me clarify; the goal is to allow information to be published (hence "informational") in a structured and well-defined way, to minimise confusion and maximise the possibility that consumers…

Works for me.

There's no reason why these shouldn't be individual submissions of new RRtypes.

--Paul Hoffman

---

From: SM <[email-masked]>
Date: Mon, 01 Oct 2012 10:30:18 -0700

At 10:10 01-10-2012, Joe Abley wrote:
>signed zone easily. Right now you have to fight with search engines, 
>and there's no real guarantee that whatever you find is the policy 
>used to sign that particular zone.

Yes.

>Then let me clarify; the goal is to allow information to be 
>published (hence "informational") in a structured and well-defined 
>way, to minimise confusion and maximise the possibility that 
>consumers of that information will understand its meaning and intended use.

The problem with "Informational" is that's it is not a "standard" 
[1].  To answer the question asked in a previous message, it's a good 
idea.  It would be quite an effort to move the idea forward as it has 
the word "policy" in it.

Regards,
-sm

1. I'll skip the long explanation.