[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120

[Ilari Liusvaara]

On Tue, Jul 23, 2024 at 09:51:04PM -0700, Dennis Jackson wrote:
> 
> Ahead of the meeting tomorrow, I want to highlight some of the questions
> which I think we need to find and agree on answers for:

The following are my own opinions.


> - What are the problems that we solving?

* Allowing server to have multiple certificates for handling spatial
  (different trust stores) and temporal (different versions of the
  same trust store) fragmentation of trust stores.
* Intermediate supression.


> - Who are we solving these problems for? Browsers or everyone?

Everyone.


> - Are we proposing a hard requirement on this negotiation mechanism for
> anyone wanting to do fully PQ TLS?

No. However, there may be transition period with really bad spatial
fragmentation making this mechanism de facto mandatory (which could then
be followed by temporal fragmentation).

However, because TLS does have proper algorithm agility, there is little
benefit in using fully PQ TLS until CRQC appears. To handle any
retroactive attacks, only kex has to be post-quantum, and post-quantum
kex can be used (and is used in the wild) with classical certificates.

 
> - Can the proposed mechanism be enabled by default in TLS Libraries without
> requiring application changes?

Only if using some sort of system certificate validation. Otherwise
mostly minor changes are required.

Some models turn out to require major server-side application changes
(e.g., anything that can dynamically vary number of end-entity certs),
and those are to be avoided.


> - Can the proposed mechanism support use in a private PKI? How about in a
> private PKI that runs over the public Internet (in the now-classic
> zero-trust networking model)?

Trust Expressions looks like it would work with private PKI. Things
are much more muddy with Trust Anchor Identifiers. It does seem to
support private PKI, but is that actually usable?


> - What is the long-term vision for TLS and the WebPKI? Are we moving forward
> together or fragmenting?

I would see the fragmentation on WebPKI remaining as it is today, but
total fragmentation increasing as some of the stuff now on WebPKI is
pulled out to private PKIs.

 
> - How do the proposed mechanisms affect TLS Client Hello fingerprinting or
> other tracking vectors?

The information transmitted given everything else is very small, as this
stuff can be mostly inferred from other things (not reliably enough for
servers, but reliably enough for tracking!).


> - How would the proposed system work in practice? What happens when actors
> follow their own interests rather than the requirements of RFCs?

The failure modes seem to confined to:

- Tracking vectors.
- "I'm vulnerable" signals.

However, any extensions, including non-standard ones can have the same
failure modes.

 
> - Are less popular clients incentivized to lie in their Trust Expressions
> about which root stores they have? The history of browser HTTP User Agent
> spoofing [1] highlights how minority clients are forced to spoof the signals
> of other browsers to maximize site compatibility (even though it violates
> protocol requirements).

Here it is likely that problems are due to inaction rather than
deliberate steps.

And various WebPKI trust stores have high overlap, so lying is very
likely to work.

Site that wants to deliberately exclude some browser could perform
things like TLS fingerprinting or deeper probing of JS APIs. These are
much harder to get around than simple user agent checks.


> - How would versioning root programs work in practice when security
> requirements change? If the same root CAs are in version N and version N+1
> of a root store and version N+1 adopts a stricter security policy - can
> these root CAs still issue certificates for version N?

Only adding constraints would trigger version change. And clients stuck
at version N do not know about the additional constraints, so apply the
old more lax rules.


> - What are the consequences of making it easier to establish new root
> programs? For governments that have previously tried to build domestic root
> programs, would solve some of the problems they faced and encourage them to
> try again?

More private PKIs. And it would not solve the problems with domestic root
programs.

There might not be any way to add a new root program, requiring any
parallel root program to be handled as special case in the code.


> Ultimately, these are two complex drafts which propose substantial changes
> to TLS and the WebPKI. Besides evaluating the technical details in the draft
> themselves, we also have to tackle the nitty gritty operational questions
> about how a new system would work in practice—in particular, considering the
> incentives of the stakeholders to adopt the system and or to deliberately
> deviate from the intended protocol for self-benefit.

Only TAI does changes to TLS that could be considered substantial.
Neither proposes any substantial change to WebPKI.

The main incentive is improved

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

[Peter C]

Douglas,

The agenda for the TLS session is looking packed, and this is a very 
in-the-weeds comment, so I hope you don't mind me posting it to the list.  
Happy to take any discussion off-list, if you'd prefer.

The draft-ietf-tls-hybrid-design security considerations currently say:

The shared secrets computed in the hybrid key exchange should be
computed in a way that achieves the "hybrid" property: the resulting
secret is secure as long as at least one of the component key
exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an
investigation of these issues.

If you assume the PQ KEM is IND-CCA2 secure, then I agree that [GIACON] and 
[BINDEL] imply that the derived traffic secrets will be indistinguishable from 
random and from each other.  The same is true if the KEM is only OW-CCA2 secure 
by Petcher-Campagna (https://ia.cr/2023/972).

If you assume the PQ KEM is broken, however, then [GIACON] and [BINDEL] do not 
apply since ECDH-as-a-KEM is not IND-CCA2 secure.  Similarly, Petcher-Campagna 
does not apply because ECDH is not OW-CCA2 secure.  Nor do I think it's 
possible to fall back on [DOWLING] since X25519 and NIST P-256 (as they are 
used in RFC 8446) do not satisfy the dual-snPRF-ODH assumption for any choice 
of KDF.  In this case, I don't believe the derived traffic secrets are 
guaranteed to be indistinguishable from random.

Flo raised similar points a couple of years ago which I don't think were fully 
addressed at the time.  I suspect this is just a security proof issue - the 
inclusion of the ciphertexts in the transcript hash should still protect 
against any actual attacks - and it's entirely possible that I've missed more 
recent results covering all of this.  If not, one easy solution might be to 
adopt the X-Wing approach and use

concatenated_ss = pqkem_ss || ecdh_ss || ecdh_ct || ecdh_pk,

although this currently only works with ML-KEM.

Best,

Peter


> -Original Message-
> From: TLS  On Behalf Of internet-dra...@ietf.org
> Sent: Friday, April 5, 2024 9:24 PM
> To: i-d-annou...@ietf.org
> Cc: tls@ietf.org
> Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-10.txt
>
> Internet-Draft draft-ietf-tls-hybrid-design-10.txt is now available. It is a
> work item of the Transport Layer Security (TLS) WG of the IETF.
>
>Title:   Hybrid key exchange in TLS 1.3
>Authors: Douglas Stebila
> Scott Fluhrer
> Shay Gueron
>Name:draft-ietf-tls-hybrid-design-10.txt
>Pages:   24
>Dates:   2024-04-05
>
> Abstract:
>
>Hybrid key exchange refers to using multiple key exchange algorithms
>simultaneously and combining the result with the goal of providing
>security even if all but one of the component algorithms is broken.
>It is motivated by transition to post-quantum cryptography.  This
>document provides a construction for hybrid key exchange in the
>Transport Layer Security (TLS) protocol version 1.3.
>
>Discussion of this work is encouraged to happen on the TLS IETF
>mailing list tls@ietf.org or on the GitHub repository which contains
>the draft:
> https://github/.
> com%2Fdstebila%2Fdraft-ietf-tls-hybrid-
> design&data=05%7C02%7CPeter.C%40ncsc.gov.uk%7Cec161933c97947c8a7e0
> 08dc55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6384
> 79455373796379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata
> =qNBE50aYk4woYCLUj6Rq1wMeFur63hP1MnHXDGihg80%3D&reserved=0.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatra/
> cker.ietf.org%2Fdoc%2Fdraft-ietf-tls-hybrid-
> design%2F&data=05%7C02%7CPeter.C%40ncsc.gov.uk%7Cec161933c97947c8
> a7e008dc55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C
> 638479455373796379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&s
> data=kVBR6kDc19NDTnC1fRgVqJmTnZOQggzmWk7wHHcVKbI%3D&reserved=
> 0
>
> There is also an HTML version available at:
> https://www.ie/
> tf.org%2Farchive%2Fid%2Fdraft-ietf-tls-hybrid-design-
> 10.html&data=05%7C02%7CPeter.C%40ncsc.gov.uk%7Cec161933c97947c8a7e
> 008dc55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C638
> 479455373796379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi
> LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat
> a=dcjY38cicBXU6ab7hnMalN1WTWqtQdhblMYu7xdzVT8%3D&reserved=0
>
> A diff from the previous version is available at:
> https://author/
> -tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-tls-hybrid-design-
> 10&data=05%7C02%7CPeter.C%40ncsc.gov.uk%7Cec161933c97947c8a7e008d
> c55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6384794
> 55373952646%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=3ll
> ZNYcqaixqUpU%2BhzzNOigFmuDlrA6CxCrIvyiG5HI%3D&reserved=0
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> 

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

[Deirdre Connolly]

Not a direct reference for TLS 1.3, but recent related work from the
document author, Douglas's analysis of PQ3 iMessage¹, has a hybrid
encrypted session setup with commonalities with the TLS 1.3 key schedule,
especially the layers of calls to HKDF.Expand and HKDF.extract, albeit in a
different order than TLS. These proofs rely on PRF-ODH for the curves and
that HKDF.Expand/Extract are PRFs in their first argument and more PRF
assumptions of the ~equivalent of the large key schedule that it is also a
PRF in two arguments (any chaining key material and the public session
information, including the ephemeral public keys) to achieve session key
indistinguishability.

¹
https://security.apple.com/assets/files/Security_analysis_of_the_iMessage_PQ3_protocol_Stebila.pdf

Maybe Douglas will be able to answer directly on TLS 1.3 but hopefully this
is also useful ✨



On Wed, Jul 24, 2024, 6:41 AM Peter C 
wrote:

> Douglas,
>
> The agenda for the TLS session is looking packed, and this is a very
> in-the-weeds comment, so I hope you don't mind me posting it to the list.
> Happy to take any discussion off-list, if you'd prefer.
>
> The draft-ietf-tls-hybrid-design security considerations currently say:
>
> The shared secrets computed in the hybrid key exchange should be
> computed in a way that achieves the "hybrid" property: the resulting
> secret is secure as long as at least one of the component key
> exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an
> investigation of these issues.
>
> If you assume the PQ KEM is IND-CCA2 secure, then I agree that [GIACON]
> and [BINDEL] imply that the derived traffic secrets will be
> indistinguishable from random and from each other.  The same is true if the
> KEM is only OW-CCA2 secure by Petcher-Campagna (https://ia.cr/2023/972).
>
> If you assume the PQ KEM is broken, however, then [GIACON] and [BINDEL] do
> not apply since ECDH-as-a-KEM is not IND-CCA2 secure.  Similarly,
> Petcher-Campagna does not apply because ECDH is not OW-CCA2 secure.  Nor do
> I think it's possible to fall back on [DOWLING] since X25519 and NIST P-256
> (as they are used in RFC 8446) do not satisfy the dual-snPRF-ODH assumption
> for any choice of KDF.  In this case, I don't believe the derived traffic
> secrets are guaranteed to be indistinguishable from random.
>
> Flo raised similar points a couple of years ago which I don't think were
> fully addressed at the time.  I suspect this is just a security proof issue
> - the inclusion of the ciphertexts in the transcript hash should still
> protect against any actual attacks - and it's entirely possible that I've
> missed more recent results covering all of this.  If not, one easy solution
> might be to adopt the X-Wing approach and use
>
> concatenated_ss = pqkem_ss || ecdh_ss || ecdh_ct || ecdh_pk,
>
> although this currently only works with ML-KEM.
>
> Best,
>
> Peter
>
>
> > -Original Message-
> > From: TLS  On Behalf Of internet-dra...@ietf.org
> > Sent: Friday, April 5, 2024 9:24 PM
> > To: i-d-annou...@ietf.org
> > Cc: tls@ietf.org
> > Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-10.txt
> >
> > Internet-Draft draft-ietf-tls-hybrid-design-10.txt is now available. It
> is a
> > work item of the Transport Layer Security (TLS) WG of the IETF.
> >
> >Title:   Hybrid key exchange in TLS 1.3
> >Authors: Douglas Stebila
> > Scott Fluhrer
> > Shay Gueron
> >Name:draft-ietf-tls-hybrid-design-10.txt
> >Pages:   24
> >Dates:   2024-04-05
> >
> > Abstract:
> >
> >Hybrid key exchange refers to using multiple key exchange algorithms
> >simultaneously and combining the result with the goal of providing
> >security even if all but one of the component algorithms is broken.
> >It is motivated by transition to post-quantum cryptography.  This
> >document provides a construction for hybrid key exchange in the
> >Transport Layer Security (TLS) protocol version 1.3.
> >
> >Discussion of this work is encouraged to happen on the TLS IETF
> >mailing list tls@ietf.org or on the GitHub repository which contains
> >the draft:
> > https://github/.
> > com%2Fdstebila%2Fdraft-ietf-tls-hybrid-
> > design&data=05%7C02%7CPeter.C%40ncsc.gov.uk%7Cec161933c97947c8a7e0
> > 08dc55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C6384
> > 79455373796379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> > CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata
> > =qNBE50aYk4woYCLUj6Rq1wMeFur63hP1MnHXDGihg80%3D&reserved=0.
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatra/
> > cker.ietf.org%2Fdoc%2Fdraft-ietf-tls-hybrid-
> > design%2F&data=05%7C02%7CPeter.C%40ncsc.gov.uk%7Cec161933c97947c8
> > a7e008dc55ae8cd7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0%7C
> > 638479455373796379%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&s
> > data=k

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

[Peter C]

Deirdre,

I’m not familiar with the PQ3 protocol, but I think PRF-ODH can fail in 
practice due to the way that ECDH is usually instantiated.

For NIST P-256, the input to the KDF is usually the x-coordinate of the ECDH 
shared secret rather than the full point.  Given a challenge (C, label), 
setting C’ = -C and querying the oracle with (C’, label) should give the same 
KDF output.

For X25519, the private keys are clamped and there are usually no checks on the 
public keys.  Given a challenge (C, label), setting C’ = C + P for a point P of 
small order and querying the oracle with (C’, label) should give the same KDF 
output.

Note that in both cases we are deviating from the idealised PRF-ODH setting so 
this does not contradict the proof that StDH implies PRF-ODH 
(https://ia.cr/2017/517).

Peter

From: Deirdre Connolly 
Sent: Wednesday, July 24, 2024 3:34 PM
To: Peter C 
Cc: Douglas Stebila ; TLS List 
Subject: Re: [TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt


Not a direct reference for TLS 1.3, but recent related work from the document 
author, Douglas's analysis of PQ3 iMessage¹, has a hybrid encrypted session 
setup with commonalities with the TLS 1.3 key schedule, especially the layers 
of calls to HKDF.Expand and HKDF.extract, albeit in a different order than TLS. 
These proofs rely on PRF-ODH for the curves and that HKDF.Expand/Extract are 
PRFs in their first argument and more PRF assumptions of the ~equivalent of the 
large key schedule that it is also a PRF in two arguments (any chaining key 
material and the public session information, including the ephemeral public 
keys) to achieve session key indistinguishability.

¹https://security.apple.com/assets/files/Security_analysis_of_the_iMessage_PQ3_protocol_Stebila.pdf

Maybe Douglas will be able to answer directly on TLS 1.3 but hopefully this is 
also useful ✨



On Wed, Jul 24, 2024, 6:41 AM Peter C 
mailto:40ncsc.gov...@dmarc.ietf.org>> 
wrote:
Douglas,

The agenda for the TLS session is looking packed, and this is a very 
in-the-weeds comment, so I hope you don't mind me posting it to the list.  
Happy to take any discussion off-list, if you'd prefer.

The draft-ietf-tls-hybrid-design security considerations currently say:

The shared secrets computed in the hybrid key exchange should be
computed in a way that achieves the "hybrid" property: the resulting
secret is secure as long as at least one of the component key
exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an
investigation of these issues.

If you assume the PQ KEM is IND-CCA2 secure, then I agree that [GIACON] and 
[BINDEL] imply that the derived traffic secrets will be indistinguishable from 
random and from each other.  The same is true if the KEM is only OW-CCA2 secure 
by Petcher-Campagna (https://ia.cr/2023/972).

If you assume the PQ KEM is broken, however, then [GIACON] and [BINDEL] do not 
apply since ECDH-as-a-KEM is not IND-CCA2 secure.  Similarly, Petcher-Campagna 
does not apply because ECDH is not OW-CCA2 secure.  Nor do I think it's 
possible to fall back on [DOWLING] since X25519 and NIST P-256 (as they are 
used in RFC 8446) do not satisfy the dual-snPRF-ODH assumption for any choice 
of KDF.  In this case, I don't believe the derived traffic secrets are 
guaranteed to be indistinguishable from random.

Flo raised similar points a couple of years ago which I don't think were fully 
addressed at the time.  I suspect this is just a security proof issue - the 
inclusion of the ciphertexts in the transcript hash should still protect 
against any actual attacks - and it's entirely possible that I've missed more 
recent results covering all of this.  If not, one easy solution might be to 
adopt the X-Wing approach and use

concatenated_ss = pqkem_ss || ecdh_ss || ecdh_ct || ecdh_pk,

although this currently only works with ML-KEM.

Best,

Peter


> -Original Message-
> From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of 
> internet-dra...@ietf.org
> Sent: Friday, April 5, 2024 9:24 PM
> To: i-d-annou...@ietf.org
> Cc: tls@ietf.org
> Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-10.txt
>
> Internet-Draft draft-ietf-tls-hybrid-design-10.txt is now available. It is a
> work item of the Transport Layer Security (TLS) WG of the IETF.
>
>Title:   Hybrid key exchange in TLS 1.3
>Authors: Douglas Stebila
> Scott Fluhrer
> Shay Gueron
>Name:draft-ietf-tls-hybrid-design-10.txt
>Pages:   24
>Dates:   2024-04-05
>
> Abstract:
>
>Hybrid key exchange refers to using multiple key exchange algorithms
>simultaneously and combining the result with the goal of providing
>security even if all but one of the component algorithms is broken.
>It is motivated by transition to post-quantum cryptography.  This
>document provides a construction for hybrid key exchange in the
>   

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

[Deirdre Connolly]

Yet another reason I would love full group elements included in these
protocols but alas

On Wed, Jul 24, 2024, 9:22 AM Peter C  wrote:

> Deirdre,
>
>
>
> I’m not familiar with the PQ3 protocol, but I think PRF-ODH can fail in
> practice due to the way that ECDH is usually instantiated.
>
>
>
> For NIST P-256, the input to the KDF is usually the x-coordinate of the
> ECDH shared secret rather than the full point.  Given a challenge (C,
> label), setting C’ = -C and querying the oracle with (C’, label) should
> give the same KDF output.
>
>
>
> For X25519, the private keys are clamped and there are usually no checks
> on the public keys.  Given a challenge (C, label), setting C’ = C + P for a
> point P of small order and querying the oracle with (C’, label) should give
> the same KDF output.
>
>
>
> Note that in both cases we are deviating from the idealised PRF-ODH
> setting so this does not contradict the proof that StDH implies PRF-ODH (
> https://ia.cr/2017/517).
>
>
>
> Peter
>
>
>
> *From:* Deirdre Connolly 
> *Sent:* Wednesday, July 24, 2024 3:34 PM
> *To:* Peter C 
> *Cc:* Douglas Stebila ; TLS List 
> *Subject:* Re: [TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt
>
>
>
> Not a direct reference for TLS 1.3, but recent related work from the
> document author, Douglas's analysis of PQ3 iMessage¹, has a hybrid
> encrypted session setup with commonalities with the TLS 1.3 key schedule,
> especially the layers of calls to HKDF.Expand and HKDF.extract, albeit in a
> different order than TLS. These proofs rely on PRF-ODH for the curves and
> that HKDF.Expand/Extract are PRFs in their first argument and more PRF
> assumptions of the ~equivalent of the large key schedule that it is also a
> PRF in two arguments (any chaining key material and the public session
> information, including the ephemeral public keys) to achieve session key
> indistinguishability.
>
> ¹
> https://security.apple.com/assets/files/Security_analysis_of_the_iMessage_PQ3_protocol_Stebila.pdf
>
> Maybe Douglas will be able to answer directly on TLS 1.3 but hopefully
> this is also useful ✨
>
>
>
>
>
> On Wed, Jul 24, 2024, 6:41 AM Peter C  40ncsc.gov...@dmarc.ietf.org> wrote:
>
> Douglas,
>
> The agenda for the TLS session is looking packed, and this is a very
> in-the-weeds comment, so I hope you don't mind me posting it to the list.
> Happy to take any discussion off-list, if you'd prefer.
>
> The draft-ietf-tls-hybrid-design security considerations currently say:
>
> The shared secrets computed in the hybrid key exchange should be
> computed in a way that achieves the "hybrid" property: the resulting
> secret is secure as long as at least one of the component key
> exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an
> investigation of these issues.
>
> If you assume the PQ KEM is IND-CCA2 secure, then I agree that [GIACON]
> and [BINDEL] imply that the derived traffic secrets will be
> indistinguishable from random and from each other.  The same is true if the
> KEM is only OW-CCA2 secure by Petcher-Campagna (https://ia.cr/2023/972).
>
> If you assume the PQ KEM is broken, however, then [GIACON] and [BINDEL] do
> not apply since ECDH-as-a-KEM is not IND-CCA2 secure.  Similarly,
> Petcher-Campagna does not apply because ECDH is not OW-CCA2 secure.  Nor do
> I think it's possible to fall back on [DOWLING] since X25519 and NIST P-256
> (as they are used in RFC 8446) do not satisfy the dual-snPRF-ODH assumption
> for any choice of KDF.  In this case, I don't believe the derived traffic
> secrets are guaranteed to be indistinguishable from random.
>
> Flo raised similar points a couple of years ago which I don't think were
> fully addressed at the time.  I suspect this is just a security proof issue
> - the inclusion of the ciphertexts in the transcript hash should still
> protect against any actual attacks - and it's entirely possible that I've
> missed more recent results covering all of this.  If not, one easy solution
> might be to adopt the X-Wing approach and use
>
> concatenated_ss = pqkem_ss || ecdh_ss || ecdh_ct || ecdh_pk,
>
> although this currently only works with ML-KEM.
>
> Best,
>
> Peter
>
>
> > -Original Message-
> > From: TLS  On Behalf Of internet-dra...@ietf.org
> > Sent: Friday, April 5, 2024 9:24 PM
> > To: i-d-annou...@ietf.org
> > Cc: tls@ietf.org
> > Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-10.txt
> >
> > Internet-Draft draft-ietf-tls-hybrid-design-10.txt is now available. It
> is a
> > work item of the Transport Layer Security (TLS) WG of the IETF.
> >
> >Title:   Hybrid key exchange in TLS 1.3
> >Authors: Douglas Stebila
> > Scott Fluhrer
> > Shay Gueron
> >Name:draft-ietf-tls-hybrid-design-10.txt
> >Pages:   24
> >Dates:   2024-04-05
> >
> > Abstract:
> >
> >Hybrid key exchange refers to using multiple key exchange algorithms
> >simultaneously and combining the result with the goal of pro

[TLS]Re: I-D Action: draft-ietf-tls-svcb-ech-03.txt

[Sean Turner]

Hey folks this version is just a keep alive version, i.e., the dates changed 
and that’s it.  We had a couple of comments during WGLC that need to be 
addressed.

Cheers,
spt

> On Jul 23, 2024, at 08:26, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-tls-svcb-ech-03.txt is now available. It is a work
> item of the Transport Layer Security (TLS) WG of the IETF.
> 
>   Title:   Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
>   Authors: Ben Schwartz
>Mike Bishop
>Erik Nygren
>   Name:draft-ietf-tls-svcb-ech-03.txt
>   Pages:   6
>   Dates:   2024-07-23
> 
> Abstract:
> 
>   To use TLS Encrypted ClientHello (ECH) the client needs to learn the
>   ECH configuration for a server before it attempts a connection to the
>   server.  This specification provides a mechanism for conveying the
>   ECH configuration information via DNS, using a SVCB or HTTPS record.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-03.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-svcb-ech-03
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list -- i-d-annou...@ietf.org
> To unsubscribe send an email to i-d-announce-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]tls@ietf120: WG I-D status

[Sean Turner]

Hi! We often review the WG I-Ds’ status during the chairs’ slides. I’d like to 
try an experiment to save us more time for the session by sending the update 
via email; it’s also in the chairs’ slides. If any I-D authors disagree with 
this very brief summary please let us know.  The list is sorted based on 
datatracker order.

- draft-ietf-tls-svcb-ech-03: Needs a -04 to address WGLC comments from Rich 
Salz and Chris Patton.

- draft-ietf-tls-8773bis-02: Refer to Formal Analysis Triage Team (FATT) 
discussion in meeting.

- draft-ietf-tls-wkech-05: See Stephen’s slides for IETF 120.

- draft-ietf-tls-deprecate-obsolete-kex-04: Joe needs to do some minor word 
tweaking before moving it forward.

- draft-ietf-tls-key-share-prediction-00: It’s new, needs WG review.

- draft-ietf-tls-tls13-pkcs1-01: Through WGLC, will enter FATT process once 
8773bis is resolved; technically behind -rrc.

- draft-ietf-tls-rfc8447bis-09: Awaiting WGLC; Deirdre to run.

- draft-ietf-tls-keylogfile-02: With RFC Editor.

- draft-ietf-tls-ctls-10: Stalled, but Hannes said he will have more time late 
summer.

- draft-ietf-tls-hybrid-design-10: See Deirdre’s slides for IETF 120.

- draft-ietf-tls-tls12-frozen-00: See Rich’s slides for IETF 120.

- draft-ietf-tls-dtls-rrc-11: Through WGLC, will enter FATT process once 
8773bis is resolved.

- draft-davidben-tls-key-share-prediction-01: WG review needed.

- draft-ietf-tls-cert-abridge-01: Needs WG review.

- draft-ietf-tls-tlsflags-13: Awaiting implementations; would move if 
draft-jhoyla-req-mtls-flag was adopted.

- draft-ietf-tls-rfc8446bis-10: See Sean’s slides for IETF 120.

Cheers,
spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: Discussions on Trust Anchor Negotiation at IETF 120

[Tim Hollebeek]

I think this is a good summary.  I want to support this sort of effort, in part 
because it's very similar to some other ideas my boss and I were pushing about 
five years ago.  Something similar to this would solve, but also cause, lots of 
problems.  It's not clear whether the net result is better or worse.

But I find it difficult or impossible to evaluate for exactly the reasons 
Dennis mentions: there's no context explaining how it will be used, or any 
discussion of the impact on the many other things that would need to change for 
this draft to be useful.

We need to have open and honest discussions about how roots and root management 
will work going forward, if we want things to work differently in the future.

-Tim

> -Original Message-
> From: Dennis Jackson 
> Sent: Tuesday, July 23, 2024 9:51 PM
> To: TLS List 
> Subject: [TLS]Discussions on Trust Anchor Negotiation at IETF 120
> 
> There has been a lot of discussion over the past few days, both in person and
> on the mailing list. I want to share some thoughts on those discussions before
> the meeting tomorrow.
> 
> My impression is that there is little consensus on which problems we want to
> solve as a WG. Resolving this is critical for making progress.
> It is almost impossible to have sensible conversations about new drafts
> without agreeing on and understanding the problems we want to solve.
> 
> The vast majority of folks I've spoken with have said they're interested in
> solving the challenges around deploying fully PQ TLS, but don't feel that we
> are currently close to a shared understanding of those challenges or the
> tradeoffs around the drafts on the table today.
> 
> A smaller number of folks are interested in tackling other problems around
> root store management. I fear this aspect of the problem space is even less
> clearly understood and I heard very little agreement on what the key
> challenges are or how they might be addressed.
> 
> I hope tomorrow we can focus our discussion on figuring out as a WG the
> problem(s) that we want to tackle and where we differ in our understanding
> of those problems. I am sure that 20 minutes will not be enough time to
> resolve these complex issues, but I hope we can find a way to continue the
> conversation constructively.
> 
> Ahead of the meeting tomorrow, I want to highlight some of the questions
> which I think we need to find and agree on answers for:
> 
> - What are the problems that we solving?
> 
> - Who are we solving these problems for? Browsers or everyone?
> 
> - Are we proposing a hard requirement on this negotiation mechanism for
> anyone wanting to do fully PQ TLS?
> 
> - Can the proposed mechanism be enabled by default in TLS Libraries without
> requiring application changes?
> 
> - Can the proposed mechanism support use in a private PKI? How about in a
> private PKI that runs over the public Internet (in the now-classic zero-trust
> networking model)?
> 
> - What is the long-term vision for TLS and the WebPKI? Are we moving
> forward together or fragmenting?
> 
> - How do the proposed mechanisms affect TLS Client Hello fingerprinting or
> other tracking vectors?
> 
> - How would the proposed system work in practice? What happens when
> actors follow their own interests rather than the requirements of RFCs?
> 
> - Are less popular clients incentivized to lie in their Trust Expressions 
> about
> which root stores they have? The history of browser HTTP User Agent
> spoofing [1] highlights how minority clients are forced to spoof the signals 
> of
> other browsers to maximize site compatibility (even though it violates
> protocol requirements).
> 
> - How would versioning root programs work in practice when security
> requirements change? If the same root CAs are in version N and version
> N+1 of a root store and version N+1 adopts a stricter security policy -
> can these root CAs still issue certificates for version N?
> 
> - What are the consequences of making it easier to establish new root
> programs? For governments that have previously tried to build domestic
> root programs, would solve some of the problems they faced and encourage
> them to try again?
> 
> Ultimately, these are two complex drafts which propose substantial
> changes to TLS and the WebPKI. Besides evaluating the technical details
> in the draft themselves, we also have to tackle the nitty gritty
> operational questions about how a new system would work in practice—in
> particular, considering the incentives of the stakeholders to adopt the
> system and or to deliberately deviate from the intended protocol for
> self-benefit.
> 
> Finally, in any proposal which alters the power dynamics of a system,
> there will be difficult questions of a political nature, especially when
> the system in question is depended upon by billions of people.
> 
> Naturally, good people will often disagree on the nuances of these
> complex topics. However, we owe it to each other to communicate
> constructively, arr

[TLS]Re: tls@ietf120: WG I-D status

[Stephen Farrell]

Hiya,

What's the status/plan for draft-ietf-tls-esni-18?

Thanks,
S.

On 24/07/2024 20:57, Sean Turner wrote:

[External Email] This email originated outside of Trinity College Dublin. Do 
not click links or open attachments unless you recognise the sender and know 
the content is safe.

Hi! We often review the WG I-Ds’ status during the chairs’ slides. I’d like to 
try an experiment to save us more time for the session by sending the update 
via email; it’s also in the chairs’ slides. If any I-D authors disagree with 
this very brief summary please let us know.  The list is sorted based on 
datatracker order.

- draft-ietf-tls-svcb-ech-03: Needs a -04 to address WGLC comments from Rich 
Salz and Chris Patton.

- draft-ietf-tls-8773bis-02: Refer to Formal Analysis Triage Team (FATT) 
discussion in meeting.

- draft-ietf-tls-wkech-05: See Stephen’s slides for IETF 120.

- draft-ietf-tls-deprecate-obsolete-kex-04: Joe needs to do some minor word 
tweaking before moving it forward.

- draft-ietf-tls-key-share-prediction-00: It’s new, needs WG review.

- draft-ietf-tls-tls13-pkcs1-01: Through WGLC, will enter FATT process once 
8773bis is resolved; technically behind -rrc.

- draft-ietf-tls-rfc8447bis-09: Awaiting WGLC; Deirdre to run.

- draft-ietf-tls-keylogfile-02: With RFC Editor.

- draft-ietf-tls-ctls-10: Stalled, but Hannes said he will have more time late 
summer.

- draft-ietf-tls-hybrid-design-10: See Deirdre’s slides for IETF 120.

- draft-ietf-tls-tls12-frozen-00: See Rich’s slides for IETF 120.

- draft-ietf-tls-dtls-rrc-11: Through WGLC, will enter FATT process once 
8773bis is resolved.

- draft-davidben-tls-key-share-prediction-01: WG review needed.

- draft-ietf-tls-cert-abridge-01: Needs WG review.

- draft-ietf-tls-tlsflags-13: Awaiting implementations; would move if 
draft-jhoyla-req-mtls-flag was adopted.

- draft-ietf-tls-rfc8446bis-10: See Sean’s slides for IETF 120.

Cheers,
spt
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org




OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: tls@ietf120: WG I-D status

[Arnaud Taddei]

Funny I had the SAME question earlier too with someone else.

So, ditto

Arnaud Taddei
Global Security Strategist | Enterprise Security Group

mobile: +41 79 506 1129 
Geneva, Switzerland
arnaud.tad...@broadcom.com  | broadcom.com

> On 24 Jul 2024, at 13:22, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
> What's the status/plan for draft-ietf-tls-esni-18?
> 
> Thanks,
> S.
> 
> On 24/07/2024 20:57, Sean Turner wrote:
>> [External Email] This email originated outside of Trinity College Dublin. Do 
>> not click links or open attachments unless you recognise the sender and know 
>> the content is safe.
>> Hi! We often review the WG I-Ds’ status during the chairs’ slides. I’d like 
>> to try an experiment to save us more time for the session by sending the 
>> update via email; it’s also in the chairs’ slides. If any I-D authors 
>> disagree with this very brief summary please let us know.  The list is 
>> sorted based on datatracker order.
>> - draft-ietf-tls-svcb-ech-03: Needs a -04 to address WGLC comments from Rich 
>> Salz and Chris Patton.
>> - draft-ietf-tls-8773bis-02: Refer to Formal Analysis Triage Team (FATT) 
>> discussion in meeting.
>> - draft-ietf-tls-wkech-05: See Stephen’s slides for IETF 120.
>> - draft-ietf-tls-deprecate-obsolete-kex-04: Joe needs to do some minor word 
>> tweaking before moving it forward.
>> - draft-ietf-tls-key-share-prediction-00: It’s new, needs WG review.
>> - draft-ietf-tls-tls13-pkcs1-01: Through WGLC, will enter FATT process once 
>> 8773bis is resolved; technically behind -rrc.
>> - draft-ietf-tls-rfc8447bis-09: Awaiting WGLC; Deirdre to run.
>> - draft-ietf-tls-keylogfile-02: With RFC Editor.
>> - draft-ietf-tls-ctls-10: Stalled, but Hannes said he will have more time 
>> late summer.
>> - draft-ietf-tls-hybrid-design-10: See Deirdre’s slides for IETF 120.
>> - draft-ietf-tls-tls12-frozen-00: See Rich’s slides for IETF 120.
>> - draft-ietf-tls-dtls-rrc-11: Through WGLC, will enter FATT process once 
>> 8773bis is resolved.
>> - draft-davidben-tls-key-share-prediction-01: WG review needed.
>> - draft-ietf-tls-cert-abridge-01: Needs WG review.
>> - draft-ietf-tls-tlsflags-13: Awaiting implementations; would move if 
>> draft-jhoyla-req-mtls-flag was adopted.
>> - draft-ietf-tls-rfc8446bis-10: See Sean’s slides for IETF 120.
>> Cheers,
>> spt
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org


-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

[Douglas Stebila]

Hi Peter,

I agree that if you assume that the PQ KEM is broken, then [GIACON] and 
[BINDEL] don't apply since ECDH-as-a-KEM is not IND-CCA2 secure.  I don't fully 
follow your argument on why it's not possible to fall back on [DOWLING] -- in 
other words, just resort back to the original security proof of ECDH in TLS 
1.3.  

I did see your subsequent email about the tweaking that one can do for NIST 
P-256 and X25519 due to compressed formats leading to mathematically equivalent 
points.  If it was the case that this tweakability resulted in hybrid key 
exchange having a problem (either a security problem or just a proof problem) 
when the PQ KEM is broken, then I think that would also imply that this 
tweakability leads to a problem in plain old ECDH key exchange in TLS 1.3.  In 
other words, I think your argument implies that the [DOWLING] proof doesn't 
apply to TLS 1.3 ECDH key exchange because the point encodings used for X25519 
and NIST P-256 don't satisfy dual-snPRF-ODH.  Which may be true, but it would 
imply a bigger scope of concerns than just hybrid key exchange.

Now, it is the case that the HKDF.Expand portions of the key schedule include 
the transcript hash and thus the ECDH public keys, so any of these tweaks 
would, at the HKDF.Expand point, lead to different hash values.  This suggests 
to me that if one needed to adapt the proof, I'd start by treating HKDF.Extract 
and HKDF.Expand as a single monolithic operation involving the shared secrets 
and the transcripts.  In the random oracle model, this results in hashing 
everything in, which I guess would provide enough rigidity to prevent any such 
attacks, similar to the argument in X-Wing.

So if I am correctly interpreting your argument about point formats leading to 
a proof doubt, I think the path forward would be to revisit the original 
[DOWLING] proof in light of groups that don't satisfy dual-snPRF-ODH due to 
tweakability of point formats, possibly addressing this by treating 
HKDF.Extract and HKDF.Expand monolithically, and try to cover both the original 
ECDH and the hybrid questions at the same time.

Douglas


> On Jul 24, 2024, at 09:39, Peter C  wrote:
> 
> Douglas,
> 
> The agenda for the TLS session is looking packed, and this is a very 
> in-the-weeds comment, so I hope you don't mind me posting it to the list.  
> Happy to take any discussion off-list, if you'd prefer.
> 
> The draft-ietf-tls-hybrid-design security considerations currently say:
> 
>The shared secrets computed in the hybrid key exchange should be
>computed in a way that achieves the "hybrid" property: the resulting
>secret is secure as long as at least one of the component key
>exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an
>investigation of these issues.
> 
> If you assume the PQ KEM is IND-CCA2 secure, then I agree that [GIACON] and 
> [BINDEL] imply that the derived traffic secrets will be indistinguishable 
> from random and from each other.  The same is true if the KEM is only OW-CCA2 
> secure by Petcher-Campagna (https://ia.cr/2023/972).
> 
> If you assume the PQ KEM is broken, however, then [GIACON] and [BINDEL] do 
> not apply since ECDH-as-a-KEM is not IND-CCA2 secure.  Similarly, 
> Petcher-Campagna does not apply because ECDH is not OW-CCA2 secure.  Nor do I 
> think it's possible to fall back on [DOWLING] since X25519 and NIST P-256 (as 
> they are used in RFC 8446) do not satisfy the dual-snPRF-ODH assumption for 
> any choice of KDF.  In this case, I don't believe the derived traffic secrets 
> are guaranteed to be indistinguishable from random.
> 
> Flo raised similar points a couple of years ago which I don't think were 
> fully addressed at the time.  I suspect this is just a security proof issue - 
> the inclusion of the ciphertexts in the transcript hash should still protect 
> against any actual attacks - and it's entirely possible that I've missed more 
> recent results covering all of this.  If not, one easy solution might be to 
> adopt the X-Wing approach and use
> 
>concatenated_ss = pqkem_ss || ecdh_ss || ecdh_ct || ecdh_pk,
> 
> although this currently only works with ML-KEM.
> 
> Best,
> 
> Peter
> 
> 
>> -Original Message-
>> From: TLS  On Behalf Of internet-dra...@ietf.org
>> Sent: Friday, April 5, 2024 9:24 PM
>> To: i-d-annou...@ietf.org
>> Cc: tls@ietf.org
>> Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-10.txt
>> 
>> Internet-Draft draft-ietf-tls-hybrid-design-10.txt is now available. It is a
>> work item of the Transport Layer Security (TLS) WG of the IETF.
>> 
>>   Title:   Hybrid key exchange in TLS 1.3
>>   Authors: Douglas Stebila
>>Scott Fluhrer
>>Shay Gueron
>>   Name:draft-ietf-tls-hybrid-design-10.txt
>>   Pages:   24
>>   Dates:   2024-04-05
>> 
>> Abstract:
>> 
>>   Hybrid key exchange refers to using multiple key exchange algorithms
>>   simultaneously and combining the result with the goal of providing
>>   security ev

[TLS]Side meeting on attested TLS tomorrow

[Yaron Sheffer]

Dear TLS WG, There will be a side meeting on Attested TLS tomorrow morning, Thursday 9:00-10:00 at the Prince of Wales room. The target audience is the TLS community, so please join us whether you are big fans of attestation or you think that attestation is a Bad Thing. Thanks, Hannes and Yaron
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]I-D Action: draft-ietf-tls-tls12-frozen-01.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-tls12-frozen-01.txt is now available. It is a
work item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   TLS 1.2 is in Feature Freeze
   Authors: Rich Salz
Nimrod Aviram
   Name:draft-ietf-tls-tls12-frozen-01.txt
   Pages:   5
   Dates:   2024-07-24

Abstract:

   TLS 1.2 is in widespread use and can be configured such that it
   provides good security properties.  TLS 1.3 is also in widespread use
   and fixes some known deficiencies with TLS 1.2, such as removing
   error-prone cryptographic primitives and encrypting more of the
   traffic so that it is not readable by outsiders.

   Both versions have several extension points, so items like new
   cryptographic algorithms, new supported groups (formerly "named
   curves"), etc., can be added without defining a new protocol.  This
   document specifies that outside of urgent security fixes, no new
   features will be approved for TLS 1.2.  This prescription does not
   pertain to DTLS (in any DTLS version); it pertains to TLS only.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-01.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-tls12-frozen-01

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


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: I-D Action: draft-ietf-tls-tls12-frozen-01.txt

[Salz, Rich]

This version removes all text that is duplicated in the UTA "require TLS 1.3" 
draft.[1]

In my view, this is ready for WGLC. 

[1] https://datatracker.ietf.org/doc/draft-ietf-uta-require-tls13/


On 7/24/24, 4:44 PM, "internet-dra...@ietf.org 
" mailto:internet-dra...@ietf.org>> wrote:


Internet-Draft draft-ietf-tls-tls12-frozen-01.txt is now available. It is a
work item of the Transport Layer Security (TLS) WG of the IETF.


Title: TLS 1.2 is in Feature Freeze
Authors: Rich Salz
Nimrod Aviram
Name: draft-ietf-tls-tls12-frozen-01.txt
Pages: 5
Dates: 2024-07-24


Abstract:


TLS 1.2 is in widespread use and can be configured such that it
provides good security properties. TLS 1.3 is also in widespread use
and fixes some known deficiencies with TLS 1.2, such as removing
error-prone cryptographic primitives and encrypting more of the
traffic so that it is not readable by outsiders.


Both versions have several extension points, so items like new
cryptographic algorithms, new supported groups (formerly "named
curves"), etc., can be added without defining a new protocol. This
document specifies that outside of urgent security fixes, no new
features will be approved for TLS 1.2. This prescription does not
pertain to DTLS (in any DTLS version); it pertains to TLS only.


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


There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-tls12-frozen-01.html 



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org