On Wed, Jul 22, 2015 at 05:23:39PM -0400, Paul Wouters wrote:
> >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.
But, the presence of a CNAME chain (either from host to TLSA base
domain, or from TLSA base domain to ultimate TLSA RRset) the start
of the chain is in the answer per your first comment?
> >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.
But it would affect which RRsets servers should put in the extension.
I guess the extension structure remains the same, so no need to
pin this down yet?
> >>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.
Oh, I see, indeed I DO NOT want to see applications shipping with
their own rarely updated DNSSEC libraries. They should at least
use an actively maintained library that is sepeparate from the
application, and provides a "standard" API for doing the validation.
Even better would be a new type of query to the local resolver that
includes all the records as part of the query, and the local resolver
validates the results (for clients that can reach a resolver on
127.0.0.1, but which in turn can't get DNSSEC data).
(That is a protocol is even better than an API).
> > 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?
Sure, CA chains are largish, but no reason to make DNS chains
needlessly large, or for servers to perform uncompression just to
forward DNS packets to clients.
> >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?
Google might be more at liberty to mint certificates as they please
and to coordinate this with any DNS RRSIG refreshes, I don't see
the world at large being at liberty to do this.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
