On Mon, 1 Mar 2021, Paul Hoffman wrote:
On Mar 1, 2021, at 5:36 AM, Eric Rescorla <[email protected]> wrote:
I don't necessarily object to having this be TLSA, but given that we are
standardizing
a record whose precise purpose is to signal what services are available at a
given
location, it seems to me natural to use that.
I can't fully parse the sentence.
+1. I used TLSA because PaulW had proposed it and no one objected to the
proposal, but a new purpose-built signal seems fine.
Note that I did not object to TLSA. I prefer it over SVCB. I don't think
it is realistiv for any new kind of glue record to be invented and that
seemed to have been the reason in the proposal to use SVCB? To serve
it at the parent side of the zone cut?
Another reason for SVCB was that you can define the transports in one
place, instead of having them _prefix'ed at different places for TLSA.
And as a method to specify DoH. I don't think these are an issue because
DoH is a bad fit for this solution anyway as previously discussed. So
it would be just querying for the DoT or DoQ port number per nameserver.
In the case of DNS it is clear that no one will disable port 53 if a
TLSA record is there, and I'm sure the final document will reflect
that.
Having said that, I'm a bit hesitant if that new signal also recreates TLSA
semantics for the public key, given how hard it was for the DANE WG to settle
on those, but maybe it won't be so rough this time (or maybe we can use TLSA
for the public key info).
If the DNSSEC PKI is used, I think the semantics for Usage and Selector
are obvious. In the case of WebPKI, it can be as weak as people want? Eg
putting a TLSA record there for the LetsEncrypt CA. I wouldn't limit it
to enforce it to be the Selector for SBKI.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
