Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers
Am 13.09.18 um 14:14 schrieb Willem Toorop:
> 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.
Hello,
yes, a special authoritative server name was also the mechanism, DJB choose to
publish
a curvedns server public key. (https://en.wikipedia.org/wiki/DNSCurve)
so why not name a authoritative server "dot{foo}.example"?
A resolver may expect by definition that this authoritative server
- is reachable on port 853/tcp
- present a certificate
- prove the certificate's content by a TLSA record served inline via
tls-dnssec-chain as well as via 'normal' DNS
- serve zone data
-> capability signaling by name
That way it's not a requirement for a delegation zone to serve any additional
data.
Andreas
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers
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 dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers
Paul Wouters wrote: > On Wed, 12 Sep 2018, Tony Finch wrote: > > > > RFC 7901 doesn't work when asking authoritative servers because they > > don't have a copy of the chain. > > You can set the start of the chain to the zone, so as long as any > chaining would remain within the zone or delegations on the same > server it could work. But perhaps that's stretching things too far. The scenario is that we are querying a parent zone's server, and we want to get the authenticated TLSA records for the target servers in the delegation NS records, so we can immediately talk securely to the child zone's servers. For chain queries to help, the parent zone auth servers would have to be willing to serve DNSKEY and TLSA records for all their child zones. Tony. -- f.anthony.n.finchhttp://dotat.at/ sovereignty rests with the people and authority in a democracy derives from the people ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers
Op 12-09-18 om 17:22 schreef Tony Finch: > Paul Wouters wrote: >> >> Then use RFC 7901 DNS chain queries (or the hopefully soon >> tls-dnssec-chain TLS extension) > > RFC 7901 doesn't work when asking authoritative servers because they > don't have a copy of the chain. > > tls-dnssec-chain will not help iterative resolvers because they will > already have obtained the chain in the process of locating the server > they want to authenticate. Not necessarily for out-of-bailiwick (or deep in-bailiwick) NS records with glue. If the tls-dnssec-chain would be obligatory for authoritative DoT servers, then any kind of signaling that DoT is available would be sufficient. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
