Op 12-09-18 om 17:10 schreef Paul Wouters: > On Wed, 12 Sep 2018, Willem Toorop wrote: > >> Op 12-09-18 om 13:57 schreef Ilari Liusvaara: >>> On Wed, Sep 12, 2018 at 12:02:56PM +0100, Tony Finch wrote: >>>> >>>> The reason for wanting to include the NS targets' TLSA records in >>>> the glue >>>> is so that the resolver can immediately connect over DoT with >>>> authentication, without having to spend time chasing down TLSA records >>>> from below the zone cut. It would be a performance optimization. > > Then use RFC 7901 DNS chain queries (or the hopefully soon > tls-dnssec-chain TLS extension) > >>> Maybe I am missing something, but would you not need the DNSSEC records >>> proving the TLSA records are correct too? And if someone is using many >>> nameservers and questionable signature algorithms (*cough* RSA *cough*), >>> the size of the glue could grow rather large, blowing the MTU. > > Why do we care about MTU for DoH or DoT? > >> If you received the TLSA glue from an authenticated DoT authoritative in >> a referral, perhaps you do not need the RRSIG? > > Data origin security != transport security. > > What's with this NLnetlabs push to conflate the two? We are all happy > for DNS over HTTPS/TLS but stop suggesting it is replacing DNSSEC. Stop > attacking DANE.
Paul! NLnet Labs is a strong proponent of DNSSEC and DANE. I'm sorry if we made a different impression. I'm not trying to get rid of DNSSEC. I was only talking about the TLSA glue. Having that said, I actually do think that an obligatory tls-dnssec-chain extension support for authoritative DoT servers would make sense. With that in place, signaling does not have to deal with authentication, so any kind of signaling would suffice... At least if it came over DoT already, otherwise it can be nullified by an on path attacker. Then, regarding the kind of signal (TA bit or TLSA glue). I like in-zone signaling of DoT availability, because it allows for incremental deployment of reliable DoT to authoritative servers (with RFC7706 style locally verified zones). An alternative for TLSA glue could be a label in the NS name indicating DoT support perhaps? It's not pretty, but at least it would work right now. >> And perhaps (to deal with the chicken-and-egg problem) it is also okay >> to use the glue-TLSA records when you serve the zone locally à la >> RFC7706 and you have verified that the zone is complete and correct with >> draft-wessels-dns-zone-digest ? > > transfering entire zones to get TLSA records moves the privacy from from > the enduser to the zone administrator. Have you seen the ever returning > TLS Transparency discussions related to redacting? Understood. But it might be okay for the already public root. > > Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
