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