Servers using DNSSEC won't help unless the client only honors the hint over DNSSEC, and we do not live in a universe where DNSSEC succeeded to the point that that's remotely viable.
I think that too can be discussed in detail post adoption, but I think such a change would negate the value of this whole draft. On Tue, May 21, 2024, 09:56 A A <tom25...@yandex.com> wrote: > In my opinion, to prevent downgrade attack, server MUST or SHOULD using > DNSSEC when announcing DNS record. > > > 21.05.2024, 21:48, "David Benjamin" <david...@chromium.org>: > > Off the cuff, folding it into the transcript sounds tricky, since existing > TLS servers won't know to do it, and, as with any other DNS hints, we need > to accommodate the DNS being out of sync with the server. It'll also be > more difficult to deploy due to needing changes in the TLS stack and > generally require much, much tighter coordination between DNS and TLS. I'd > like for that coordination to be more viable (see my comments on the > .well-known draft), but I don't think we're there yet. > > But I'm certainly open to continue discussing it and this problem space! > The original version of the draft actually tried a lot harder to handle the > downgrade story. Rather than mess with the transcript, it defined away all > the negotiation algorithms where this would be a problem and keyed the > NamedGroup codepoints to know when you could be guaranteed of the narrower > server behavior. > > My read of the feedback was that people thought this was an unnecessary > complication and that servers doing a key-share-first selection were doing > so intentionally because they believed the options roughly equivalent. So I > took all that out and replaced it with text to that effect. > > David > > > On Tue, May 21, 2024, 08:54 Eric Rescorla <e...@rtfm.com> wrote: > > I agree that it's attractive to be able to hint in the HTTPS RR, but I'm > less sure about addressing the basic insecurity of the DNS channel with the > approach this draft takes. I don't have a complete thought here, but what > if we were to somehow fold the hint into the handshake transcript? I > suppose we can sort this out post-adoption, but I'd like the question to be > on the table. > > -Ekr > > > On Fri, May 3, 2024 at 3:05 PM Joseph Salowey <j...@salowey.net> wrote: > > This is a working group call for adoption > for draft-davidben-tls-key-share-prediction. This document was presented > at IET 118 and has undergone some revision based on feedback since then. > The current draft is available here: > https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/. > Please read the document and indicate if and why you support or do not > support adoption as a TLS working group item. If you support adoption > please, state if you will help review and contribute text to the document. > Please respond to this call by May 20, 2024. > > Thanks, > > Joe, Deidre, and Sean > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > > , > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
