On Tue, 28 Jul 2015, Melinda Shore wrote:
On 7/28/15 5:44 PM, Shumon Huque wrote:
I'd prefer to wait till the trans-ct-dnssec draft has progressed a bit
more before considering DNSSEC key transparency issues.
Agreed.
It looks like that draft proposes SCT RRs (with DS+chain data in them,
signed by log providers), so we could in the future incorporate SCT RRs
in the chain.
That draft really is pretty immature and at this point it's not
clear whether and how it's going to progress. Paul Wouters can
speak for himself about where he thinks the draft needs to go
The current draft focussed on the container format of the data, but
after some discussion in the dns and trans groups, it became clear
that the more important question to answer first is what to log.
Especially when you want to protect against a rogue parent, it becomes
important to log zone cuts along with the keys so that consumers of
the log can see the key/parent responsible for publishing the data.
There are also issues with preventing spam/ddos attacks against the
logs, similar but different from certificates.
Well, sort of. We did talk about creating a new certificate
extension rather than a TLS extension but opted not to. The
one advantage of an X.509 extension would have been that it wouldn't
require protocol changes, but it still would have required modifying
both the server and the endpoint.
The TLS extension would be easier to configure than requiring the system
administrator to regenerate (and re-sign?) certificates. Or mark certain
data (the dnssec blob) as not covered by the certificate signature.
People will end up putting the wrong certificate signatures in TLSA
records, etc. The TLS extension separates this more cleanly, and only
the TLS servers supporting the new extension need to know about how
to generate and serve the dnssec blob. Aind finally, with raw public
keys there is no way to embed the dnssec blob into the "certificate"
payload, as it is defined (on purpose) to only contain the SPKI.
Paul
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
