Re: [dns-privacy] Sketchy notes on DNS-over-TLS to authoritative servers
Martin Hoffmann wrote: > > Downgrade seems to be an issue with all proposals. The tradeoffs seem to revolve around how much you leak before you work out whether you can use strict DoT, and how much added latency that costs. If you are talking to a nameserver via its canonical name, then asking for its TLSA record in the clear is not really leaking anything that isn't leaked by observing IP addresses and port numbers. And signed TLSA records prevent downgrade attacks. The other side of this tradeoff is the whole argument around gluelessness vs. in-bailiwick namesserver names. If you give your servers non-canonical in-bailiwick names then cleartext TLSA queries will leak the zone name, which is not so great. TA hints in the nameserver name can reduce the leakage to passive surveillance but not downgrade attacks. > One option is to create a hash over the NS record set and place it in the > parent zone in the same way as the DS record. This could either be a new > record type or, devious but possibly deployable right now, (ab)use the DS > record for the purpose with a new algorithm type. That's a neat hack and also quite disgusting :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher, German Bight: South 5 or 6, occasionally 7 later. Slight or moderate. Showers. 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 Finch wrote: > > I think signalling in the hostname has to be a hint rather than an > assertion, since it's vulnerable to a downgrade attack because delegation > NS records are unsigned (as Robert pointed out). Downgrade seems to be an issue with all proposals. To solve them, there may need to be something signed by the parent as part of the delegation data. One option is to create a hash over the NS record set and place it in the parent zone in the same way as the DS record. This could either be a new record type or, devious but possibly deployable right now, (ab)use the DS record for the purpose with a new algorithm type. Kind regards, Martin ___ 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
Warren Kumari wrote: > > If the NS records / labels were _ta.a.iana-servers.net and _ > ta.b.iana-servers.net, that could be used as a positive signal that the > resolver (or if the underscore freaks people out, > dns-o-tls.a.iana-servers.net) is listening on 853 and that an inability > to connect is a security issue. Several people seem to quite like this kind of idea, and I think it's a good way to reduce latency (since we have to assume that better glue isn't an option). e.g. Willem and Andreas in https://www.ietf.org/mail-archive/web/dns-privacy/current/msg02137.html Regarding the specifics, NS targets are hostnames so they have to conform to RFC 952 syntax (no underscores). I think signalling in the hostname has to be a hint rather than an assertion, since it's vulnerable to a downgrade attack because delegation NS records are unsigned (as Robert pointed out). Putting the hint in the NS name I think makes the TA bit redundant - it's really too late to be helpful. Tony. -- f.anthony.n.finchhttp://dotat.at/ Southeast Fitzroy: Southwesterly 5 to 7. Slight or moderate becoming rough or very rough. Mainly fair. Good, occasionally poor. ___ 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
Warren Kumari wrote: > I'd also like to point out another option -- I threw up a little when first > suggesting it, but it may be worth considering again (and please feel free > to point me at the list if it already was). > An opportunistic solution is vulnerable to intentional (or accidental) > blocking, causing a fallback to unencrypted -- blocking of port 853, stupid > middleboxes, etc. You also cannot try just do both 53 and 853 in parallel, > because, well, that would just be stupid. Why is trying 53 and 853 in parallel stupid? You can cache whether the port 853 attempt succeeded or not for a long time, perhaps even in non-volatile storage, and this will end up suppressing a huge amount of future unsuccessful connection attempts. Even with a few million authoritative nameserver IP addresses the amount of storage required is pretty low. > When resolving www.example.com, the com servers have already provided you > with: > dig +nocomment ns example.com > > example.com.86383 IN NS a.iana-servers.net. > example.com.86383 IN NS b.iana-servers.net. > a.iana-servers.net. 172783 IN A 199.43.135.53 > b.iana-servers.net. 172783 IN A 199.43.133.53 > a.iana-servers.net. 172783 IN 2001:500:8f::53 > b.iana-servers.net. 172783 IN 2001:500:8d::53 > > The NS records here are signed and dnssec verifiable (the glue isn't, but > that is a separate fight). No? The delegation NS records served by the com servers are not authoritative and are not signed. The only signed material you get from that transaction is the RRSIG covering the DS RRset, right? You would still need to contact the example.com servers with a separate NS query to DNSSEC-validate any signals encoded in NSDNAMEs. -- Robert Edmonds ___ 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 Mon, Sep 10, 2018 at 10:48 AM Tony Finch wrote: > In the most general terms, when upgrading a protocol from cleartext to > TLS, there are a couple of questions the client has to answer: > > 1. Does this server support TLS? > 2. How can I authenticate it? > > And there are a couple of approaches to answering them: > > A. opportunistic > B. explicit > > Opportunistic protocols are easier to set up, but they only answer > question 1 (leaving 2 implicit); whereas explicit protocols are about > publising an answer to question 2, which implies answer 1 is yes. > > > Opportunistic TLS > - > > The only mechanism we have is to probe port 853 and fall back to 53 if > TLS isn't available. > > I'd also like to point out another option -- I threw up a little when first suggesting it, but it may be worth considering again (and please feel free to point me at the list if it already was). An opportunistic solution is vulnerable to intentional (or accidental) blocking, causing a fallback to unencrypted -- blocking of port 853, stupid middleboxes, etc. You also cannot try just do both 53 and 853 in parallel, because, well, that would just be stupid. When resolving www.example.com, the com servers have already provided you with: dig +nocomment ns example.com example.com.86383 IN NS a.iana-servers.net. example.com.86383 IN NS b.iana-servers.net. a.iana-servers.net. 172783 IN A 199.43.135.53 b.iana-servers.net. 172783 IN A 199.43.133.53 a.iana-servers.net. 172783 IN 2001:500:8f::53 b.iana-servers.net. 172783 IN 2001:500:8d::53 The NS records here are signed and dnssec verifiable (the glue isn't, but that is a separate fight). If the NS records / labels were _ta.a.iana-servers.net and _ ta.b.iana-servers.net, that could be used as a positive signal that the resolver (or if the underscore freaks people out, dns-o-tls.a.iana-servers.net) is listening on 853 and that an inability to connect is a security issue. so: example.com.86383 IN NS _ta.a.iana-servers.net. example.com.86383 IN NS _ta.b.iana-servers.net. _ta.a.iana-servers.net. 172783 IN A 199.43.135.530 _ta.b.iana-servers.net. 172783 IN A 199.43.133.53 This works in a backward compatible manner - non-dprive servers don't care what the nameservers are "called", dprive servers can use the nameserver label as a signal. Yes, you could make the argument that this is a icky (and I won't disagree), or that eventually we would end up with this being abused into _ta._foo._bar._I_like_cheese._ your_father_smells_of_elderberries.ns23.example.com -- but, I still think it is worth considering... W > This is fraught with problems since in many cases firewalls will drop > packets to port 853 rather than promptly returning ICMP errors. > > It will be useful for resolvers to keep a cache of which auth servers > support TLS (with TLS session resumption data for those that do). > > > 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. > > > Authentication mess > --- > > If an auth server supporting TLS has a name in its certificate > matching the target name of the NS record that was used to find it, > then the implicit answer to question 2 is "just use PKIX certificate > validation". > > However, it's relatively common for NS records to use unofficial > target names. For example, DJB's comments on gluelessness and his > recommendation for delegations to be in-bailiwick with glue: > > https://cr.yp.to/djbdns/notes.html > > This means that opportunistic DoT for a popular authoritative server > is likely to run into certificate validation problems, so > opportunistic TLS can only be safe against passive snooping not active > interception. > > > 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. > > > Caveats of unusual
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
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
