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

[Paul Hoffman <[e-mail]>]

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

> 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."  

Yep. That is still the plan.

> 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".

Anyone could have started the process for an update to 6689 to reflect this. They haven't yet.

> 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.

That is a horrible abuse of the RFC publication process. That is, instead of you asking for IETF review of your idea, you are trying to slip in a significant technical change with no community review.

> My coauthors seem to prefer that we just ignore the entire issue,
> issue RFC 7250, and ignore the conflict between the two.  

What conflict? DANE is clearly defined. If you want to update the definition (and many of us would support that), write the one-page Internet Draft to do so.

> 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.

And you are not.

> 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.

As co-author of RFC 6689, I fully disagree. The correct way to update RFC 6698 is with a new RFC that has community review.

--Paul Hoffman