Re: Quic: the elephant in the room

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Apr 12, 2021 at 11:51 AM Nico Williams <[e-mail]>
wrote:

> On Mon, Apr 12, 2021 at 11:33:29AM -0400, Phillip Hallam-Baker wrote:
> > On Mon, Apr 12, 2021 at 11:22 AM Michael Thomas <[e-mail]> wrote:
> > > Correct. Better: you can do the TLSA request at the same time as the
> > > A/AAAA request speculatively. Plus if you've ever had a TLSA record for
> > > that domain, you know it's pretty likely you'll get a fresh one even if
> > > the last one is expired, so the speculation is minimal.
> >
> > 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.



> > 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.




> >                                         [...] 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.

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.

For other cases, it is much easier to check path math than to work out a
valid chain. All you need to do to check is to pull the signature record
out of each cert in the chain, pull the key record out of the previous
record and check the sig over the toBeSigned block, then check for any
constraints. Discovery requires backtracking and constraints are really
hard.