Re: [TLS] Question about DTLS for the "no new features" draft

[Achim Kraus]

(My guess is that most would-be DTLS 1.3 implementors are off
working on QUIC; that’s certainly the case of OpenSSL.)


My guess is that many companies, which have been interested in
secure IoT device communication, are now focus on AI and not QUIC.

For hobby developers it maybe a little too much work,
to implement DTLS 1.3 in the free time. But that also
applies for DTLS 1.2 extensions with higher development
effort, not only for a general switch to DTLS 1.3.

best regards
Achim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Question about DTLS for the "no new features" draft

[Rob Sayre]

> "Salz, Rich"  wrote:
> I think David’s concern about doing quantum-safe crypto in 1.2 makes a
lot of sense. But we can wait until it happens before doing anything.

Yep. The other way to read it is "this will never happen". We can find out
later, but there's no argument habitat in the meantime.

Fully support eliding DTLS 1.2 concerns.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Question about DTLS for the "no new features" draft

[Salz, Rich]

I understand that DTLS 1.3 doesn’t have many implementations yet, and that it 
is therefore premature to say that DTLS 1.2 gets no new features. (My guess is 
that most would-be DTLS 1.3 implementors are off working on QUIC; that’s 
certainly the case of OpenSSL.)

I think David’s concern about doing quantum-safe crypto in 1.2 makes a lot of 
sense. But we can wait until it happens before doing anything.

Since RFC 8996 says: “This document also deprecates Datagram TLS (DTLS) version 
1.0 (RFC 4347) but not DTLS version 1.2, and there is no DTLS version 1.1.” I 
think the draft should explicit say “This document says nothing about DTLS”

At least that’s what the next version will say and the WG can hack away if they 
want.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Question about DTLS for the "no new features" draft

[David Benjamin]

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

Re: [TLS] Question about DTLS for the "no new features" draft

[Eric Rescorla]

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.

-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

Re: [TLS] Question about DTLS for the "no new features" draft

[Jonathan Lennox]

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.


-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

Re: [TLS] Question about DTLS for the "no new features" draft

[Rob Sayre]

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.

thanks,
Rob



> -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

Re: [TLS] Question about DTLS for the "no new features" draft

[Eric Rescorla]

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.

-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

Re: [TLS] Question about DTLS for the "no new features" draft

[Rob Sayre]

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

Re: [TLS] Question about DTLS for the "no new features" draft

[Eric Rescorla]

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.

-Ekr


>
> thanks,
> Rob
>
>
> On Sun, Aug 6, 2023 at 8:28 AM Achim Kraus  wrote:
>
>> I don't have a complete overview, but AFAIK:
>>
>> - wolfSSL (C) has DTLS 1.3
>>
>> - mbedTLS (C) for now doesn't support it
>>
>> - pion/dtls (GO) for now doesn't support it
>>
>> - Eclipse/tinydtls (C) doesn't support it
>>
>> - Eclipse/Californium (Java) doesn't support it
>>
>> best regards
>> Achim
>>
>> Am 06.08.23 um 17:01 schrieb Salz, Rich:
>> > Quoting https://github.com/richsalz/tls12-frozen/issues/7
>> >  raised by Jonathan
>> > Lennox, in its entirety:
>> >
>> > “Given the slow progress of implementations of DTLS 1.3, I think this
>> > draft needs to be clear that this feature freeze applies only to TLS 1.2
>> > proper, not DTLS 1.2.
>> >
>> > “For example, I would be very sad if any new DTLS-SRTP protection
>> > profiles could only be negotiated with DTLS 1.3.
>> >
>> > “This may have implications for the IANA instructions section, for
>> > registries that are shared between the two protocols.”
>> >
>> > Does the WG have any vews?  I know OpenSSL isn’t doing DTLS 1.3 right
>> > now, but is the industry overall lagging? Should we allow changes to
>> > DTLS 1.2?
>> >
>> >
>> > ___
>> > 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
>>
> ___
> 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

Re: [TLS] Question about DTLS for the "no new features" draft

[Rob Sayre]

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.

thanks,
Rob


On Sun, Aug 6, 2023 at 8:28 AM Achim Kraus  wrote:

> I don't have a complete overview, but AFAIK:
>
> - wolfSSL (C) has DTLS 1.3
>
> - mbedTLS (C) for now doesn't support it
>
> - pion/dtls (GO) for now doesn't support it
>
> - Eclipse/tinydtls (C) doesn't support it
>
> - Eclipse/Californium (Java) doesn't support it
>
> best regards
> Achim
>
> Am 06.08.23 um 17:01 schrieb Salz, Rich:
> > Quoting https://github.com/richsalz/tls12-frozen/issues/7
> >  raised by Jonathan
> > Lennox, in its entirety:
> >
> > “Given the slow progress of implementations of DTLS 1.3, I think this
> > draft needs to be clear that this feature freeze applies only to TLS 1.2
> > proper, not DTLS 1.2.
> >
> > “For example, I would be very sad if any new DTLS-SRTP protection
> > profiles could only be negotiated with DTLS 1.3.
> >
> > “This may have implications for the IANA instructions section, for
> > registries that are shared between the two protocols.”
> >
> > Does the WG have any vews?  I know OpenSSL isn’t doing DTLS 1.3 right
> > now, but is the industry overall lagging? Should we allow changes to
> > DTLS 1.2?
> >
> >
> > ___
> > 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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Question about DTLS for the "no new features" draft

[Achim Kraus]

I don't have a complete overview, but AFAIK:

- wolfSSL (C) has DTLS 1.3

- mbedTLS (C) for now doesn't support it

- pion/dtls (GO) for now doesn't support it

- Eclipse/tinydtls (C) doesn't support it

- Eclipse/Californium (Java) doesn't support it

best regards
Achim

Am 06.08.23 um 17:01 schrieb Salz, Rich:

Quoting https://github.com/richsalz/tls12-frozen/issues/7
 raised by Jonathan
Lennox, in its entirety:

“Given the slow progress of implementations of DTLS 1.3, I think this
draft needs to be clear that this feature freeze applies only to TLS 1.2
proper, not DTLS 1.2.

“For example, I would be very sad if any new DTLS-SRTP protection
profiles could only be negotiated with DTLS 1.3.

“This may have implications for the IANA instructions section, for
registries that are shared between the two protocols.”

Does the WG have any vews?  I know OpenSSL isn’t doing DTLS 1.3 right
now, but is the industry overall lagging? Should we allow changes to
DTLS 1.2?


___
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

[TLS] Question about DTLS for the "no new features" draft

[Salz, Rich]

Quoting https://github.com/richsalz/tls12-frozen/issues/7 raised by Jonathan 
Lennox, in its entirety:

“Given the slow progress of implementations of DTLS 1.3, I think this draft 
needs to be clear that this feature freeze applies only to TLS 1.2 proper, not 
DTLS 1.2.

“For example, I would be very sad if any new DTLS-SRTP protection profiles 
could only be negotiated with DTLS 1.3.

“This may have implications for the IANA instructions section, for registries 
that are shared between the two protocols.”

Does the WG have any vews?  I know OpenSSL isn’t doing DTLS 1.3 right now, but 
is the industry overall lagging? Should we allow changes to DTLS 1.2?



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls