Subject: Re: [dane] Draft -17 comments

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 01 Mar 2012 10:36:46 +0100

Hi Dane-ists,

On 03/01/2012 12:22 AM, John Gilmore wrote:
> Thank you, editors!  -17 is a big improvement, editorially, over
> -16. Most of my comments are small nits, though there's one
> 2-paragraph insertion that I think is worthwhile.

I would like to add a single line after section 4.

It now has this:
   If an application receives zero usable certificate associations, it
   processes TLS in the normal fashion without any input from the TLSA
   records.  If an application receives one or more usable certificate
   associations, it attempts to match each certificate association with
   the TLS server's end entity certificate until a successful match is
   found.

I want to add:
           If there is no match, then the TLS connection is aborted.
Or (alternative, has keyword, I do not mind which one is taken)
           If none match, the application MUST abort the TLS connection.

This matches the algorithm in the appendix, and the behaviour if the
TLSA DNSSEC fails.  Because the 'else' from the 'if one or more usable
certificates, attempt to match' is not specified in the normative text.

Best regards,
   Wouter

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 1 Mar 2012 07:26:34 -0800

On Mar 1, 2012, at 1:36 AM, W.C.A. Wijngaards wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi Dane-ists,
> 

This works for me and matches my mental model of what the WG intended. Another way to say it would be "If no match is found, the TLS client MUST abort the TLS connection just as if, in the non-TLSA environment, the client could not validate the server's certificate".

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Thu, 1 Mar 2012 12:12:23 -0500

[ Please note that I have sent this without my consulting my co-chair (as he is off-line at the moment, it being night time there) -- anything stupid below is entirely my fault. I am explicitly CCing our AD so he can also provide a smackdown if needed.] 

Dear WG,

This working group has been a great learning opportunity for Ondrej and myself -- both of us came into this as basically virgin chairs (I cochair OpSec, but to be honest it has received very little of my attention, way less than it deserves) and appreciate the groups understanding as we have learnt. I know that I for one have made some mistakes, and have often let discussions get way off topic, have not communicated as clearly as I could have. I appreciate all of y'alls understanding and assistance over the many (long!) months...

The IETF in theory runs on rough consensus, running code (and large cookies) -- in actual fact it runs on the goodwill of the WG participants, coming together and being willing to consider each other's positions and compromise on something that we can all live with. Some of the topics here have been things that participants are very passionate about (and so we have had some incidents where that passion has bubbled over) and in general I have been very pleased with the WG's willingness to listen to other's views and compromise on a stronger solution.

I believe that we have rough consensus on this document and feel that we are now getting down into the weeds of wordsmithing -- we opened the major points in the Issues tracker, discussed and arrived at some sort of consensus, and our authors have incorporated (what the chairs judged to be) WG consensus. A number of issues were brought up during WGLC and discussed, and (very quickly) incorporated by the authors.

So, I am making one final request of the WG on this document -- we don't need to achieve (and never will) a state where everyone is perfectly happy, but please let me know if you are wildly unhappy with the document (and by "wildly unhappy" I mean "I'm ready to stab you, the process was horribly mismanaged and I've already written my appeal letter.").

Obviously, what would be even better would be a simple "I'm OK with this document" / "Yeah, I can live with this..." 
Again, we are not trying to get to a point where every word is perfect for everybody (nor reopening WGLC), rather a state that we can live with.

W

On Feb 29, 2012, at 10:50 AM, Paul Hoffman wrote:

> Greetings again. As you can see, we turned in -17 with what we think are all the changes asked for by the WG chairs. Please review the changes at <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-17>, and let the list and chairs know if you think we missed anything that the chairs asked us to do.
> 
> --Paul Hoffman
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Bill Owens <[email-masked]>
Date: Thu, 1 Mar 2012 12:51:27 -0500

> Again, we are not trying to get to a point where every word is perfect for everybody (nor reopening WGLC), rather a state that we can live with.

I've sent a note directly to the authors with very minor typo corrections; I am happy with this document.

Bill.

---

From: Ondrej Mikle <[email-masked]>
Date: Fri, 02 Mar 2012 01:24:47 +0100

Hello WG,

> So, I am making one final request of the WG on this document -- we don't need to achieve (and never will) a state where everyone is perfectly happy, but please let me know if you are wildly unhappy…

In my opinion the current consensus on the draft is fine.

John Gilmore raised the following issue:

> In section A.1.2.2:
>> One specific use-case should be noted: creating a TLSA association to
>> certificate I1 that directly signed end entity certificate S1 of the
>> server.  Since the key used to sign S1 is fixed, association to I1
>> must succeed: if a client swaps I1 for I2 (a different certificate),
>> its SPKI must match SPKI of I1.  Such and association would not
>> suffer from a false-negative failure on client's side if the client
>> uses a reissued CA certificate I2 in place of I1.
> A few issues here.  This is very dense and hard to understand; it took
> me a few readings.  Second, we use "SPKI" without defining it (the
> previous graf says SubjectPublicKeyInfo and is where we could hang a
> "(SPKI)").  Third, "Such and association" should be "Such an
> association".

Admittedly, it's not easy to understand. I can rewrite that, for example adding
ASCII graphs of those two cases. (I think adding those discrete graphs would be
much clearer compared to the wording.)

I can also add use cases for the new usage type 3 (not existent at the time of
writing of A.1 section).

I could write the mentioned update in the upcoming week (March 5-9th).

Conclusion: unless someone says such update is superfluous in the following
week, I'll write it.

Ondrej

---

From: Ondrej Mikle <[email-masked]>
Date: Mon, 05 Mar 2012 17:09:39 +0100

On 03/01/2012 12:22 AM, John Gilmore wrote:
> In section A.1:

[snip]

> 
> We do have a section later about this (A.1.2), but it seems to me
> that the much bigger question for TLS server operators is which
> certificate usage type to use, and which certificate it should identify.
> Whether it matches the whole cert, or just the public key; and whether it
> hashes, or provides the whole thing, are secondary to that initial
> choice that we don't even discuss.

A rough guide that should cover most cases (I'm numbering it A.1.4 since Jim
Schaad proposed additional subsection A.1.3). It's by no means perfect given how
many cases are there, but I think it's not misleading (much).

--

A.1.4 Transitioning to DANE-based system from current CA-based system

   This is a rough guide covering selection of certificate usage for
   server operators depending on how certificates were deployed on
   existing server's TLS services. It is by no means exhaustive but should
   point at the right direction for the majority of common cases. Server
   operators may have different preferences or policies that won't be
   covered here due to large amount of possible combinations.

   o Does TLS service use a well-known trusted CA-issued certificate?
     o If yes, then:
       o Does the service use single or at most two certificates?
         o choose certificate usage 1 (Service certificate constraint)
       o Otherwise (for cloud or CDN with many end-entity certificates):
         o choose certificate usage 0 (CA constraint)
     o If no, then:
       o Does service use self-signed certificate?
         o choose certificate usage 3 (Domain-issued certificate)
       o Otherwise the case is that service certificate is issued by a
         custom CA or a not-well-known CA
         o choose certificate usage 2 (Trust anchor assertion)

   It should be noted that the line between associating to a CA
   certificate or end-entity certificate is not an absolute. Therefore
   the above guide should be treated as informative.

   Associating with end-entity certificate (certificate usages 1 and 3)
   provides strictest assertion and is not affected by validation path
   building mechanisms at TLS clients' side. However associating with
   end-entity certificate might not be always possible (e.g. cloud
   service with hundreds of end-entity certificates) or desired for
   operational reasons (e.g. frequently exchanged end-entity
   certificate).

--

> 
>> Certificate usage 2 is not affected by the different types of chain
>> building when the end entity certificate is the same as the trust
>> anchor certificate.
> 
> Here's a clearer way to say it, which also points out that usage 3 is
> also immune from the troubles discussed: "Certificate usages 2 and 3
> are not affected by the different types of chain building, if the end
> entity certificate provided by the TLS server is the same as the
> certificate identified by (or provided in) the TLSA record."

At the time certificate usage 3 was not yet created. I propose following
formulation in the place of the "Certificate usage 2..." sentence:

"Association with end-entity certificate is immune from unpredictability in TLS
clients' validation path building algorithms. That means there are only two
cases affected: certificate usage 0 and certificate usage 2 if association is
made to a CA certificate."

> "(SPKI)").  Third, "Such and association" should be "Such an

An attempt to make the S1/I1/I2 case more readable (a replacement for the
paragraph "One specific use-case should be noted [...] uses a reissued CA
certificate I2 in place of I1."):

--

   One specific use-case should be noted: creating a TLSA association to
   CA certificate I1 that directly signed end entity certificate S1 of
   the server. The case can be illustrated by following graph:

              +----+                      +----+
              | I1 |                      | I2 |
              +----+                      +----+
                 |                           |
                 v                           v
              +----+                      +----+
              | S1 |                      | S1 |
              +----+                      +----+

          certificate chain sent by    a different validation path
          server in TLS handshake      built by TLS client

   I2 is a reissued version of CA certificate I1 (e.g. having different
   hash in signature algorithm).

   In the above scenario, both certificates I1 and I2 that sign S1 must
   have identical SubjectPublicKeyInfo, because the key used to sign S1
   is fixed. An association to SubjectPublicKeyInfo (selector type 1)
   will always succeed in such case whereas association with full
   certificate (selector type 0) might miss due to false-negative failure.

--

Ondrej

---

From: Pieter Lexis <[email-masked]>
Date: Wed, 07 Mar 2012 11:43:46 +0100

Hi all,

On 02/29/2012 04:50 PM, Paul Hoffman wrote:
> Greetings again. As you can see, we turned in -17 with what we
> think are all the changes asked for by the WG chairs. Please review
> the changes at 
> <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-17>,
> and let the list and chairs know if you think we missed anything
> that the chairs asked us to do.

I read the latest draft last weekend and I have a few minor issues
with it:

- -----

First off, the title (in the title bar) of the PDF version don't
display the brackets around (DANE) and (TLS). These show up as †DANE‡
and †TLS‡. Could be something with the tools used, don't worry too
much about it.

- -----

Second, the title on the top of every page says "DNS-Based Auth for
TLS". This seems sloppy, could this be changed to "DNS-Based
Authentication for TLS"?

- -----

Page 6, section 1.3:
This document defines a secure method to associate the certificate
that is obtained from the TLS server with a domain name using DNS;

To be honest, it doesn't define a 'secure method' to do this. It
defines a method that uses secure techniques (like DNSSEC) to
accomplish its goal (semantics, schantics).

- -----

Page 7, section 2.1.1:
...This usage is sometimes referred to as "CA constraint" because it
limits which CA can be used to issue certificates for a given host
name, port, and protocol. ...

I think this come from merging the old section 4 into this one. At
this point in the document, no examples of TLSA records have been
given. So it would make sense to rephrase this to a more common:

...This usage is sometimes referred to as "CA constraint" because it
limits which CA can be used to issue certificates for a service on a
host ...

And clarify this to be the (port, protocol, hostname) tuple in the
later sections (which is done).

- -----

Page 9, section 2.1.4:
...The data refers to the certificate in the association, not to the
TLS ASN.1 Certificate object.

This sentence suddenly talks about an ASN.1 Certificate object.
Someone not totally familiar with TLS and X.509 will have a hard time
understanding this sentence. I also believe that this sentence isn't
needed as it is correctly described in the sentences before it.
Perhaps a mention about the certificate data being in DER format
should be placed here.

- -----

Page 11, section 4:
o If the DNSSEC validation state on the response to the request for
the TLSA RRset is bogus, this MUST cause TLS not to be started or, if
the TLS negotiation is already in progress, MUST cause the connection
to be aborted.

The first sentence is a bit superfluous, maybe change this to:

o If the DNSSEC validation state of the TLSA RRset is bogus, ....

- -----

Page 29, Appendix C:

The following are examples of self-signed certificates that have been
been generated with various selectors and matching types. They were
generated with one piece of software, and validated by an individual
using other tools.

Is a bit lacking in formation, perhaps something like the following
will make it better:

The following examples are created from a single self-signed
certificate to show the differences between the various selectors and
matching types. These examples have been created and verified using
different tools.

- -----

Appendix B:

As an addition to Appendix B, I have created a better pseudo code for
the creation of the Certificate Association Data field.

// Helper functions
select(S, C) {
 if (S==0) {
  return as_DER(C)
 }
 if (S==1){
  return as_DER(C.SubjectPublicKeyInfo)
 }
}

hash(M,D) {
 if (M==0) {
  return D
 }
 if (M==1) {
  return SHA256(D)
 }
 if (M==2) {
  return SHA512(D)
 }
}

// Main function
create_assoc_data(Certificate, Selector, MatchingType) {
 return hash(MatchingType, select(Selector, Certificate))
 exit
}

- -----

Feel free to ignore/comment on/bury any of these suggestions.

Regards,

Pieter

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 7 Mar 2012 13:26:11 +0100

> accomplish its goal (semantics, schantics).

I am fine with 'secure method' in the Introduction section.  (I am also
find with just 'method'.)

> later sections (which is done).

Fine with this nit.

> Perhaps a mention about the certificate data being in DER format

That's why we have Normative Reference section.  You ought to read (well
and understand) documents in Normative References.

> o If the DNSSEC validation state of the TLSA RRset is bogus, ....

RRset doesn't have validation status.

> matching types. These examples have been created and verified using

Either is fine for me.

> return hash(MatchingType, select(Selector, Certificate))

LGTM

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQIcBAEBAgAGBQJPVzvfAAoJELPqGO5ebd4jBw4QAIULqHd7+aVUbHrmBoZgTY5x
> BuCppWsr7krL6av630kdfbIZ+YGnDxj6MO8FlQ+Rb4W6BIGTdIbFx8YWYJHnzKZr
> qcZgsaYfaks/o4eU+S9x+Mb7HlnZOUTEixkZrOg6pJsjGDo9kuFJgsa32D607x4l
> 5qPbnwnIvY7wRaejrQiVEe5FG3WpqFNkpTJlYgnV17rmaHBHwLgV2RVZqfJAMe05
> 911jGh3XY1RTcy62kr8JM2DywxZP75cy9IMK3aVEHPa5G4yeTOy609nzxD5nmPv2
> Ix2+sA89ZorwDkc9cw1hjLGetjStOdGnvAKBe/7ar6LslK+eo/WcPGMhWe2UWVHY
> lOAUK7Y41GwBlwAAqmo1f3nhVAhlslUU8ToU9nzDUyKHE1qk/tvFEIHI2cOBBAN2
> 17coxgcL16sWGU9yTau4zcK7uBLaOEQWq1vOojA+7DwB03ZDPf7Pz3DeFTzx5AJg
> uyeWkvu/5MwyK9eTI9xGcNnnAv1kUTQQ8wsMmqparamcHyt2J+rHwHvfNnusUfFW
> 1zoGStMt1OCV6fykDoMpzZ7bgCsCe6V8MgceTVUAri/WiQYYtV/pWs4Uut2M6jdK
> DsrWDqGTEr4RWkyfj1e8IZn6I4BKyBLfG8UDxFfygJchJEn97fQb33OkpXKV3mvs
> jgiNmOTrwgMqqPlJtI2i
> =CWaB
> -----END PGP SIGNATURE-----

--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 7 Mar 2012 13:35:00 +0100

Hi WG,

> many cases are there, but I think it's not misleading (much).

Do we really include a complete "HOWTO" in the Appendix?  What does the rest of WG think?

> made to a CA certificate."

I understand the problem, but I don't like this text.

LGTM

O.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 9 Mar 2012 11:17:47 +0100

On 1. 3. 2012, at 0:22, John Gilmore wrote:
> In section 5:
>> Roll-over -- Section 4 states that applications must not cache TLSA	
>> records beyond their TTL expiration. This ensures that clients 
>> will not latch onto assertions made by expired TLSA records, and 
>> will be able to transition between using one DANE mechanism to 
>> another.
> 
> Section 4 no longer says that about TTL cacheing, so this will need
> modification.  Perhaps refer now to section 8.1?  But that describes
> security considerations, not requirements on implementations.
> 
> I'd also suggest replacing the last phrase with "will be able to
> transition from using one DANE public key or certificate usage type to
> another."

Good catch.  Let's rephrase the first sentence to something like:

   Roll-over  -- TLSA records are processed in the normal manner
      within the scope of DNS protocol including the TTL expiration
      of the records.  This ensures that clients will not latch onto
      assertions made by expired TLSA records, and will be able to
      transition from using one DANE public key or certificate usage
      type to another.

Somebody with more English skill and higher caffeine levels in blood
please rephrase that.

I would also suggest to remove text in parentheses in Section 4, paragraph 4, stripping it down to:

   An implementation of this protocol makes a DNS query for TLSA records,
   validates these records using DNSSEC, and uses the resulting TLSA records
   and validation status to modify its responses to the TLS server.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 9 Mar 2012 11:33:49 +0100

John,

thanks for extensive review.

On 1. 3. 2012, at 0:22, John Gilmore wrote:

> Thank you, editors!  -17 is a big improvement, editorially, over -16.
> Most of my comments are small nits, though there's one 2-paragraph
> insertion that I think is worthwhile.

[deleted the nits and parts which I responded to in separate emails]

> In section 6:
>> A system creating TLSA records that conforms to this specification
>> MUST be able to create TLSA records containing certificate usages 0,
>> 1, 2, and 3.  A system creating TLSA records that conforms to this
>> specification MUST be able to create TLSA records with selectors 0
>> (full certificate) and 1 (SubjectPublicKeyInfo).  A system creating
>> TLSA records that conforms to this specification MUST be able to
>> create TLSA records using matching type 0 (no hash used) and matching
>> type 1 (SHA-256), and SHOULD be able to create TLSA records using
>> matching type 2 (SHA-512).
> 
> I thought we had agreed to pull this paragraph.

Yes, I think so:
http://www.ietf.org/mail-archive/web/dane/current/msg04412.html

>> A better design for
>> authenticating DNS would be to have the same level of authentication
>> used for all DNS additions and changes for a particular owner name.
> 
> I'd replace "owner name" with "domain name", since owner name is not
> defined anywhere,

'Owner' name is well defined term in DNS

> while everyone knows what a domain name is.

But 'domain name' is works for me as well.

> In section A.1:
> 
>> When creating TLSA records care must be taken to avoid
>> misconfigurations.  Section 4 of this document states that a TLSA
>> RRset whose validation state is secure MUST be used.  This means that
>> the existence of such a RRset effectively disables other forms of
>> name and path validation.  A misconfigured TLSA RRset will
>> effectively disable access to the TLS server for all conforming
>> clients, and this document does not provide any means of making a
>> gradual transition to using TLSA.
> 
> I agree that this paragraph needs to be in the document.  I think it
> belongs in the security considerations section rather than in an
> appendix.
> 
> Also, what is a "conforming client"?  To what does it conform?
> Heaven forefend that it conform to a "p-word"!
> 
> Here there's an important paragraph or 2 missing, just before "When
> creating TLSA records with certificate usage type 0 (CA Certificate)
> or type 2 (Trust Anchor)...".  Before we spend a few pages saying
> why it can be tricky to use TLSA in many ways, let's describe a
> straightforward, non-tricky way to transition to using TLSA:

Here I think this doesn't belong to this document.  We just want to
have the warning in the document.  Your provided text belongs to the
website(s) and howtos for the tools to be created.  Nobody will look
for this advice in the protocol document.

[...snip...]

>> When creating TLSA records with certificate usage type 0 (CA
>> Certificate) or type 2 (Trust Anchor), one needs to understand the
>> implications when choosing between selector type 0 (full certificate)
>> and 1 (SubjectPublicKeyInfo).  A careful choice is required because
>> different methods for building trust chains are used by different TLS
>> clients.  The following outlines the cases that one should be aware
>> of and discusses the implications of the choice of selector type.
> 
> I'd rewrite to say (particularly after inserting the above graf):
> TLSA server operators who create TLSA records with certificate types
> 0, 1, or 2 must take more care, because of the variability in how TLS
> clients build trust chains.  When creating TLSA records with
> certificate usage type 0 (CA Certificate) or type 2 (Trust Anchor),
> one needs to understand the implications.  The following outlines the
> cases that TLS server operators should be aware of.

I am sorry, but I see no difference in these two paragraphs in terms of clarity.  But maybe I am in this WG for too long.

Rest replied elsewhere (at least I hope I have responded to this in my response to Ondrej Mikle).

> certificate identified by (or provided in) the TLSA record."

This might be solved in thread: 'Making certificate usage type 2 "CA-only"?'

[I think I have responded to rest of your comments elsewhere, if not please feel free to point which sections needs more attention.]

O.

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 9 Mar 2012 11:42:15 +0100

On 1. 3. 2012, at 0:22, John Gilmore wrote:
> In section 8.1:
>> Implementations need to
>> be cautious in assuming the continuing validity of an TLSA records/
>> DNS name association.
> 
> "An TLSA records" sounds bad, even though I know it ultimately refers
> to "an association".  Perhaps you mean "Implementations need to be
> cautious in assuming the continuing validity of the association
> between TLSA records and a domain name."  But that is almost a
> tautology, caused by the confusing "association" language.  Every DNS
> resource record produces an association between the domain name and
> the contents of the record.  That association is always only good for
> a brief time, specified in the TTL.  So what are we really trying to
> say here?

Maybe it is tautology, but we need to say it in Security Consideration
sections.  Your wording is slightly better, but I am fine with both.
I'll leave it to the editors if they accept the change.

>> If implementations cache the results of domain name lookups in order
>> to achieve a performance improvement, they MUST observe the TTL
>> information reported by DNS.  Implementations that fail to follow
>> this rule this rule could be spoofed when a previously-accessed
>> server's TLSA record changes, such as during a certificate rollover.
> 
> I don't see how this can cause an implementation to be "spoofed".  If
> clients cache beyond the TTL, they'll use the old TLSA records, and
> may be unable to access a TLS server that uses a new certificate.  But
> that's denial of service, not spoofing.  The only way I can see to be
> spoofed is if the TLS server's previous private-key credentials had
> been exposed (and then this is why the TLS server's certificate has
> changed and why the corresponding TLSA records were changed).  In that
> case, someone who obtained the server's previous private-key
> credentials, and who can also act as a man-in-the-middle of the TLS
> connection, can spoof clients who use the old TLSA records.  But
> that's a much more detailed and less likely scenario than the one
> described.

I think you have exactly describe the scenario of spoofing.  It is less
likely scenario than DoS, but we are talking about security risks.

And/or we could add ' or access will be denied' after spoof.

O.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 10 Mar 2012 23:21:51 -0500 (EST)

>   and validation status to modify its responses to the TLS server.

modify its behaviour towards the TLS server? As it might decide not to
respond at all, or not even initiate.

Paul