Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

[Olafur Gudmundsson <[e-mail]>]

John, 
Sorry for the top posting of our main arguments. 
RFC7250 has shipped, please do not hold up the publication. 
We need a quick turnaround to address the issues you identified below. 

As Wes Hardaker commented in a later message we have an “Dane uses and fixes” document in the
queue and adding this to it is appropriate. (dane-ops) 
<more comments inline plan at the bottom> 

On May 29, 2014, at 4:05 AM, John Gilmore <[e-mail]> wrote:

> The TLS Working Group is in the final stages of approving RFC 7250,
> "Using Raw Public Keys in TLS/DTLS":
> 
>  https://www.rfc-editor.org/authors/rfc7250.txt
> 
> The draft modifies the TLS protocol to allow clients and servers to
> negotiate and exchange types of authentication material other than
> PKIX certificate chains, and defines a format for exchanging a raw
> public key.  These public keys are authenticated "out of band",
> outside the TLS protocol, for example by prior administration (in some
> Internet-of-Things cases), or by the use of DANE.  Paul Wouters was
> the main author, and the protocol and document were significantly
> improved by several co-authors from the TLS WG.
> 
> In reviewing the draft, I noticed that it doesn't ever describe how
> you store such a public key in a TLSA record.  And the TLSA RFC 6698
> explicitly specifies that TLSA records can ONLY store PKIX
> certificates!  The relevant sections are:
> 
> RFC 6698 Sec. 1.3:
> 
>   This document only applies to PKIX [RFC5280] certificates, not
>   certificates of other formats.

This is a major change and specifying how to do other certificate types 
should go through the normal standards process. 
DANE WG is happy to take that on, and this should be processed before we go on to DANE-bis document. 

> 
> RFC 6698 Sec. 2.1.1:
> 
>   The certificate usages defined in this document explicitly only apply
>   to PKIX-formatted certificates in DER encoding [X.690].  If TLS
>   allows other formats later, or if extensions to this RRtype are made
>   that accept other formats for certificates, those certificates will
>   need their own certificate usage values.
> 
> I remember fighting this fight in the DANE WG, and the result was
> something along the lines of "We'll narrow the RFC now, and then
> if-and-when raw public keys are approved by the TLS WG, then we'll
> amend it to include them."  Well, the time has come.  Raw public keys
> are approved by the TLS WG.  The trouble is that nobody has bothered
> to amend the TLSA RFC, so the new draft RFC tells people "just use
> DANE", but the DANE TLSA RFC says, "No you can't”.

Lets fix this, based on experience!

> 
> I propose to add some text to the draft RFC 7250 that extends RFC 6698
> by defining how raw public keys are stored in TLSA records.

In the chairs opinion that is a bad idea. 

> 
> My coauthors seem to prefer that we just ignore the entire issue,
> issue RFC 7250, and ignore the conflict between the two.  As someone
> who learned most of what I know about protocols (and the Internet)
> from reading Saint Jon Postel's clearly written RFCs, I would hate to
> inflict that on future readers.  We should not release documents that
> contain deliberate incompatabilities.

We wish that this had been detected sooner and a corresponding document was in 
the publication queue, we are willing to commit to get this fix ASAP. 

> 
> We think RFC 7250 is ready to go except for this remaining issue.  It
> has been approved by the TLS WG, the IESG, the RFC Editor, and all the
> co-authors but me.
> 
> Here's my proposed wording change for RFC 7520.  Improvements welcome.
> Start from this version:
> 
>  https://www.rfc-editor.org/authors/rfc7250.txt
> 
> Section 4.4.
> OLD (entire section):
>   When the TLS server has specified RawPublicKey as the
>   server_certificate_type, authentication of the TLS server to the TLS
>   client is supported only through authentication of the received
>   client SubjectPublicKeyInfo via an out-of-band method.
> 
> NEW (entire section):
>   When the TLS server has specified RawPublicKey as the
>   server_certificate_type, authentication of the TLS server to the TLS
>   client is supported only through authentication of the received
>   client SubjectPublicKeyInfo via an out-of-band method.
> 
>   In order to support out-of-band authentication via DANE [RFC6698],
>   this document extends the DANE TLSA record definition to allow such
>   records to describe raw public keys as well as PKIX [RFC5280]
>   certificates.  This extension does not define any new field values;
>   it merely defines how existing fields are processed when being
>   matched to raw public keys provided by TLS servers.
> 
>   A raw public key is represented in a TLSA record by specifying a
>   certificate usage of 3 (domain-provided), a selector of 1
>   (SubjectPublicKeyInfo), and a matching type of 0.  The
>   SubjectPublicKeyInfo that holds the public key is placed in the
>   certificate association data.  Matching types other than 0 may also
>   be used, by placing the corresponding hash value into the
>   certificate association data.
> 
>   DANE [RFC6698] section 1.3 is extended to say:
> 
>      This document only applies to raw public keys and to PKIX
>      [RFC5280] certificates, not certificates of other formats.
> 
>   DANE section 2.1.1 is extended to say:
> 
>      The certificate usages 0, 1 and 2 defined in this document
>      explicitly only apply to PKIX-formatted certificates in DER
>      encoding [X.690].  If TLS allows other formats later, or if
>      extensions to this RRtype are made that accept other formats for
>      certificates, those certificates will need their own certificate
>      usage values.
> 
>   In DANE section 2.1.1, in addition to the definition of certificate
>   usage 3 with TLS servers that use PKIX certificates, certificate
>   usage 3 may also be used with TLS servers that use raw public keys:
> 
>      3 -- Certificate usage 3 is also used to specify a raw public key
>      that MUST match the raw public key presented by the server in
>      TLS.  When the TLS server provides a raw public key, there is no
>      PKIX certificate and no PKIX validation is done; the TLS
>      server's raw public key MUST match the raw public key provided in
>      the TLSA record.  This certificate usage is sometimes referred
>      to as "domain-issued" because it allows a domain administrator
>      to directly certify a domain's public keys.
> 
> I believe that this wording reflects the up-to-now tacit consensus on
> how the DANE WG expects TLS raw public keys to be represented and
> processed in TLSA records.  In the absence of significant dissent or
> further improvements, I propose to provide the above updates to the
> RFC Editor and release the new RFC.
> 
> 	John

We think this text is a good starting point, for the OPS document that will update RFC6698

The plan we propose is publish RFC7250 and push the fix out no later than right after the
IETF meeting in Toronto. 

	Olafur & Warren