Subject: Re: [keyassure] draft-ietf-dane-protocol-03.txt

From: Steve Schultze <[email-masked]>
Date: Fri, 11 Feb 2011 00:49:48 -0500

Sorry I missed this when you first posted. 

I feel that Matt's proposed language for Section 3 is clearer as to what is done in different scenarios:
http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html

For example, the current language in Section 3 does not make clear what is done in the case of no records or a DNSSEC response of "bogus" .  I like the way Matt's language clearly lays out all of the possible cases and the results.

The one issue with his language is that it assumes the client is doing DNSSEC validation, but our current language permits "a remote nameserver to which one has a secured channel of communication."  If we are permitting that, we may have to rephrase some of his specific references to DNSSEC result status' like "bogus" to be more generic.

On Jan 25, 2011, at 2:59 PM, Paul Hoffman wrote:
> Greetings again. There was not an open issue on how TLSA deals with non-key information in PKIX certificates, but Phill had brought up strong reservations and Steve Kent responded. There was then a longish thread on alternatives, but Jakob and I had never clarified the document. Thus, we put out -03 with some proposed wording that should make clear that the keys in certificate associations are trust anchors. The side effect of making that clear is that we could wipe out all the wishy-washy stuff from the old 3.1.
> 
> The diffs are at <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-03.txt>.
> 
> If folks are happy with this clarification, it will close some of the open issues that were spurred by the language in 3.1.
> 
> --Paul Hoffman
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Feb 2011 08:35:00 -0800

> http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html

It went into more scenarios, but I didn't see much agreement on the 
scenarios at the time, or since then.

> For example, the current language in Section 3 does not make clear
> what is done in the case of no records or a DNSSEC response of
> "bogus" .  I like the way Matt's language clearly lays out all of the
> possible cases and the results.

Laying out the possible cases is good, as long as we can agree with the 
results. For example, there was disagreement about what to do in the 
case of a bogus result; what he proposed at the time causes a new and 
easy-to-mount denial-of-service attack on TLS.

> The one issue with his language is that it assumes the client is
> doing DNSSEC validation, but our current language permits "a remote
> nameserver to which one has a secured channel of communication."  If
> we are permitting that, we may have to rephrase some of his specific
> references to DNSSEC result status' like "bogus" to be more generic.

There is more than that one issue, I believe.

If someone (you or Matt) want to suggest some wording as a change to the 
current draft, that would be helpful to maybe a new open issue. However, 
please consider splitting the wording into different parts, since the 
earlier wording had disagreement about different parts, and the WG might 
want to adopt some but not all of a proposal.