On Mon, Aug 7, 2023 at 9:27 PM Eric Rescorla wrote:
> On Mon, Aug 7, 2023 at 2:50 PM Jonathan Lennox
> wrote:
>
>> On Aug 6, 2023, at 5:22 PM, Rob Sayre wrote:
>>
>> On Sun, Aug 6, 2023 at 2:14 PM Eric Rescorla 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.
>
Agreed. BoringSSL has not yet implemented DTLS 1.3, but we don't consider
this a reason to backport PQ KEMs to (D)TLS 1.2. The right path for PQ KEMs
in DTLS is DTLS 1.3. When we go to add PQ KEMs to our DTLS uses, we'll take
that route.
As a practical matter, PQ KEMs in (D)TLS 1.2 is messier than it sounds.
ECDHE ServerKeyExchange and ClientKeyExchange have too short of length
prefixes. Our original CECPQ1 experiment, which predated TLS 1.3, had to
define new cipher suites to get around this. Also keep in mind that,
whether it's 1.2 or 1.3, getting to PQ KEMs (or any other new (D)TLS
feature) will require updating client and server software regardless. The
existing DTLS 1.2 + no PQ deployment will not magically become PQ-ready if
we do a backport.
> -Ekr
>
>
>>
>>
>> -Ekr
>>>
>>>
>>> On Sun, Aug 6, 2023 at 1:59 PM Rob Sayre wrote:
>>>
On Sun, Aug 6, 2023 at 11:48 AM Eric Rescorla wrote:
>
>
> On Sun, Aug 6, 2023 at 9:58 AM Rob Sayre 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
