Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers
On Wed, 12 Sep 2018, Tony Finch 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. 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. 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: > > 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. Tony. -- f.anthony.n.finchhttp://dotat.at/ Rockall, Malin, Hebrides, Bailey, Fair Isle: West or southwest, becoming cyclonic in Bailey, 5 to 7, increasing gale 8 at times. Rough or very rough, occasionally moderate. Squally showers, thundery at times except in Rockall and Malin. Good, occasionally poor except in Rockall and Malin. ___ 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
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 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 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. > > 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. If you received the TLSA glue from an authenticated DoT authoritative in a referral, perhaps you do not need the RRSIG? 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 ? -- Willem > > > -Ilari > > ___ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy > ___ 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
Erik Kline wrote: > On Wed, 12 Sep 2018 at 15:38, Shane Kerr wrote: > > > > Note that we can also use the RTT of this query to set a reasonable > > timeout for our port 853 traffic. A DNS server administrator may have > > configured port 853 support, but the network administrator may block > > this port for portions of the network or may later block this port. So > > we still need probing and a timeout - but it can be quite low in most cases. Right, there will need to be some careful client-side engineering. > One thing a client might do with a positive TA bit and failed > connections to 853 is present that information to the user and ask for > confirmation they'd still like to use the network. That might be > useful, or might lead to confusion, idk. Seems worth trying, though. Yes, the TA bit will (inevitably) sometimes be wrong. My idea is that during the rollout phase it is probably worth having a TA bit so resolvers can avoid probing 853 when it is definitely futile. If TA=1 and 853 doesn't work then it'll probably be slower to resolve that server's domains, which is about the right level of breakage. (TA is a hint not a security feature.) > > I don't follow why the registries need to be involved with DANE for > > DNS-over-TLS any more than they do with HTTP-over-TLS or SMTP-over-TLS. > > Can you maybe try to explain more? 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. To some extent it also closes a privacy leak since it makes it easier for the resolver to query the child zone's servers without exposing which child zone it is asking about. > Exposing my considerable ignorance here (as usual), but can a TLSA > record be added for the in-addr.arpa/ip6.arpa name of a given > nameserver IP? Possibly... I think it was the DoH session at IETF 101 where a bunch of people got up to say that it's futile to expect the reverse DNS to be useful. It is perhaps less of a disaster area for mail server and maybe DNS server IP addresses. But it's shaky territory. The advantage in this context is that it might allow us to work around the problem of authoritative servers with lots of different names in NS targets. You could authenticate DoT to the server regardless of name by putting the TLSA record in the reverse DNS. Another disadvantage is that it might be a bit slow, because you can't look up the reverse DNS TLSA until after you have got the address records (rather than being able to look them up concurrently). On the gripping hand, since we can't include TLSA records in glue, the choice is between a followup query to get the TLSA records from the child zone, or from the reverse DNS, so the performance difference boils down to how quickly the resolver can iterate down the reverse DNS. Perhaps it makes sense to search for TLSA in both forward and reverse? Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher: West, backing southwest later, 5 to 7, occasionally gale 8 at first. Moderate or rough. Showers later. Good. ___ 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
Tony, On 2018-09-10 16:48, Tony Finch wrote: Opportunistic TLS - The only mechanism we have is to probe port 853 and fall back to 53 if TLS isn't available. This is fraught with problems since in many cases firewalls will drop packets to port 853 rather than promptly returning ICMP errors. > Suggestion: TA flag, "TLS available" It might be worth adding an EDNS flag to advertise the availability of TLS (only meaningful in responses, like the RA flag). This might mitigate the worst auto-probing latency problems. This is kind of by analogy to SMTP servers advertising STARTTLS in their EHLO response. This seems reasonable, at the cost of sending *some* unencrypted traffic. Note that we can also use the RTT of this query to set a reasonable timeout for our port 853 traffic. A DNS server administrator may have configured port 853 support, but the network administrator may block this port for portions of the network or may later block this port. So we still need probing and a timeout - but it can be quite low in most cases. Suggestion: DANE for DoT This is similar to the SMTP situation, so how far can we get by applying a similar solution? That is, use DANE TLSA records to advertise that: * this nameserver supports TLS, and * resolvers can authenticate it strictly. For example, newton.ac.uk. NS auth0.dns.cam.ac.uk. ... auth0.dns.cam.ac.uk. A 131.111.8.37 auth0.dns.cam.ac.uk. A 2a05:b400:d:a0::1 _853._tcp.auth0.dns.cam.ac.uk. TLSA 1 1 1 ( ... ) (This is basically the same as a SPKI pinset but with a different encoding.) A nice thing about this is that the resolver can find out the auth server's DoT details at the same time as it finds out its addresses, so there's no need for slow protocol negotiation. I like it. Caveats of unusual size --- Unfortunately, when we consider in-bailwick delegations, we soon realise that we have strayed into a fire swamp. Ideally (to minimize latency) when following a referral to a zone with DoT auth servers, we would get everything we need in one response, including TLSA records as a new kind of glue record. I believe there aren't any big obstacles from the DNS protocol point of view (including AXFR and UPDATE etc.) to adding new kinds of glue record. However, to make TLSA glue useful, it also needs to be supported by registry databases, by EPP, and by registrar user interfaces. That'll take considerably more than a million times longer than getting out of the lightning sand. I don't follow why the registries need to be involved with DANE for DNS-over-TLS any more than they do with HTTP-over-TLS or SMTP-over-TLS. Can you maybe try to explain more? -- Shane ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
