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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dane > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
