Re: Quic: the elephant in the room

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Apr 12, 2021 at 11:59:58AM -0400, Phillip Hallam-Baker wrote:
> On Mon, Apr 12, 2021 at 11:51 AM Nico Williams <nico@xxxxxxxxxxxxxxxx>
> wrote:
> > On Mon, Apr 12, 2021 at 11:33:29AM -0400, Phillip Hallam-Baker wrote:
> > > Or replace the DNS resolver protocol with a privacy protected one
> > > in which a single request packet can be answered by multiple
> > > response packets.  This maintains the 'stateless' nature of DNS
> > > queries but allows responses of 1-32 packets.
> >
> > As long as it's not over UDP, or otherwise first has a return
> > routability check.
> 
> I don't follow.

"No magnification DDoS please"

> > > Then a query to the responder can return the A record, the AAAA
> > > record, the SRV record, any relevant TXT and TLSA records [...]
> >
> > Kinda like "any" queries.
> 
> Not quite because of 1) the interaction of prefixes and 2) you only
> need data for the one host you connect to.

Thus "kinda" :)

> > >                                         [...] and the entire cert
> > > chain for one particular host chosen by the responder.
> >
> > You get better security properties (w.r.t. possible compromised root
> > or ccTLD/TLD keys) if the resolver finds the DNSSEC chain on its own
> > using qname minimization than you get with stapling, but I agree
> > that stapling is a performance win.  We'll really want transparency
> > for DNSSEC if we do any kind of full chain stapling.
> 
> SCVP introduced a distinction between path discovery and path
> validation.  Both can be very useful.

Yes, exactly.  But for PKIX path discovery is not possible without
directories, but DNS _is_ a directory, so you get to do path discovery.
And unlike PKIX, there is only one possible path (well, at most as many
paths as there are labels in the domainname, minus 1, plus any sub-paths
due to CNAME RR chasing).

> If you have a low level IoT device, you are probably better off doing
> path math properly in one trusted device in your network than relying
> on whatever embedded code is running in your toaster.

Absolutely.  There is a trade-off to make.  Low-power && low-value RPs
should prefer stapling, or even a local caching recursive resolver to do
all the lookups and signature verification too.

Nico
-- 




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux