On Mon, Aug 7, 2023 at 2:50 PM Jonathan Lennox <jonathan.len...@8x8.com> wrote:
> > > On Aug 6, 2023, at 5:22 PM, Rob Sayre <say...@gmail.com> wrote: > > On Sun, Aug 6, 2023 at 2:14 PM Eric Rescorla <e...@rtfm.com> wrote: > >> Sure. Though with that said, DTLS-SRTP should use the same code points >> for 1.2 and 1.3, so I don't actually know if this is an exception after all. >> > > I think the issue is still there in a spec lawyer kind of way. So, after > this draft is published, would we say a new DTLS-SRTP cipher suite is > defined for use in DTLS 1.2? > > That seems like the goal of the Github issue. > > > That was indeed the goal of my initial Github issue, but on further > reflection, I’m more concerned. > > As Achim’s mail indicated, as far as I know wolfSSL is the only library > currently with a released DTLS 1.3 implementation, and many of the other > common TLS libraries — most notably including the OpenSSL family — don’t > seem to have any current plans to do so. > > If this situation doesn’t change before we need PQ KEMs to enter > production, then there’ll be no way to protect DTLS-protected traffic — > notably including WebRTC and other DTLS-SRTP traffic — from > harvest-now-decrypt-later attacks. > > Hopefully the eventual need for PQ support will incentivize stack > developers to work on DTLS 1.3, but I’m worried. > > I don’t know if this would warrant actually defining PQ KEMs for DTLS 1.2 > — will stack implementors implement that if they won’t do DTLS 1.3? — but > it’s something to think about. > These seem like good reasons for stack implementors to do DTLS 1.3. -Ekr > > > -Ekr >> >> >> On Sun, Aug 6, 2023 at 1:59 PM Rob Sayre <say...@gmail.com> wrote: >> >>> On Sun, Aug 6, 2023 at 11:48 AM Eric Rescorla <e...@rtfm.com> wrote: >>> >>>> >>>> >>>> On Sun, Aug 6, 2023 at 9:58 AM Rob Sayre <say...@gmail.com> wrote: >>>> >>>>> There's also the fact that the TLS 1.3 was published in August 2018, >>>>> but DTLS 1.3 wasn't published until April 2022. So, it is kind of >>>>> reasonable to allow some extra time here. >>>>> >>>>> The WG could say this document doesn't apply to DTLS. Another choice >>>>> would be to say that it does apply to DTLS, but the WG will continue to >>>>> accept work for DTLS 1.2 that is DTLS-specific. The aim here being that >>>>> DTLS is not used as an excuse to continue to work on 1.2. >>>>> >>>> >>>> This seems like a fine proposal. However, as a practical matter, there >>>> are very few changes one could make to DTLS that would not also apply to >>>> TLS, so aside from DTLS-SRTP cipher suites, I'm not sure how much >>>> difference it makes. >>>> >>> >>> Makes sense, let's just not try to prove a negative in insisting that >>> DTLS-SRTP cipher suites are the only such thing. >>> >>> "Further, TLS 1.3 use is widespread, and new protocols should require >>> and assume its existence. DTLS 1.3 is a newer specification. New >>> algorithms or extensions that apply solely to DTLS, such as DTLS-SRTP >>> cipher suites, will be considered for DTLS 1.2." >>> >>> thanks, >>> Rob >>> >>> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
