On Thu, 25 Feb 2021, Eric Rescorla wrote:
There are (at least) three reasons:
1. Semantically, TLSA does not mean "I support TLS", but rather "if you are to
do TLS, do it this way. SVCB means something
different.
We tried hard to make it mean "You should only use TLS", but the webpki
people freaked out and blocked the DANE WG until this compromise was
reached. In my opinion, any client that publishes TLSA records for a
service means that you should reach it over TLS and hard-fail. No
one really means "you may do TLS but if insecure cleartext is your cup
of tea, that's fine with me too".
No, because there are existing deployments, so we can't just retcon the meaning.
That would be the retcon of "If you can do TLS, please prefer TLS over
insecure cleartext" instead of the original meaning "This is my TLS. It
is secure but you are welcome to use this completely insecure
version instead - I claim no preference"
In any case, it's quite different to have the TLSA records in the parent and in
the server, because the server can ensure they don't get
out of sync with itself in a way that is harder than with the parent.
Also, the parent is really the wrong location. For libreswan.org, the
nameserver is ns0.nohats.ca and the parent is .org. Clearly, if
ns0.nohats.ca does TLS, there is no way scalable automated way for
ns0.nohats.ca to tell the .org registry anything. At best, you can
do something with CDS/DS or CDNSKEY/DNSKEY in the zone that communicates
to the parent. But this uptake so far as been non-existig. I don't
see why SVCB would do better. It has all the same problems, in addition
of requiring new DNS Auth server code to be deployed to add SVCB as
either glue records (hard) or as authenticated at the parent records,
which is even harder, because it requires changes to all DNS resolver
code similar to DS - the only child record in existence today that
lives at the parent's side of the zone cut.
All these have been discussed before, and the conclusion was really
that the only way to do this is to either:
1) make it a nameserver name record, not a record that lives at the
paret dns zone.
2) encode 1) using a DS and hope automated CDS starts happening for
this soon.
2. SVCB does not just let you signal DoH versus DoT it also allows
you to signal DoQ, which has obvious
advantages.
TLSA also lets you signal DoQ. If it didn't, we would have rejected it out of
hand.
DoQ didn't exist when TLSA was done. TLSA records are discovered based
on their port. If DoQ uses a standard port, then TLSA can be used. You
would have a TLSA for DoQ and a TLSA for DoT. It would not be possible
to do DoH, but as people said, nameserver IP's are public knowledge and
easilly blocked, there is no advantage to using DoH here at all anyway.
I think it depends what you mean by "signal". TLSA can signal the certificate
which is to be expected for a QUIC connection, but AFAICT
it has no way to indicate that the server supports QUIC, whereas with SVCB you
can do this with ALPN (h3, doq). Your draft has a TODO
here, so I'm not sure what you have in mind.
Yes it does. Let's say DoQ gets ports 453. Your nameserver's DoQ TLSA
would be:
_doq._453.ns0.nohats.ca. IN TLSA 3 1 <Base64BLOB>
And your DoT would be;
_dot._853.ns0.nohats.ca. IN TLSA 3 1 <Base64BLOB>
If people dislike that you have multiple DNS queries to find these
services, you could use something like:
_dns.ns0.nohats.ca. IN TLSA 3 1 <Base64BLOB>
And then within the certificate encode a EKU or SAN in a standarized way
to relay the ports and protocols for encrypted DNS offered.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
