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

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 26 Jul 2011 13:36:47 -0400

Dear DANE,

On the way up to Quebec, I gave the current DANE protocol spec a pretty thorough read.  My comments are below.

--Richard

1.3. 
Exclusion part should be removed.  Probably want to link to
PKIX/TLS/DNS terminology, as in draft-ietf-dane-use-cases.

4. 
I would expect this section to be stronger, clearly defining the logic that the client follow to determine the validity of the assertion. Probably need more 2119 language to clearly specify behavior.

4.1., 4.2.
In 4.1 and 4.2, the distinction is made between type ref type 0 and nonzero. It would be more extensible to specify individually by ref type -- or else just make it a hash type field.

4.1. 
I'm concerned that only doing byte wise comparison could lead to malformed certs being accepted. Suggest requiring that cert be well formed, or at least noting that it must meet the requirements of TLS for certs, e.g. KeyCertSign bit being set.

4.2.
The use of the term "Trust Anchor" here is sloppy.  What you really want to say here is that a CA certificate matching the TLSA record MUST be in the certification path.  

4.3
I thought we had agreed not to do bare public keys? They are not in the use cases doc.

4.4. 
This section should be either a summary of previous sections, or the only normative
part.   It might be useful to provide some pseudocode for the client validation process.

4.4. 
The discussion of SAN here seems to intrude on the application layer. Maybe we want to say that TLSA can only be used when the expected service identifier is a domain name?  And even that should be said in the context of RFC 6125.

5. 
I disagree that this document addresses the cert lock and CA lock use cases. Both of those entail normal PKIX validation, which both certTypes in this document disable.  Of course, the RP can always make the decision, but it would be good to enable the domain owner to make a recommendation -- suggest adding a flag for this.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 Jul 2011 18:10:30 -0400 (EDT)

> I would expect this section to be stronger, clearly defining the logic that the client follow to determine the validity of the assertion. Probably need more 2119 language to clearly specify behavio…

Perhaps move up section 4.4 to here would satisfy your concern?

I agree that the reference type could be called a hash type field. But then Section 4.2 should not be
using it to change behaviour on the certificate bundle. I think if any behaviour of the certificate types
needs further directions, it should be a new certificate type, and not a side effect of the reference type.
Actually, I would probably rename "Certificate type" to "Reference type" and rename "reference type" to
"hash type". This also more cleanly allows non-certificate type extensions.

> I'm concerned that only doing byte wise comparison could lead to malformed certs being accepted. Suggest requiring that cert be well formed, or at least noting that it must meet the requirements of…

You could say "the first valid certificate offered by the TLS server", but then you have to qualify "valid", especially
that it might NOT mean [PKIX] validation.

Arguably, if the TLS connection did not get a "proper" certificate to validate, there is no point in looking
up or comparing the DNS record. How about:

 	Once a validly formed certificate type 1 (a certificate that identifies an end entity) is received from
 	the TLS server, it is matched [...]

> The use of the term "Trust Anchor" here is sloppy.  What you really want to say here is that a CA certificate matching the TLSA record MUST be in the certification path.

The entire paragraph is very hard to read. It seems to list 3 use cases:
   1) The TLSA record specifies the CA that signed the EE cert received in
      the certificate bundle from the TLS server
   2) The TLSA record specifies a CA that should treated as Trust Anchor for
      the certificate bundle received from the TLS Server.
   3) The TLSA record specifies a CA that should treated as Trust Anchor for
      any existing locally configured Trust Anchors, which should themselves
      lead to a validation path to the EE cert.

The last option actually scares me. I could use it to determine which locally configured
trust anchors your have. It could also be misused by putting (or forcing others to put)
a very large encompassing CA cert in there. Think of a nation state mandating such a
certificate....

The third case also mixes up local client policy. I don't think a TLSA
record should tell a client exactly when to use its preconfigured trust
anchors - the TLS client probably knows better (or has very specific
instructions) on when to use its locally configured trust anchors and for
what. I suggest removing case 3) and leave that to "local policy". Then
writing up the first two cases become somewhat easier.

> I thought we had agreed not to do bare public keys? They are not in the use cases doc.

Technically, this is not doing bare public keys, but identification of
a certificate based on a public key. Yes, it could also be used if/when
we have a TLS extension that allows us to suppress sending a [PKIX]
container with filler to be ignored. I don't think we need to make it
harder for such future possible extension (disclaimer: I wrote a draft for
such a TLS extension)

> 5.
> I disagree that this document addresses the cert lock and CA lock use cases. 
> Both of those entail normal PKIX validation, which both certTypes in this document disable.

How does 4.1 not satisfy the "cert lock" use case? Is your concern that
it not specificly states that the TLSA record should be override local
client policy of preconfigured trust anchors? I think some people would
object to such language.

Similarly for 4.2 for the CA lock case.

Perhaps we could state more clearly that a matching trust path based on
the TLSA record is required to confirm the EE/CA certificate obtained
from the TLS server before proceeding with any local client policy. Would
that satisfy your "lock in" concerns? This could be explained in Section 4.1

> Of course, the RP can always make the decision, but it would be good to enable the domain owner to make a recommendation -- suggest adding a flag for this.

I don't see how a flag would address anything. The TLSA record itself is already
a claim by the domain owner on what they believe is a valid TLS public key/cert.
A flag for "yes really" wouldn't add much to that.

Paul

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 27 Jul 2011 00:50:47 -0400

> a claim by the domain owner on what they believe is a valid TLS public key/cert.

No, the domain owner may wish to make a purely restrictive statement.
This is most important when an alternative CA (with cross certificates)
can serve as a useful constraint but the domain owner does not want to
be exposed to arbitrary certificates from it.  Another possible use is
to require a given intermediate or server certificate without waiving
PKIX revocation checks.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 27 Jul 2011 02:19:56 -0400

> to require a given intermediate or server certificate without waiving

-> https://trac.tools.ietf.org/wg/dane/trac/ticket/25

-- 
Matt

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Jul 2011 14:36:59 -0400 (EDT)

> -> https://trac.tools.ietf.org/wg/dane/trac/ticket/25

Isn't this already covered?

If they want it restrictive, they put in the EE cert.

If they want it restrictive & traditional, they put in the CA cert that's
  in the CA bundle received from the TLS server.

If they want it traditional, they don't put in a TLSA record at all.

the "additive" case is really a case of local policy and not for the TLS server
to dictate.

Paul