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

[Stephen Farrell <[e-mail]>]

Thanks Olafur,

Now that the DANE WG are going to address this issue,
I think that means that John can send his approval
for auth-48 for oob and we can move it forward.

Cheers,
S.


On 04/06/14 03:19, Olafur Gudmundsson wrote:
> 
> 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 
> 
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane
>