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.


-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

Reply via email to