Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Loganaden Velvindron]

I hope this moves forward.

On Wed, 29 Mar 2023 at 05:50, Christopher Wood  wrote:
>
> As discussed during yesterday's meeting, we would like to assess consensus 
> for moving draft-ietf-tls-hybrid-design forward with the following strategy 
> for allocating codepoints we can use in deployments.
>
> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this 
> document through the process towards publication.
> 2. Write a simple -00 draft that specifies the target variant of 
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully did 
> this for us already [1].) Once this is complete, request a codepoint from 
> IANA using the standard procedure.
>
> The intent of this proposal is to get us a codepoint that we can deploy today 
> without putting a "draft codepoint" in an eventual RFC.
>
> Please let us know if you support this proposal by April 18, 2023. Assuming 
> there is rough consensus, we will move forward with this proposal.
>
> Best,
> Chris, Joe, and Sean
>
> [1] https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
> ___
> 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] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-02.txt

[John Mattsson]

Hi,

5.  IANA Considerations

This document requests IANA to mark the cipher suites listed in Appendix C as 
not recommended in the "TLS Cipher Suites" registry. Note that all cipher 
suites listed in Appendix A and in Appendix D are already marked as not 
recommended in the registry.


How do we split the IANA actions for cipher suites between this document, 
RFC8447, and draft-mattsson-tls-psk-ke-dont-dont-dont?

”N” seems highly inappropriate for TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
that is very clearly a “D”

What about TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. Is that a ”N”? The definition 
of discourage is clear with RFC8447bis. The definition of deprecated is not as 
clear.

Cheers,
John


From: TLS  on behalf of internet-dra...@ietf.org 

Date: Sunday, 26 March 2023 at 00:54
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Transport Layer
Security (TLS) WG of the IETF.

   Title   : Deprecating Obsolete Key Exchange Methods in TLS 1.2
   Authors : Carrick Bartle
 Nimrod Aviram
   Filename: draft-ietf-tls-deprecate-obsolete-kex-02.txt
   Pages   : 20
   Date: 2023-03-25

Abstract:
   This document deprecates the use of RSA key exchange and Diffie
   Hellman over a finite field in TLS 1.2, and discourages the use of
   static elliptic curve Diffie Hellman cipher suites.

   Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and
   1.1 are deprecated by [RFC8996] and TLS 1.3 either does not use the
   affected algorithm or does not share the relevant configuration
   options.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-02.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-deprecate-obsolete-kex-02

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
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] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Kampanakis, Panos]

> I would also like secp384r1_kyber1024 option, please.

Why do you up the ECDH curve sec level with Kyber1024? It adds unnecessary size 
to the keyshare. like secp384r1_kyber768 combines two equivalent security 
levels.
Those that want to be extra conservative can go secp521r1_kyber1024 which won’t 
be much worse than secp384r1_kyber1024 in performance or size.



From: TLS  On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: Tuesday, March 28, 2023 10:40 PM
To: Krzysztof Kwiatkowski ; Christopher Wood 

Cc: TLS@ietf.org
Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for 
draft-ietf-tls-hybrid-design


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Can we add secp256r1_kyber768 option for those who prefer NIST curves?

I support this.

I would also like secp384r1_kyber1024 option, please.

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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Kampanakis, Panos]

+1 for NIST curve codepoints.


From: TLS  On Behalf Of Krzysztof Kwiatkowski
Sent: Tuesday, March 28, 2023 10:00 PM
To: Christopher Wood 
Cc: TLS@ietf.org
Subject: RE: [EXTERNAL][TLS] Consensus call on codepoint strategy for 
draft-ietf-tls-hybrid-design


CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.


Hello,

Can we add secp256r1_kyber768 option for those who prefer NIST curves?

Kris



On 29 Mar 2023, at 10:48, Christopher Wood 
mailto:c...@heapingbits.net>> wrote:

As discussed during yesterday's meeting, we would like to assess consensus for 
moving draft-ietf-tls-hybrid-design forward with the following strategy for 
allocating codepoints we can use in deployments.

1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this 
document through the process towards publication.
2. Write a simple -00 draft that specifies the target variant of 
X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully did 
this for us already [1].) Once this is complete, request a codepoint from IANA 
using the standard procedure.

The intent of this proposal is to get us a codepoint that we can deploy today 
without putting a "draft codepoint" in an eventual RFC.

Please let us know if you support this proposal by April 18, 2023. Assuming 
there is rough consensus, we will move forward with this proposal.

Best,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
___
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] New Version Notification for draft-mattsson-tls-compact-ecc-04.txt

[John Mattsson]

This version just fixes a few nits.

- I think the new encodings make sense for cTLS where my understanding is that 
people likely want to keep using P-256 key share. Then the new encodings save 
80 bytes per mutually authenticated handshake.
- The new encodings are not needed for non-constrained TLS. There x25519 rules 
and the new ECDSA encoding in a handshake where only the server is 
authenticated saves 7 bytes.
- I think new code points should only be registered if people want to use this 
in cTLS.

Cheers,
John

From: internet-dra...@ietf.org 
Date: Wednesday, 29 March 2023 at 13:20
To: John Mattsson , John Mattsson 

Subject: New Version Notification for draft-mattsson-tls-compact-ecc-04.txt

A new version of I-D, draft-mattsson-tls-compact-ecc-04.txt
has been successfully submitted by John Preuß Mattsson and posted to the
IETF repository.

Name:   draft-mattsson-tls-compact-ecc
Revision:   04
Title:  Compact ECDHE and ECDSA Encodings for TLS 1.3
Document date:  2023-03-29
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-04.txt
Status: https://datatracker.ietf.org/doc/draft-mattsson-tls-compact-ecc/
Html:   
https://www.ietf.org/archive/id/draft-mattsson-tls-compact-ecc-04.html
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-mattsson-tls-compact-ecc
Diff:   
https://author-tools.ietf.org/iddiff?url2=draft-mattsson-tls-compact-ecc-04

Abstract:
   The encodings used in the ECDHE groups secp256r1, secp384r1, and
   secp521r1 and the ECDSA signature algorithms ecdsa_secp256r1_sha256,
   ecdsa_secp384r1_sha384, and ecdsa_secp521r1_sha512 have significant
   overhead and the ECDSA encoding produces variable-length signatures.
   This document defines new optimal fixed-length encodings and
   registers new ECDHE groups and ECDSA signature algorithms using these
   new encodings.  The new encodings reduce the size of the ECDHE groups
   with 33, 49, and 67 bytes and the ECDSA algorithms with an average of
   7 bytes.  These new encodings also work in DTLS 1.3 and are
   especially useful in cTLS.




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

[TLS] Milestones changed for tls WG

[IETF Secretariat]

Deleted milestone "Submit "Batch Signing for TLS" to the IESG".

URL: https://datatracker.ietf.org/wg/tls/about/

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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Blumenthal, Uri - 0553 - MITLL]

Can we add secp256r1_kyber768 option for those who prefer NIST curves?

 

I support this. 

 

I would also like secp384r1_kyber1024 option, please.

 

Thanks



On 29 Mar 2023, at 10:48, Christopher Wood  wrote:

 

As discussed during yesterday's meeting, we would like to assess consensus for 
moving draft-ietf-tls-hybrid-design forward with the following strategy for 
allocating codepoints we can use in deployments.

1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this 
document through the process towards publication.
2. Write a simple -00 draft that specifies the target variant of 
X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully did 
this for us already [1].) Once this is complete, request a codepoint from IANA 
using the standard procedure.

The intent of this proposal is to get us a codepoint that we can deploy today 
without putting a "draft codepoint" in an eventual RFC.

Please let us know if you support this proposal by April 18, 2023. Assuming 
there is rough consensus, we will move forward with this proposal.

Best,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Salz, Rich]

> The intent of this proposal is to get us a codepoint that we can deploy today 
> without putting a "draft codepoint" in an eventual RFC.

I support the proposal

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

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Richard Barnes]

+1

On Tue, Mar 28, 2023 at 10:15 PM Christopher Patton  wrote:

> I support this. Adding P256 + Kyber768 seems like a good idea.
>
> Chris P.
>
> On Wed, Mar 29, 2023 at 10:50 AM Christopher Wood 
> wrote:
>
>> As discussed during yesterday's meeting, we would like to assess
>> consensus for moving draft-ietf-tls-hybrid-design forward with the
>> following strategy for allocating codepoints we can use in deployments.
>>
>> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this
>> document through the process towards publication.
>> 2. Write a simple -00 draft that specifies the target variant of
>> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully
>> did this for us already [1].) Once this is complete, request a codepoint
>> from IANA using the standard procedure.
>>
>> The intent of this proposal is to get us a codepoint that we can deploy
>> today without putting a "draft codepoint" in an eventual RFC.
>>
>> Please let us know if you support this proposal by April 18, 2023.
>> Assuming there is rough consensus, we will move forward with this proposal.
>>
>> Best,
>> Chris, Joe, and Sean
>>
>> [1]
>> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
>> ___
>> 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] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Christopher Patton]

I support this. Adding P256 + Kyber768 seems like a good idea.

Chris P.

On Wed, Mar 29, 2023 at 10:50 AM Christopher Wood 
wrote:

> As discussed during yesterday's meeting, we would like to assess consensus
> for moving draft-ietf-tls-hybrid-design forward with the following strategy
> for allocating codepoints we can use in deployments.
>
> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this
> document through the process towards publication.
> 2. Write a simple -00 draft that specifies the target variant of
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully
> did this for us already [1].) Once this is complete, request a codepoint
> from IANA using the standard procedure.
>
> The intent of this proposal is to get us a codepoint that we can deploy
> today without putting a "draft codepoint" in an eventual RFC.
>
> Please let us know if you support this proposal by April 18, 2023.
> Assuming there is rough consensus, we will move forward with this proposal.
>
> Best,
> Chris, Joe, and Sean
>
> [1]
> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
> ___
> 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] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Eric Rescorla]

I support this proposal.



On Tue, Mar 28, 2023 at 6:49 PM Christopher Wood 
wrote:

> As discussed during yesterday's meeting, we would like to assess consensus
> for moving draft-ietf-tls-hybrid-design forward with the following strategy
> for allocating codepoints we can use in deployments.
>
> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this
> document through the process towards publication.
> 2. Write a simple -00 draft that specifies the target variant of
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully
> did this for us already [1].) Once this is complete, request a codepoint
> from IANA using the standard procedure.
>
> The intent of this proposal is to get us a codepoint that we can deploy
> today without putting a "draft codepoint" in an eventual RFC.
>
> Please let us know if you support this proposal by April 18, 2023.
> Assuming there is rough consensus, we will move forward with this proposal.
>
> Best,
> Chris, Joe, and Sean
>
> [1]
> https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
> ___
> 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] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Krzysztof Kwiatkowski]

Hello,

Can we add secp256r1_kyber768 option for those who prefer NIST curves?

Kris


> On 29 Mar 2023, at 10:48, Christopher Wood  wrote:
> 
> As discussed during yesterday's meeting, we would like to assess consensus 
> for moving draft-ietf-tls-hybrid-design forward with the following strategy 
> for allocating codepoints we can use in deployments.
> 
> 1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this 
> document through the process towards publication.
> 2. Write a simple -00 draft that specifies the target variant of 
> X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully did 
> this for us already [1].) Once this is complete, request a codepoint from 
> IANA using the standard procedure.
> 
> The intent of this proposal is to get us a codepoint that we can deploy today 
> without putting a "draft codepoint" in an eventual RFC.
> 
> Please let us know if you support this proposal by April 18, 2023. Assuming 
> there is rough consensus, we will move forward with this proposal.
> 
> Best,
> Chris, Joe, and Sean
> 
> [1] https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
> ___
> 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] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

[Christopher Wood]

As discussed during yesterday's meeting, we would like to assess consensus for 
moving draft-ietf-tls-hybrid-design forward with the following strategy for 
allocating codepoints we can use in deployments.

1. Remove codepoints from draft-ietf-tls-hybrid-design and advance this 
document through the process towards publication.
2. Write a simple -00 draft that specifies the target variant of 
X25519+Kyber768 with a codepoint from the standard ranges. (Bas helpfully did 
this for us already [1].) Once this is complete, request a codepoint from IANA 
using the standard procedure.

The intent of this proposal is to get us a codepoint that we can deploy today 
without putting a "draft codepoint" in an eventual RFC.

Please let us know if you support this proposal by April 18, 2023. Assuming 
there is rough consensus, we will move forward with this proposal.

Best,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-00
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG Adoption call for draft-sbn-tls-svcb-ech

[Jan Schaumann]

Martin Thomson  wrote:
> Adopt.  But please include an example, even if the public key is 
> 0x010203040506...

+1 on including an example.

-Jan

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

[TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[Christopher Wood]

As mentioned during yesterday's meeting, this email starts the working group 
last call for "The Transport Layer Security (TLS) Protocol Version 1.3" and 
"IANA Registry Updates for TLS and DTLS” I-Ds, located here:

- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis

The WG Last Call will end on April 18, 2023.

Please review the documents and submit issues or pull requests via the GitHub 
repositories, which can be found at:

- https://github.com/tlswg/tls13-spec
- https://github.com/tlswg/rfc8447bis

Alternatively, you can also send your comments to tls@ietf.org.

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

Re: [TLS] Packet number encryption negotiation

[Benson Muite]

> A first draft can be found here:
> https://www.ietf.org/id/draft-pismenny-tls-dtls-plaintext-sequence-number-00.txt
>  
> 
> 
> and the source is here:
> https://github.com/BorisPis/draft-pismenny-tls-dtls-plaintext-sequence-number 
> 
> 
> All inputs will be appreciated.
> 
Thanks for bringing this up today. Experimental numbers would be helpful
- interested in obtaining these, though not sure what has been obtained
before. Maybe it would be helpful to find other people working on data
center switches as well as doing multinode deployments in the cloud to
see if they would benefit from this.  One might expect to use a
different communication stack for internal communication within the
datacenter where high performance is needed, but this does add more
material that the development team needs to know.

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

Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes

[Hans Petter Selasky]

Hi,

On 3/28/23 00:39, Hal Murray wrote:


h...@selasky.org said:

A typical video stream of 4 MBit/s may produce on average 333 packets per
second, and I ask a simple question if it is really needed to authenticate
all of those packets while the user sits in a chair and eats popcorn?


Are you sure there is a user eating popcorn?


The majority - yes.


Are there any 0-day exploits in your video system?


That's a reminder to not use over complicated and secret sauce video 
codecs. Probably there is a 0-day exploit in the .mp4 codec already, 
implanted by secret services. Who knows. Nice to get rid of it!



Is that middle box doing the right thing?


If someone tampers internet in my town, the half a mile it goes down to 
the bank, I'm pretty sure I'll figure it out myself. But you know how 
ISP's like to do it, they send the traffic hundreds of miles to the 
nearest data/recording center, and then sends it back again. Encryption 
will never solve that problem, internet traffic goes way longer than it 
should. Infact governments require access to crypto keys so they can 
decrypt all traffic anyway - so what are you saying about middle boxes 
doing again  and encryption can do something about it? Nah, I don't 
think so.



The main problem I see with your proposal is that it adds complexity.
Everybody using TLS will now have to consider what happens if your option gets
enabled and/or how to make sure that it doesn't get enabled.  Security is
complicated.  Making it more complicated is a step in the wrong direction.


Yes, that's why I want a central change in this area, and not something 
custom, to avoid a big fight about the next httpX protocol.



Does your popcorn eating user need TLS as all?


That's a good question. People eating popcorn while watching movies on 
the TV probably also knows how their internet works - so I guess the 
answer is no :-)


--HPS

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

Re: [TLS] WG Adoption call for draft-sbn-tls-svcb-ech

[David Schinazi]

I support adoption.
David

On Tue, Mar 28, 2023 at 3:41 PM Martin Thomson  wrote:

> Adopt.  But please include an example, even if the public key is
> 0x010203040506...
>
> On Tue, Mar 28, 2023, at 13:54, Sean Turner wrote:
> > At TLS@IETF116, the sense of the room was that there was WG support to
> > adopt draft-sbn-tls-svcb-ech [1].  This message is to confirm the
> > consensus in the room. Please indicate whether you do or do not support
> > adoption of this I-D by 2359UTC on 18 April 2023. If do not support
> > adoption, please indicate why.
> >
> > Cheers,
> > Chris, Joe, and Sean
> >
> > [1] https://datatracker.ietf.org/doc/draft-sbn-tls-svcb-ech/
> > ___
> > 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] WG Adoption call for draft-sbn-tls-svcb-ech

[Martin Thomson]

Adopt.  But please include an example, even if the public key is 
0x010203040506...

On Tue, Mar 28, 2023, at 13:54, Sean Turner wrote:
> At TLS@IETF116, the sense of the room was that there was WG support to 
> adopt draft-sbn-tls-svcb-ech [1].  This message is to confirm the 
> consensus in the room. Please indicate whether you do or do not support 
> adoption of this I-D by 2359UTC on 18 April 2023. If do not support 
> adoption, please indicate why.
>
> Cheers,
> Chris, Joe, and Sean
>
> [1] https://datatracker.ietf.org/doc/draft-sbn-tls-svcb-ech/
> ___
> 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