On Mon, Mar 1, 2021 at 8:32 AM Paul Wouters <[email protected]> wrote: > On Mon, 1 Mar 2021, Eric Rescorla wrote: > > > Rephrased: TLSA might work, but given that SVCB is designed for this > purpose, > > my prior is to favor it. > > Thanks, that clarified it for me. > > > > +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? > > > > I do think serving this at the parent side of the zone cut is a good > idea, > > but that's not the reason for SVCB. > > You would need to write an RFC for the EPP extension. You would need to > wait > for most TLD's EPP systems to support this new record. Then you need to > wait for Registrars to update their EPP software. Then you need to wait > for Resellers like OpenSRS to update their software to resellers. >
> Then you need to write an RFC on adding SVCB records to a parent zone so > that current DNS software doesn't immediately reject it as out-of-zone > data. Then you need to push opensource implementors. Then you need to > push TLDs to deploy, and the big DNS appliance vendors. Then you have to > wait for old DNS products to be updated or replaced at the enterprise. > > That's a 5-10 year time line. You would need an interim solution. If you > have such a solution, there is even less incentive to get this work done. > This seems like something to discuss live in the session, but at a high level, one doesn't need universal deployment to get value here. Given the relative concentration of both a small number of high value TLDs and large-scale authoritative nameservers, we should be able to get *some* encryption fairly quickly even if the long tail takes a while. > > As has been discussed extensively, the general feeling among people who > work with > > the WebPKI is that pinning has turned out to be a bad idea. For this > reason, it's > > important to be able to have an available way to say "just use the > WebPKI", even > > if it's also possible to be more specific. > > DNS is not the web. DNSSEC already "pins" via the DS record in a > hierarchical way with DNSKEYs. Adding another public key here is > not that different. > Given the low rate of DNSSEC deployment and the high rate of misconfiguration (https://dl.acm.org/doi/pdf/10.1145/3131365.3131373) I don't find this particularly encouraging. > Reducing the hierarchical security of DNS (with or without DNSSEC) by > replacing it with what is defacto the LetsEncrypt Root CA seems a bad > idea. If you plan to use this new sentinel without any kind of public > key, then this proposal is yet another workaround to hack WwebPKI into > somewhere where it doesn't belong or fit, and I must object. > Sounds like a good discussion to have in the meeting. I'm not sure why this has to be a war between WebPKI and DNSSEC. Our for this draft is to give the nameserver the choice of how to authenticate, I appreciate that you feel that it would be better to root the security of ADoT in DNSSEC, but given that we effectively have no ADoT now, ISTM that our first priority should be to get some. If that turns out to be substantially easier to deploy with WebPKI, then that's what we should do. If on the other hand, rooting it in the DNSSEC turns out to be better, then we should do that. Specifying a mechanism which allows people to do both will let us find out, rather than letting the best be the enemy of the good. -Ekr
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
