Subject: [dane] DANE deployment document?

From: Bill Owens <[email-masked]>
Date: Wed, 15 Feb 2012 08:40:18 -0500

The group seems to have collected a set of issues during WGLC:

 - real-world implementations and their adherence to RFC5280
 - a perceived lack of introductory and explanatory text
 - desire for full example records and associated certs
 - questions around behavior in the presence of local trust anchors and proxies
 - one more that I want to mention, but first need to read through the list archives to see whether someone else has already pointed to it ;)

Would it be reasonable to consider another document to collect all of these, something like 'DANE Deployment Considerations'? It seems as though we have a usable document in draft 16, one that could be used to request an RRTYPE assignment and allow implementations to move forward, and that these issues will not end up causing changes to the normative portions of the standard. We might even have some interoperable implementations to talk about, by the time a deployment draft was ready to be taken forward.

Bill.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Feb 2012 07:23:13 -0800

> Would it be reasonable to consider another document to collect all of these, something like 'DANE Deployment Considerations'? It seems as though we have a usable document in draft 16, one that coul…

Personal opinion: a deployment considerations document would be a good place for the "explain the context" discussion that John wants as well, much better than the protocol document.

Note that such a deployment considerations document does *not* need to be a formal WG item, but certainly should be discussed on this mailing list as it is put together.

--Paul Hoffman

---

From: John Gilmore <[email-masked]>
Date: Wed, 15 Feb 2012 22:57:46 -0800

> Note that such a deployment considerations document does *not* need to be a formal WG item, but certainly should be discussed on this mailing list as it is put together.

WG Last Call is supposed to be about the document that's been called.
If it has issues and the issues aren't addressed in the document, then
the document shouldn't proceed toward publication.  I haven't proposed
any protocol changes -- just editorial changes to how the protocol is
explained in the document.

The idea that we can publish an incomprehensible or self-contradictory
document and then somehow patch things up with a "deploying your
incomprehensible or self-contradictory standard" document looks to me
like a recipe for unsuccessful adoption by the greater community.
Particularly if the "deploying" document isn't a standards-track
document.

I thought that I (and every other WG member) was being called upon to
spend many hours reviewing the document and making concrete
suggestions, to make it the document and protocol that we'd all be
proud to publish.  It's our last chance to do so.  If the real point
of a WGLC is to just rubber-stamp the document, somebody should've
told me not to waste my time.

	John

PS: If anyone perceives a need to rush out a document just to get a
TLSA RRTYPE allocated, we should just follow RFC 5395 and ask IANA for
one.  They'll send our request to a couple of expert reviewers and get
back to us shortly.  We don't have to publish an RFC to get an RRTYPE.

---

From: John Gilmore <[email-masked]>
Date: Thu, 16 Feb 2012 00:31:07 -0800

Section 2.1.1 of draft-ietf-dane-protocol-16.txt punts the meaning of
the certificate usage field to section 4.  Section 4 attempts to
finally specify the semantics of the four defined TLSA Certificate
Usage values.  However, Section 4 is hard to understand.

First, I suggest that we present these usages in order of increasing
complexity.  Thus, "Match certificate" would be first, since it is
most straightforward - a straight binary comparison with what
came over the wire in TLS.

Then "PKIX Validation and match end entity certificate", since it only
adds one complexity to "Match certificate".  Since the same end entity
certificate (provided by the TLS server) always has to appear in any
certification path, this certificate use doesn't affect the building
of certificate validation chains.  This also just involves a new
straight binary comparison.

The next most complex, "PKIX Validation and Chain through CA",
involves modifying a complex and poorly documented part of the PKIX
Validation process.  A naive implementation of this certificate usage
could vastly increase the processing time required for building a
final certificate validation chain -- possibly requiring the software
to try millions of combinations before succeeding.  Yet we provide no
warning about this, nor make any related suggestions (e.g. website
admins should avoid this usage if you want fast web browsing of your
site; or programmers, here are some heuristics for making your
implementation fast).

The most complex, "PKIX Validation and Use Trust Anchor", is poorly
defined due to the absence of a dependable description of how path
construction works.  This usage can't necessarily be done by a naive
implementation (or perhaps I don't understand how it works -- which
again is a problem, if WG members can't understand the spec, how can
ordinary mortals be expected to).  Existing TLS implementations will
not just have to surround their existing PKIX chain construction code
with an extra check, as with the other two certificate usages that
involve PKIX.  Instead they will have to modify the guts of the chain
construction code -- but since chain construction is not standardized,
it's unclear exactly what the revised software will have to do.

Also, it currently says:

   4.3.  Pass PKIX Validation and Use Trust Anchor

   Certificate usage 2 is used to specify a certificate, or the public
   key of such a certificate, that must be used as a trust anchor when
   validating the end entity certificate given by the server in TLS.
   This usage is sometimes referred to as "trust anchor assertion" and
   allows a domain name administrator to specify a new trust anchor,
   such as if the domain issues its own certificates under its own CA
   that is not expected to be in the end users collection of trust
   anchors.
  
This is the complete description of this certificate usage's semantics!

This certificate usage value only appears to work if the matching type
field is 0, and if the selector field is 0.  If only a hash of a
certificate or key is provided, then how can this TLSA record provide
a provide a new trust anchor "that is not expected to be in the end
user[']s collection of trust anchors"?  Yet this constraint is nowhere
mentioned.

I don't think PKIX validation can even be done when only the key of a
trust anchor is known (selector = 1).  Additional fields of the trust
anchor, such as the CA's name and constraints are required.  RFC 5280
says:

   In Section 6.1, the text describes basic path validation.  Valid
   paths begin with certificates issued by a trust anchor.  The
   algorithm requires the public key of the CA, the CA's name, and any
   constraints upon the set of paths that may be validated using this
   key.

It goes on to say:

         The trust anchor information includes:
         (1)  the trusted issuer name,
         (2)  the trusted public key algorithm,
         (3)  the trusted public key, and
         (4)  optionally, the trusted public key parameters associated
              with the public key.

To make this Certificate Usage type work with a bare public key, we
would need to enhance the PKIX Path Validation described in RFC 5820
by specifying how a bare public key engages in that process.
Alternatively, we should only standardize this Certificate Usage type
for use with a full certificate provided in the TLSA RDATA.

In addition, we should consider suggesting that the trust anchor
specified in this Certificate Usage SHOULD be directly used to sign
the end-entity certificate provided by the TLS server.  This should
reduce the opportunities for path construction irregularities.  It
still offers an advantage over the "Match Certificate" usage, by
allowing the TLSA record to not need updating when the TLS server's
key is changed.

If we reorder the discussion from least complex to most complex,
we should consider renumbering the field values in that order as well
(so that 0 denotes the least complex usage, and so that the field
values are once again described in numerical order).

Finally, WG discussion has produced so many varying points of view
about path construction that it will be hard to say anything concrete
in the I-D about it.  But rather than let our silence lead the reader
to assume that the certificate usages that modify path construction
algorithms are simple or well understood, we should at least warn the
reader about the diversity of implementations they are likely to
encounter.  I suggest adding a paragraph like:

   4.5.  Complexities of TLSA Certificate Usage

   TLS specifies a certification path validation algorithm without
   specifying a path construction algorithm, leaving many details to
   vary in individual implementations.  Some of the complexities
   hiding in those details are described in "Internet X.509 Public Key
   Infrastructure: Certification Path Building" [RFC4158].  The
   addition of TLSA records with certificate usages specifying "Chain
   via CA" or "Use Trust Anchor" modifies these unspecified
   algorithms, in ways that can change both the results and the
   performance of the implementation.  Since implementations are free
   to vary in how they interpret these records, TLS server
   administrators should carefully consider whether and when to use
   these certificate usage specifiers, and if used, should test them
   for interoperability in a variety of TLS clients.

	John

---

From: John Gilmore <[email-masked]>
Date: Thu, 16 Feb 2012 00:37:04 -0800

Small changes: In 4.1 and 4.2, end the last sentence of each paragraph
by saying that these usages limit what certificate can be used "for a
given host name, protocol and port".  Currently they say "for a given
host name", but name prefixing clearly allows multiple different TLS
servers at the same host name, which might well use different
certificate chains.

	John

---

From: Bill Owens <[email-masked]>
Date: Thu, 16 Feb 2012 08:31:38 -0500

> Particularly if the "deploying" document isn't a standards-track

I thought it should be obvious, but apparently isn't, so I will be explicit; I have closely reviewed the document over the last few drafts and provided my comments to the authors and to the list, and do not believe that it is 'incomprehensible or self-contradictory'. I have the strong impression that the other members of the WG agree, or they would have previously commented as well; of course they can speak to that point if they choose. There are of course some specific points of contention, at least those that I listed and possibly more, but if they don't affect the protocol definition I don't see a need to have them dealt with in the protocol specification.

I am not yet persuaded that there is a need for additional explanatory text beyond what is already included in RFC6394. I am arguing that, if further explanation is needed, it should be dealt with in a separate document explicitly written for that purpose.

> back to us shortly.  We don't have to publish an RFC to get an RRTYPE.

Let me be explicit again; I am not proposing to rush the document, rather to avoid making substantial changes to a document that the group already felt was ready for WGLC, in the name of avoiding delay. I'm glad to learn that an RFC is not required to ask for an RRTYPE, though I wonder whether the expert reviewers would want the draft to at least have passed WGLC. 

I accept that you are spending many hours reviewing and changing the document; please understand that your requests are requiring us to spend hours reviewing and considering your changes, to a document that some of us, at least, were already satisfied with.

Bill.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Feb 2012 10:48:34 -0800

> explained in the document.

Actually, you have, but most of what you have proposed so far is a major editorial overhaul. So far, not many people have supported it.

> like a recipe for unsuccessful adoption by the greater community.

To date, you are the only person who has claimed that the document is incomprehensible or self-contradictory. Sure, there have been many places where it was not clear; we have fixed them as they were exposed. Others have shown by actual coding that the document is comprehensible.

> Particularly if the "deploying" document isn't a standards-track

Oh, please. You are saying that a developer who finds a protocol document incomprehensible or self-contradictory and finds an informational deployment document is going to stop and say "screw it, I won't read it unless it is on standards track". That's silly.

> proud to publish.

I cannot find "proud to publish" in the WG archives. Everyone is called on to make the document an accurate description of what the WG believes is the consensus of the WG. That certainly can mean editorial improvement: it has meant that at every step of the process.

>  It's our last chance to do so.  If the real point

And yet no one told you that because it is not true. It is true that if one person asks for major changes and that request doesn't get much support in the WG, the chairs might not ask the authors to make the changes. It is also true that WG members should feel free to comment on each other's requests without wondering if they will be attacked with strawmen overstatements.

> back to us shortly.  We don't have to publish an RFC to get an RRTYPE.

Another strawman. No one has said anything about rushing, and if you look at the archive, you will see that no one has rushed.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Feb 2012 11:19:09 -0800

> Usage values.  However, Section 4 is hard to understand.

It sounds like you missed the recent thread on this list that asked for us to wind the material from 4 into 2.1.1, and we said we would unless there was any strong objection (and there has been none).

> complexity.  

Presenting the usages in an order other than numeric seems silly to me. Others might disagree. These are short paragraphs, and we expect developers reading the document to understand all of them.

> site; or programmers, here are some heuristics for making your

Implementation guidance sounds like good material for an implementation guidance document or appendix. So far, the group seems more inclined towards the former, but your earlier message indicates you are not.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Feb 2012 11:22:00 -0800

> allowing the TLSA record to not need updating when the TLS server's

Despite what John said in an earlier message about not making technical changes, I think this is a request to get rid of usage type 2, or add a lot of technical requirements on its use. I'm OK with either of those actions, and would prefer to get rid of it to make the protocol simpler.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Feb 2012 11:24:07 -0800

> servers at the same host name, which might well use different

Good catch, yes.

--Paul Hoffman

---

From: Pieter Lexis <[email-masked]>
Date: Thu, 16 Feb 2012 20:38:53 +0100

Hi,

On 02/16/2012 08:22 PM, Paul Hoffman wrote:
> Despite what John said in an earlier message about not making 
> technical changes, I think this is a request to get rid of usage
> type 2, or add a lot of technical requirements on its use. I'm OK
> with either of those actions, and would prefer to get rid of it to
> make the protocol simpler.

How would one use a private CA when usage 2 gets removed? Usage 0
isn't sufficient to do this.

- From a purely operational point of view, using a private CA is less
burdensome (TLSA wise, with DNS server support) than usage 3
('privately issued certs').

But if this issue is not resolvable for now, it should be removed and
the PKIX WG should create a document describing the path-building
algorithm.

- --
Pieter

---

From: John Gilmore <[email-masked]>
Date: Thu, 16 Feb 2012 12:10:09 -0800

> make the protocol simpler.

I sought to document how cert usage type 2 interacts with the
selector and match fields.

And perhaps to *suggest* that domain administrators who make a direct
2-cert chain between the trust anchor certificate and the end-entity
certificate, will likely improve their interoperability.  We already
have similar cautionary text in the Security Considerations section.
(Nit: that text has a typo, "be come".) 

	John

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 16 Feb 2012 12:35:25 -0800

On Feb 16, 2012, at 11:38 AM, Pieter Lexis wrote:

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

Now I'm confused. Why can't type 0 be used for a private CA (that is, one that is not already in the client's trust store)?

> ('privately issued certs').

That will be true for some folks, not for others. But regardless, we should certainly support it. I thought that 0 did so.

--Paul Hoffman

---

From: Pieter Lexis <[email-masked]>
Date: Thu, 16 Feb 2012 22:25:22 +0100

Hi,

On 02/16/2012 09:35 PM, Paul Hoffman wrote:
> Now I'm confused. Why can't type 0 be used for a private CA (that
> is, one that is not already in the client's trust store)?

Well, Usage 2 talks about using the association as a trust anchor and
section 4.3 talks about the certificate not being expected to be in
the end-user's cert-store.

I assumed this means that usage 0 implies that the certificate in the
association is 'well known' (aka expected to be in the user's cert
store). Also, it is defined as being a 'CA certificate'.

>> - From a purely operational point of view, using a private CA is 
>> less burdensome (TLSA wise, with DNS server support) than usage 3
> That will be true for some folks, not for others. But regardless,
> we should certainly support it. I thought that 0 did so.

I though it didn't. See above.

- --
Pieter

---

From: James Cloos <[email-masked]>
Date: Thu, 16 Feb 2012 17:08:09 -0500

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

PH> I think this is a request to get rid of usage type 2, or add a lot
PH> of technical requirements on its use. I'm OK with either of those
PH> actions, and would prefer to get rid of it to make the protocol simpler.

-1 on removal.  Just add a note that the TLS server SHOULD send the cert
referenced by the type 2 TLSA RR just like it currently SHOULD (MUST?)
send intermediate certs.

Conceptually, the cert in question IS an intermediate cert; it is
just tied to DNS instead of to an OutOfBand x509 cert.

So wording it that way ought to be easy to comprehend and
implementations written based on that conceptualization should
Just Work™.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 24 Feb 2012 16:35:57 +0100

> implementations written based on that conceptualization should

+1 to this solution.  It works for me.  Does it work for you, Paul?  Any objections from WG?  (Reading RFC 5280 Section 6 is assumed.)

O.
--
 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: Paul Hoffman <[email-masked]>
Date: Fri, 24 Feb 2012 07:40:53 -0800

> +1 to this solution.  It works for me.  Does it work for you, Paul?  Any objections from WG?  (Reading RFC 5280 Section 6 is assumed.)

Works for me if it works for the WG.

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Feb 2012 11:09:18 -0500

> implementations written based on that conceptualization should

+1 to what Jim says.

--Richard

---

From: Pieter Lexis <[email-masked]>
Date: Fri, 24 Feb 2012 17:14:04 +0100

On 02/16/2012 11:08 PM, James Cloos wrote:
> -1 on removal.  Just add a note that the TLS server SHOULD send the
> cert referenced by the type 2 TLSA RR just like it currently SHOULD
> (MUST?) send intermediate certs.
> 
> implementations written based on that conceptualization should Just
> Work™.

+1 on JC's comment (so -1 on removal)

- --
Pieter