On Mon, Mar 8, 2021 at 6:00 PM Puneet Sood <[email protected]> wrote:
> [late to the discussion, so putting my responses here instead of as > replies to various threads] > > * Use of SVCB vs TLSA for signaling secure transport support. > Preference for SVCB since it is specifically meant to represent > transport endpoints and could be extended to new transports, > additional info in the future (DoQ or others). > > * Publishing SVCB records in the parent zone in addition to the child zone. > The example used in the draft, shows an out-of-bailiwick SVCB record > returned by the parent nameserver in a response to the resolver. The > benefit of this is saving 1RTT to query the child zone and the > information being more trustworthy w/o depending DNSSEC in the child > zone. > > - This is the kind of record that a resolver will discard since it is > out-of-bailiwick. Best reference I could find is the description of > bailiwick in https://datatracker.ietf.org/doc/html/rfc8499. - Ignoring this issue, if the resolver were to accept the SVCB record > in glue from the parent zone, the information to be saved per zone -> > name server mapping will go up significantly since there is now an > SVCB record in addition to the NS record. If the SVCB information is > tied to the nameserver name, then it needs to be saved only once per > name server or name server set. > Yes, I would it expect it to use it for this request but not cache it. > * Use of DNSSEC vs WebPKI for authentication. > No opinion on this matter - leave it to experts on this topic. > > Clarification question for Eric: You have mentioned elsewhere in this > thread that you expect the protocol will allow both/either DNSSEC and > WebPKI to be used by an operator. Is the expectation that recursive > resolvers will support *both* mechanisms early on? Otherwise if a > resolver supported DNSSEC authentication only while the nameserver for > a zone supported WebPKI only, the two won't be able to communicate > securely. > I think we'd need to sort this out. The minimum requirement, I think, is to allow the SVCB record to indicate what the authoritative supports, so you don't get downgrade. If you have that, then both sides can vote with their feet and we can see what is most deployable. -Ekr > * Authenticating data from root. > For operators willing to do it, running a local root server > (https://www.rfc-editor.org/rfc/rfc8806.html) is a possible solution > to this problem. > > -Puneet > > On Tue, Feb 23, 2021 at 7:21 PM Eric Rescorla <[email protected]> wrote: > > > > Hi folks, > > > > I wanted to point people to a new draft by Tommy Pauly, David > > Schinazi, Chris Wood, and myself that defines a mechanism > > for authenticated resolver<->authoritative communication. > > > > At a high level, the design is to use SVCB to indicate that > > a given server supports ADo[THQ]. The expectation is that > > the SVCB record would be supplied in additional_data along > > with the NS records, allowing you to bootstrap to encrypted > > transport without incurring additional transport. More details > > in the draft, but a few points might be worth fleshing out > > here: > > > > - The basic assumption is that the transport to the parent [0] > > is encrypted, thus preventing attackers from substituting > > NS or SVCB [1]. > > > > - The draft is agnostic on how the authorative server, and > > is compatible with either TLSA or WebPKI, though there > > are some details to be worked out if we don't mandate > > one or the other. > > > > We missed the draft deadline, so in the meantime the draft can be > > found at: > > > > > https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html > > > https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.txt > > > > Comments welcome, etc. > > > > -Ekr > > > > [0] The root may be somewhat tricky here, but there are > > some thoughts in the draft. > > [1] For reasons laid out in the draft, if this isn't the > > case, I'm not sure it's possible to avoid leaking the name > > you are resolving, even with DNSSEC. > > _______________________________________________ > > dns-privacy mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
