Subject: [dane] Review of draft-ietf-dane-protocol-08.txt

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 Jul 2011 11:37:17 -0700

I have done a careful read of the document and here are my comments:

1.  IMO, you need to have another item added to section 2.1.1 - I believe
that the use of type 3 is insufficient for dealing with an intermediate CA.
Consider the following case:
   TA1->CA_TA1->EE and
   TA2->CA_TA2->EE
In both of these cases the public key for CA_TA1 and CA_TA2 are the same,
however it is not clear that the extensions that are included in these two
certificates are going to be the same.  Thus information might be lost or
changed in how the certificate EE is trusted.

2.  The text in para 4 of section 4.4 should probably also say that if the
certificate type is not understood by the TLS client then the association is
marked as unusable.

3.  The text in para 6 of section 4.4 is very out of date.  It does not
discuss any certificate type except end-entity and states that if an
end-entity certificate is not found (i.e. you cannot do a trust anchor only
DANE record) then the handshake aborts

4. In section 5 - 3.2 Certificate constraints - see above point about why I
don't think a public key actually implements a certificate constraint - it
just implements a public key constraint.  As such it does not enforce any
extensions in the certificate.

5. In section 5 - I have missed all of the text that discusses the
Combination point.  I think that the message a while ago about the need for
a potentially new certificate type is going to be required to deal with
combinations.  As such I do not believe that the current draft has any
useful discussion on combinations.

6. In section 6 - I believe that the roll-over text needs to include two
different phases.  The first is covered - that is that the TTL will cause
the old record to disappear.  However you need to have sufficient text to
state what happens if there are two end-entity certificates present at the
same time as this is also part of the roll over text.   There are some
interesting cases that might also be hard to document and implement and thus
need to be discussed.  What is happens if one is trying to roll over from a
TLSA record of type 1 to a TLSA record of type 2.  While both are present,
only one of the records needs to be satisfied.

7.  In section 6 - There is a missing discussion for delegated service that
needs to be include - Specifically it is not clear to me that the semantics
for item #3 in the delegated service section are implementable. (Separate
message follows)

8. Formatting error in 2.1.3 s/ASN.1Cert object/ASN.1 Cert Object/

9.  In section 2.2, I can understand the default representation of the
certificate for association being a hexadecimal character string, however I
would prefer not having a MUST here as I believe that it might make sense
for people to represent this in other ways - i.e. information that
represents a certificate might be more useful in more advanced versions.

10. Section 4.1 - The text assumes that all future reference types are going
to be hashes.  I do not believe that this will necessarily be true.  For
example I can see people defining a PGP certificate reference type.  I think
the last two sentences can be combined together when a more general
statement that the certificate referenced must be dereferenced and match.  I
don't know of any new reference types that might be included.  I believe
that in association with this we should change the reference type 0 from
Full Certificate  to Value.   If I include a cert type of 3 and a ref type
of 0 then calling the public key a full certificate does not really make any
sense.

11. Section 4.2 - As with the usage document, if the "Certification
Authority Certificate" is only for trust anchors - I would much rather see
the title of the section reflect that point.  It is not currently allowed
for an intermediate certification authority and thus the title is
misleading.  I personally have no problems with a certificate being both an
EE certificate and a trust anchor as that is what is happening.

12.  Section 4.4 - You say that type is a "trust anchor for that domain
name"  I think that this is a bit squirrely for language as it allows for a
possible ambiguity with DNSSEC vs TLS.  I would preferce that that it is a
"trust anchor for certificate chains for services in this domain name".

13.  Section 4.4 - Missing paragraph? " If a certificate association
contains a certificate type field that is not understood by the TLS client,
that certificate association MUST be marked as unusable."

Apologies - I tried to get this out earlier, but I have been on the road for
much of the last three weeks.

Jim

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 18 Jul 2011 22:57:11 +0300

> certificate type is not understood by the TLS client then the association is

-1. Such associations must be considered usable but not matching or you will
get a downgrade attack possibility.

> DANE record) then the handshake aborts

I think TLS requres an end-entity certificate (unless selected Ciphersuite
does not use certificates at all).

> extensions in the certificate.

Such extensions can be handled in untrusted manner. I.e. only process
restrictions.

> represents a certificate might be more useful in more advanced versions.

Well, that's DNS RR represntation anyway, not any sort of wire format.

Also, the hex format is pretty easy with hashes (shasum / sha256sum output).

> of 0 then calling the public key a full certificate does not really make any

The idea is that certificate type sets constraints on what it can match and
tells how to format the data. Then reference type tells what hash function
(if any) this data is to be run through. 

This decouples the certificate type and reference type. Also, this type
of cartesian factorizability makes implementation easier.

Thus to add PGP type, add certificate type 4 that can match PGP certificates
and specify how to format them.

> EE certificate and a trust anchor as that is what is happening.

Actually, according to text it is any higher certificate with EE specifically
excluded (use type 1 to match EEs). I think this is the intention for
type 2.

> "trust anchor for certificate chains for services in this domain name".

Or actually, isn't it just one port in that domain name?

> that certificate association MUST be marked as unusable."

See point 2 above for reasons I consider this to be very bad idea.

-Ilari

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 18 Jul 2011 16:20:53 -0400

> does not use certificates at all).

RFC 5246 implies that this is the case, but does not normatively require it.  See:
<http://tools.ietf.org/html/rfc5246#section-7.4.2>

--Richard

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 Jul 2011 14:05:05 -0700

Comments mixed in

> -----Original Message-----
> From: Ilari Liusvaara [mailto:[email-masked]]
> Sent: Monday, July 18, 2011 12:57 PM
> To: Jim Schaad
> Cc: Paul Hoffman; [email-masked]; [email-masked]
> Subject: Re: [dane] Review of draft-ietf-dane-protocol-08.txt
> 
> > 2.  The text in para 4 of section 4.4 should probably also say that if
> > the certificate type is not understood by the TLS client then the
> > association is marked as unusable.
> 

If that is the case then I would also say that the same text should be used for the references section.  I.e. if there is a reference that you do not understand then the association should not be marked as unusable and continue for the same reason as above.  Either both can be ignored or neither can be ignored.

> 
> > 3.  The text in para 6 of section 4.4 is very out of date.  It does
> > not discuss any certificate type except end-entity and states that if
> > an end-entity certificate is not found (i.e. you cannot do a trust
> > anchor only DANE record) then the handshake aborts
> 
> I think TLS requres an end-entity certificate (unless selected Ciphersuite does
> not use certificates at all).

My text was a bit too brief I guess.  The text in the paragraph states that if an association is not found for the end-entity certificate then the handshake stops.  However there is no reason in principle that an association could not be made for either the trust anchor or one of the intermediary CA certificates and no association exist for the EE certificate.  This is not to state that TLS does not have an EE certificate.

> 
> > 4. In section 5 - 3.2 Certificate constraints - see above point about
> > why I don't think a public key actually implements a certificate
> > constraint - it just implements a public key constraint.  As such it
> > does not enforce any extensions in the certificate.
> 

At least one of us has misunderstood the other.  If I have the case of 
TA1->CA1->EE  
And the certificate CA1(signed by TA1) has a critical extension in it that needs to be checked by the TLS client.
Alice puts in a TLSA restriction that the public key of CA1 must appear in the chain.

TA2->CA2->EE
The certificate CA2(signed by TA2) has the same public key as CA1, but does not contain the critical extension that Alice wants to see enforced.  There is nothing in the current system to say that only the cert for CA1 but not the cert for CA2 can be used to validate the certificate EE when doing chain validation.  Both certificates satisfy the public key constraint but do not have the same properties for doing path validation in PKIX.

> > certificate for association being a hexadecimal character string,
> > however I would prefer not having a MUST here as I believe that it
> > might make sense for people to represent this in other ways - i.e.
> > information that represents a certificate might be more useful in more
> advanced versions.
> 

I understand that this is not a wire format.  But I think that the MUST is too strong.  Do you disagree?

> 
> > 10. Section 4.1 - The text assumes that all future reference types are
> > going to be hashes.  I do not believe that this will necessarily be
> > true.  For example I can see people defining a PGP certificate
> > reference type.  I think the last two sentences can be combined
> > together when a more general statement that the certificate referenced
> > must be dereferenced and match.  I don't know of any new reference
> > types that might be included.  I believe that in association with this we
> should change the reference type 0 from
> > of 0 then calling the public key a full certificate does not really
> > make any sense.
> 
> The idea is that certificate type sets constraints on what it can match and tells
> how to format the data. Then reference type tells what hash function (if any)
> this data is to be run through.
> 
> This decouples the certificate type and reference type. Also, this type of
> cartesian factorizability makes implementation easier.
> 

I think that I changed thoughts half way through and messed up.  A new reference type might be "indirect" which would contain a DNS name to look for the TLSA certificate data .  Partly in this text I am mixing up reference type and certificate type.

Thought #1
The text assumes that all future reference types are going to be hashes.  I do not believe that this will necessarily be true.  For example, I can see people defining an "indirect" reference type where the contents is a DNS node to look in to get the actual certificate value.  

Thought #2
I think that using Full certificate for reference type 0 is incorrect and should be Value.  If I include a cert type of 3 and a ref type of 0 then calling the public key a full certificate does not really make any sense.

> > Authority Certificate" is only for trust anchors - I would much rather
> > see the title of the section reflect that point.  It is not currently
> > allowed for an intermediate certification authority and thus the title
> > is misleading.  I personally have no problems with a certificate being
> > both an EE certificate and a trust anchor as that is what is happening.
> 
> excluded (use type 1 to match EEs). I think this is the intention for type 2.

If you read the text is says "The certificate association is valid if the first
   certificate in the certificate bundle can be validly chained to the
   trust anchor from the TLSA data."
Which means that it is only for trust anchors.  Type 2 is in section 4.3 and thus would not be covered by this section (and the title on the section)

> 
> > 12.  Section 4.4 - You say that type is a "trust anchor for that
> > domain name"  I think that this is a bit squirrely for language as it
> > allows for a possible ambiguity with DNSSEC vs TLS.  I would preferce
> > that that it is a "trust anchor for certificate chains for services in this domain
> name".
> 

That would depend on the domain name in question.  If it was example.com then no it is the entire domain (with possible exceptions).  If it is _443._tcp.example.com then it would be for a specific port and protocol.

> > contains a certificate type field that is not understood by the TLS
> > client, that certificate association MUST be marked as unusable."
> 

This is what I get for writing a message over the course of 2 weeks.  This is a duplicate item and can be ignored.

Jim

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Jul 2011 17:19:31 -0400 (EDT)

> does not use certificates at all).

Hopefully not much longer:

http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-00

> and specify how to format them.

The naming of "certificate" in the entire document could be made more uhm opaque
to allow for different types, but it might make reading the document much harder.

Paul

---

From: Martin Rex <[email-masked]>
Date: Tue, 19 Jul 2011 02:56:57 +0200 (MEST)

Richard L. Barnes wrote:
> >> end-entity certificate is not found (i.e. you cannot do a trust anchor
> >> only DANE record) then the handshake aborts
> > 
> > I think TLS requres an end-entity certificate (unless selected
> > Ciphersuite does not use certificates at all).
> 
> RFC 5246 implies that this is the case, but does not normatively require it.
> See: <http://tools.ietf.org/html/rfc5246#section-7.4.2>

I do not see any such implication, and in fact, using self-signed
certs as well as servers using "allowed to act as a CA" cert
work fine with every TLS implementation that I've seen, once
you configure the trust.

Btw. shipping a TLS implementation with _ZERO_ trust anchors preconfigured
is perfectly reasonable.  In that case, configuring trust for a server
with a self-signed cert could be easier that configuring trust for a server
with a cert signed by a commercial CA.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Jul 2011 07:03:18 -0400

I'm not sure why you say it doesn't normatively require it. The text is:

   When this message will be sent:

      The server MUST send a Certificate message whenever the agreed-
      upon key exchange method uses certificates for authentication
      (this includes all key exchange methods defined in this document
      except DH_anon).  This message will always immediately follow the
      ServerHello message.

   Meaning of this message:

      This message conveys the server's certificate chain to the client.

      The certificate MUST be appropriate for the negotiated cipher
      suite's key exchange algorithm and any negotiated extensions.

I don't see any scope for omitting it because of stuff that happens outside of
TLS.

-Ekr

On Mon, Jul 18, 2011 at 4:20 PM, Richard L. Barnes <[email-masked]> wrote:
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Jul 2011 07:04:37 -0400

Perhaps your point is that it doesn't require a cert that is formally
a PKIX EE cert.

I agree, TLS is quite vague on this point. What it requires is that
there be a cert
corresponding to the public key the server intends to use.

-Ekr

---

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

On Tue, 26 Jul 2011, Eric Rescorla wrote:

> there be a cert corresponding to the public key the server intends to use.

And hopefully we can update that to be "the subjectPublicKeyInfo, optionally wrapped
into a cert, that the server intends to use" :P

Paul

---

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

On Mon, 2011-07-18 at 14:05 -0700, Jim Schaad wrote:
> That would depend on the domain name in question.  If it was
> example.com then no it is the entire domain (with possible
> exceptions).  If it is _443._tcp.example.com then it would be for a
> specific port and protocol.

The current draft does not provide for lookup of TLSA records at any
owner name other than _port._transport.host .

-- 
Matt

---

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

> useful discussion on combinations.

If you meant this:

https://www.ietf.org/mail-archive/web/dane/current/msg02637.html

then see:

https://trac.tools.ietf.org/wg/dane/trac/ticket/27

-- 
Matt

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 27 Jul 2011 09:03:15 -0400

> From: Matt McCutchen [mailto:[email-masked]]
> Sent: Wednesday, July 27, 2011 12:55 AM
> To: Jim Schaad
> Cc: [email-masked]
> > > > domain name"  I think that this is a bit squirrely for language as
> > > > it allows for a possible ambiguity with DNSSEC vs TLS.  I would
> > > > preferce that that it is a "trust anchor for certificate chains
> > > > for services in this domain
> > > name".
> > >
> The current draft does not provide for lookup of TLSA records at any owner
> name other than _port._transport.host .

But you could find the records at any of the DNS names starting at that point and striping off the left most token until you actually find the TLSA records.    However I don't believe that this changes my statement that I am not happy with the language in question.

Jim

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 27 Jul 2011 13:34:23 -0400

On Wed, 2011-07-27 at 09:03 -0400, Jim Schaad wrote:
> But you could find the records at any of the DNS names starting at
> that point and striping off the left most token until you actually
> find the TLSA records.

The draft does not provide for any such behavior, except inasmuch as it
happens automatically via DNS wildcard expansion.  And I do not see a
need to state the effect of DNS wildcard expansion specifically rather
than just let it generate individual virtual RRsets that apply to all
possible transports and ports at the host.

> However I don't believe that this changes my statement that I am not
> happy with the language in question.

Agreed.

-- 
Matt