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.
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?
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
