Confirm
298
edits
Changes
m
→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 minimal 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. This optimization would require some small server modifications.
The second option (TLS extension) is more difficult to deploy, because it requires more significant server modificationto implement the extension. 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.
