Subject: [dane] Comments on draft-ietf-dane-protocol-14

From: Bill Owens <[email-masked]>
Date: Thu, 26 Jan 2012 21:36:58 -0500

I've been trying to give the current draft a thorough reading, and I
confess to being confused in a few parts. I believe that my
inexperience with TLS and PKIX is showing, but that the draft itself
is making things worse ;) In particular, the use of the all-important
word 'certificate' seems to me to be inconsistent.

I think there is one use of the word, meaning the certificate
presented by the TLS server during the opening of the TLS connection;
that object is called by the following names:
'certificate' : 31 times
'server's certificate' : 4 times
'PKIX certificate' : 5 times
'end entity certificate' : 7 times
'certificate from TLS' : 1 time

It seems as though 'end entity certificate' is the correct terminology
from the PKIX standard but I'm not certain of that.

Likewise, the data included in the TLSA record are called:
'certificate association' : 15 times
'certificate for association' : 4 times
Occasionally it is referred to as simply a certificate, for example in
the first paragraph of section 1.2.

The document also talks about CA certificates and trust anchors, and I
believe that usage is consistent.

I can't say whether the language creates any ambiguity, since I don't
know enough about the intricacies of PKIX; since anyone actually
implementing this protocol would need to have such expertise, perhaps
there's no issue. However, a set of definitions near the beginning of
the document, and a more consistent use of the defined terms, would
make things a lot easier to follow.

There are a few other small changes that the authors might want to consider:

 - Section 1.2 says "This document does not specify how DNSSEC
validation occurs...", but then goes on to make such a suggestion in
Section 4.4, and leaves a placeholder for discussing last-hop issues
in the Appendix.

 - Section 4.1 refers to "the public key of such a certificate, that
the must be found in any of the PKIX validation chains" Should there
be something between "the" and "must", or is "the" a typo?

 - Section 4.4 talks about "how to match the identify given in a PKIX
certificate" - should that be "identity", or "identifier", or ?

 - Also in Section 4.4, the paragraph about clients is confusingly
written. I think that it means to say something like this:

    Clients that validate the DNSSEC signatures themselves MUST use
standard DNSSEC validation procedures. Clients that rely on another
entity to perform the DNSSEC signature validation MUST use a secure
transport (such as TSIG...) between themselves and the validator. Note
that it is not sufficient to use secure transport to a DNS resolver
that does not do DNSSEC signature validation.

 - The paragraph on SSL proxies in Section 8 ends with the statement
"Thus, such proxies might choose to aggressively block TLSA requests
and/or responses." I think that would be a downgrade attack, which is
prevented by authenticated denial of existence.

 - Minor wording: Appendix A.1.1 is missing "the" in the last sentence
("client builds the trust chain") and A.1.2.1 likewise in the first
sentence ("provides the most precise")

 Finally in the pseudocode, I believe that I can follow the processing
except for the appearance of the PKIX validation chain H in in the
usage=2 case. Wouldn't the chain consist only of R, which was provided
by the TLSA record? If not, how does the client obtain the rest of the
chain? On that point, is it meaningful to have usage=2 and selector=1,
and if so, how does the client obtain the certificate referred to by
the SubjectPublicKeyInfo in the TLSA record?

And I apologize if a similar but shorter message shows up on the list
at some point; I tried sending it twice from my usual email address
([email-masked]) but it did not appear to go through. I've yet to
hear back from the IETF mail support folks about what might be going
on.

Bill.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 27 Jan 2012 11:04:22 +0100

On Thu, Jan 26, 2012 at 09:36:58PM -0500,
 Bill Owens <[email-masked]> wrote 
 a message of 86 lines which said:

> The document also talks about CA certificates and trust anchors, and
> I believe that usage is consistent.

They are different things. A CA certificate has the CA bit set. A
trust anchor is a certificate which is used to start a validation
chain. You may have a CA certificate which is not a trust anchor
(because you don't trust that CA, for instance).

> Finally in the pseudocode, I believe that I can follow the
> processing except for the appearance of the PKIX validation chain H
> in in the usage=2 case. Wouldn't the chain consist only of R, which
> was provided by the TLSA record? If not, how does the client obtain
> the rest of the chain?

In the TLS negotation (several certificates can be sent by the server
and it is its responsability to include a complete chain).

> On that point, is it meaningful to have usage=2 and selector=1,

Same thing, I would say. RFC 5246, section 7.4.2 seems clear about it.

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 28 Jan 2012 21:39:38 +0100

> 'certificate from TLS' : 1 time

The word 'certificate' is used in different contexts, sometimes a certificate in general is described, sometimes the very cert from the TLS server. I'll try to make another pass - perhaps it will be clearer.

> the first paragraph of section 1.2.

I've cleaned this up, the field is now called "certificate association data" (as it can be either a cert or a hash-of-cert).

> Section 4.4, and leaves a placeholder for discussing last-hop issues

Yes, we need to revisit this sentence when write the appendix.

> be something between "the" and "must", or is "the" a typo?

Fixed.

> certificate" - should that be "identity", or "identifier", or ?

Fixed.

> that does not do DNSSEC signature validation.

Thanks.

> prevented by authenticated denial of existence.

We'll looking into this.

> sentence ("provides the most precise")

Fixed.

> the SubjectPublicKeyInfo in the TLSA record?

We'll looking into this separately.

Thanks you for all your comments,

	jakob