On Wed, 22 Jul 2015, Viktor Dukhovni wrote:
I think the server should stick to one chain, from the root to itself,
so it does not have to deal with variable chain blobs per client.
That will allow server code to stick to something like hourly
regenerating the blob for use with all clients.
From the root to its own TLSA RRset, however, this can be complicated
in the presence of CNAMEs:
Should everything other than the first CNAME be in additional
records?
I think so.
Should all the above (with their RRSIGs) be in the answer
section, with the union of the supporting DNSKEY/RRSIG/DS records
as additional?
No, only the TLSA record and its RRSIG should be in there, so it is
identical to a real DNS response packet.
I tried to ask a related question during the meeting, but bandwidth
to explain the context was limited: Should proofs of non-delegation
be included, to keep gTLDs and ccTLDs honest for some future CT for
DNS? Specifically, suppose you see:
_443._tcp.www.example.com. IN TLSA <rrdata>
with an RRSIG from the ".com" zone, should there also be NSEC/NSEC3
records that demonstrate that "example.com" (and www.example.com)
are not delegated? (Such records might then be subject to "gossip"
or related "transparency" counter-measures).
That's an interesting question. I'd be tempted not to do this work in
the TLS extension but keep that to a ct-dnssec document.
I do strongly prefer the binary blob to be in raw dns format. That
will make parsing easier with existing code, and over time we will
not run into issues where dns libraries support newer algorithms
but this specific dnssec parsing code isn't updated.
I'm not sure what "algorithms" you have in mind?
The successor to ECDSA or something like Curve*. I meant new DNSKEY
algorithms used to generate RRSIG records. I would like to see DNS
code maintained by DNS people used by browser people but I am young and
naive.
We should perhaps
allow (even encourage) "compression" to reduce the payload size,
Is that a problem in TLS? I thought the CA chains were already massively
bigger? Or is this something specific to the client/server hello
message?
As for ekr's question on why not stuff this inside X.509, that would not
be compatible with tls raw pulic keys that only contain a SBKI, and drag
back into the protocol more ASN.1 parsing and containers.
This really can't go in the certificate, because then certificates
would have to be updated as often as RRSIGS are regenerated. That
seems exceedingly unlikely to be deployable.
I agree, but Adam Langley did make that work so perhaps we are wrong?
Paul
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
