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:51 AM Nico Williams <nico@xxxxxxxxxxxxxxxx> 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 <mike@xxxxxxxx> 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. 

 

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

  Powered by Linux