Re: Quic: the elephant in the room

[Michael Thomas <[e-mail]>]

On 4/12/21 8:33 AM, Phillip Hallam-Baker wrote:
>
>
> On Mon, Apr 12, 2021 at 11:22 AM Michael Thomas <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     On 4/12/21 3:36 AM, Andrew McConachie wrote:
>     >
>     >
>     > When looking at how one might implement DANE for HTTPS/TLS I
>     don’t see
>     > any reason to handle these things sequentially. You don’t have to
>     > change TLS you just have to do things asynchronously. Query for
>     TLSA
>     > RRs at the same time as sending the TLS ClientHello, and kill the
>     > connection setup when/if DANE validation fails. On the off
>     chance that
>     > the DNS actually takes longer than TLS, maybe delay sending data
>     via
>     > TLS until DNS responds. But I bet this almost never happens.
>     >
>     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.
>
> Then introduce a new DNS query for 'tell me how to connect to protocol 
> X at name Y'
>
> Then a query to the responder can return the A record, the AAAA 
> record, the SRV record, any relevant TXT and TLSA records and the 
> entire cert chain for one particular host chosen by the responder.
>
I really have no desire to boil the ocean. My post was something that is 
actually achievable with existing protocols with and achievable by way 
of many browser vendors having the capability of implementing those 
protocols on their front and backends. That was its entire point: it's 
achievable in the here and now.

Mike