Confirm
298
edits
Changes
no edit summary
(Where the entry is intended to be a single contiguous line.) This specifies a record of type 65468 (experimental number for TLSA) that is 34 bytes long. The "03" at the beginning indicates a public key, and the "01" indicates sha256. The rest is the hash. (The actual data embedded in the record is represented as a series of in-order two-digit hexadecimal values that each correspond to a byte of data.)
== Transmitting the DNSSEC Chain ==
There are essentially two reasonable options for transmitting the DNSSEC chain in the TLS handshake. The first option is to include it as an X509 extension in the server certificate, as Google Chrome does (see above). The second option would be to define a TLS extension wherein the server sends the chain in addition to, but outside of, its certificate. In either case, the client would receive the chain, verify it, and if successful, continue the session. Note that the material provided in the chain does not replace the material from the certificate - it merely verifies it.
The first option (X509 extension) is easy to deploy, as it only requires making a special certificate and no modifications to server software. It works well with self-signed certificates (where the TLSA record provides the chain of trust), but not with preexisting certificates signed by a third party. Furthermore, in order to use the optimization of sending a chain with a deeper root of trust (i.e. sending a shorter chain), the certificate would have to either be created on the fly or a certificate for every possible chain would have to be created (admittedly, this is a small number). This still doesn't solve the problem, however, because there must be a mechanism for the client to tell the server what root is appropriate.
The second option (TLS extension) is more difficult to deploy, because it requires server modification. However, it will work with both self-signed and preexisting certificates. Additionally, the short chain optimization would work as expected: the client specifies a trusted root and the server responds with a chain from that root.
Currently the second option (TLS extension) is considered ultimately more flexible and usable.
== Contact ==
David Keeler (irc: keeler, email: d[irc name]@mozilla.com)
