On Wed, Feb 24, 2021 at 7:26 AM Paul Wouters <[email protected]> wrote: > On Tue, 23 Feb 2021, Eric Rescorla wrote: > > > 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: > > > > https://ekr.github.io/draft-rescorla-dprive-adox/draft-rescorla-dprive-adox.html > > The idea seems fine. I guess the advantage of SVCB over TLSA is > that you can define the transport, which is a clear advantage > over trying to figure out which transport to try first, or trying > them all at once. > > The disadvantage of using SVCB is that, at least for DNSSEC, you > would need to use another lookup to get the TLSA record. But that > is mitigated when using the TLS tls-dnssec extension. >
Right. That is my assumption. > You talk about adding SVCB to the additional data, but in practise > authoritative prefer small lean answers these days to avoid > amplification attacks, so I'm not sure if this is a reasonable > assumption of the future. A basic assumption here is that you are doing TLS to the referring authoritative. Otherwise things kind of fall apart for reasons laid out in the security considerations. So in this case I would assume that amplification is much less of an issue. > > - The basic assumption is that the transport to the parent [0] > > is encrypted, thus preventing attackers from substituting > > NS or SVCB [1]. > > SVCB is not served by the parent right? You mean the substitution > would be in a second step after substituting the NS records? > I was assuming SVCB was served by the parent in additional_data. But as a practical matter, substituting NS works as well. > Although an attacker with those powers can probably more easilly > just redirect IP that the NS records point to, so it does not need > to sit in the middle of the connection to the parent. > Agreed. > And the defense against this is of course verifying any NS record > using the signed DS record at the parent and confirming the records at > the child. This costs an extra lookup but gains you security. Does that work for this case? My reasoning was that it was too late. For instance, you're looking up example.com and you receive NS=ns.attacker.example. At this point (1) the attacker knows you want example.com and (2) you then have to query ns.attacker.com for the signed NS records, so ns.attacker.com learns it (even if you didn't already know). So this is useful for concealing whether you want a.example.com or b.example.com, but not if the only domains anyone wants are www.example.com and example.com, right? -Ekr
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
