date:20231206



Hiya,

On 06/12/2023 21:06, Russ Housley wrote:

Stephen:

Maybe.  ECH would need to be updated to use PQC algorithms to get that 
protection.

Ill add that point:

Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
tracking prevention.  The guidance in these sections remain relevant.

If an external PSK identity is used for multiple connections, then an
observer will generally be able track clients and/or servers across
connections.  The rotation of the external PSK identity or the use of
the Encrypted Client Hello extension [I-D.ietf-tls-esni] with
algorithms that a secure against a CRQC can mitigate this risk.


That'd be a fairly giant outer client hello though if you include
real PSK stuff in the inner CH, more or less any PQ hybrid scheme
and the phoney/GREASE PSK stuff in the outer CH. I dunno if it'd
be feasible to use in practice, which would seem telling in terms
of promotion from experimental. I think someone would need to check
the numbers and/or maybe figure out if the phoney/GREASE outer PSK
stuff can be safely omitted in this context, and then write down
how to do that.

I suspect that could end up with something that'd work ok, but it'd
need some work, and that's in addition to saying how to do the PQ
thing for ECH, which'd involve a number of design decisions I think,
and might in itself be a bit of an experiment.

So I don't think a quick bit of text about ECH solves the problem
John raised in this context, or, at least, it'd be a non-trivial
solution, and maybe more that you'd want if starting with with the
goal in the subject line? (Not trying to be negative, just not at
all sure.)

Cheers,
S.



Russ


On Dec 6, 2023, at 4:00 PM, Stephen Farrell  wrote:


Hiya,


(3) The privacy considerations already talk about Appendix E.6 of
[RFC8446].  I am please to add a pointer to ECH, but I do not think
that ECH use should not be mandated.


While I'm a fan of ECH, does it actually do the trick here?
If the adversary has a CRQC then we'd need an updated ECH
that's not vulnerable in that scenario, and we don't have
that now. (And it might be hard to get to, given MTU sizes.)

Cheers,
S.


I suggest:
Appendix E.6 of [RFC8446] discusses identity-exposure attacks on PSKs.  Also, 
Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses tracking prevention.  The 
guidance in these sections remain
relevant.
If an external PSK identity is used for multiple connections, then
an observer will generally be able track clients and/or servers
across connections.  The rotation of the external PSK identity or the
use of the Encrypted Client Hello extension [I-D.ietf-tls-esni] can
mitigate this risk.
Russ

On Dec 6, 2023, at 11:51 AM, John Mattsson
 wrote:
Hi,
I am quite convinced that the security properties are not worse
than a mixture of PSK authentication, PSK key exchange, (EC)DHE key
exchange, and signature authentication.
In some cases, this is very good. You get the quantum-resistance of
the PSK together with the PFS of ECDHE, and the entity
authentication and security policies of certificates. In other
cases, it is not so good as the reuse of a PSK identifier enables
tracking and potentially identification of both the client and the
server. I don’t think that such a field enabling tracking belongs
in modern TLS, but reuse of a PSK identifier is already in RFC 8446
so this document does theoretically not make the worst-case worse.
If RFC 8773 is updated. I think the following things should be
updated: - The title and abstract only talks about PSK
authentication. The key exchange is likely more important to make
quantum-resistant than the authentication. I think the title and
abstract should talk about PSK key exchange. - I think the
paywalled references should be removed. I think paywalled
references are both a cybersecurity risk and a democracy problem
[1]. I don’t think they belong in RFCs unless absolutely necessary.
RFC 8446bis recently removed all paywalled references. - The
document should refer to section C.4 of RFC8446bis that now
includes a short discussion on that reuse of an PSK identifier
enables tracking. I think RFC8773bis should have a warning early
that the privacy properties are much worse than the normal
certificate-based authentication. This could be completely solved
by mandating ECH. Alternatively, it could be solved by sending the
PSK identifier after flight #1 when things are encrypted.
3GPP specified the use of server certificate authentication
combined with PSK authentication and key exchange for TLS 1.2. As
that mode was not available in RFC 8446, 3GPP does not specify this
mode for TLS 1.3 but there have recently been discussions in 3GPP
about adding RFC 8773. I think the really bad privacy properties of
PSK in TLS 1.3 is a significant problem for 3GPP. The bad privacy
properties of TLS 1.3 with PSK have also been discussed several
times in EMU WG. I think a mode that s

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-06 Thread Russ Housley

Stephen:

Maybe.  ECH would need to be updated to use PQC algorithms to get that 
protection.

Ill add that point:

   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
   PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
   tracking prevention.  The guidance in these sections remain relevant.

   If an external PSK identity is used for multiple connections, then an
   observer will generally be able track clients and/or servers across
   connections.  The rotation of the external PSK identity or the use of
   the Encrypted Client Hello extension [I-D.ietf-tls-esni] with
   algorithms that a secure against a CRQC can mitigate this risk.

Russ

> On Dec 6, 2023, at 4:00 PM, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
>> (3) The privacy considerations already talk about Appendix E.6 of
>> [RFC8446].  I am please to add a pointer to ECH, but I do not think
>> that ECH use should not be mandated.
> 
> While I'm a fan of ECH, does it actually do the trick here?
> If the adversary has a CRQC then we'd need an updated ECH
> that's not vulnerable in that scenario, and we don't have
> that now. (And it might be hard to get to, given MTU sizes.)
> 
> Cheers,
> S.
> 
>> I suggest:
>> Appendix E.6 of [RFC8446] discusses identity-exposure attacks on PSKs.  
>> Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses tracking 
>> prevention.  The guidance in these sections remain
>> relevant.
>> If an external PSK identity is used for multiple connections, then
>> an observer will generally be able track clients and/or servers
>> across connections.  The rotation of the external PSK identity or the
>> use of the Encrypted Client Hello extension [I-D.ietf-tls-esni] can
>> mitigate this risk.
>> Russ
>>> On Dec 6, 2023, at 11:51 AM, John Mattsson
>>>  wrote:
>>> Hi,
>>> I am quite convinced that the security properties are not worse
>>> than a mixture of PSK authentication, PSK key exchange, (EC)DHE key
>>> exchange, and signature authentication.
>>> In some cases, this is very good. You get the quantum-resistance of
>>> the PSK together with the PFS of ECDHE, and the entity
>>> authentication and security policies of certificates. In other
>>> cases, it is not so good as the reuse of a PSK identifier enables
>>> tracking and potentially identification of both the client and the
>>> server. I don’t think that such a field enabling tracking belongs
>>> in modern TLS, but reuse of a PSK identifier is already in RFC 8446
>>> so this document does theoretically not make the worst-case worse.
>>> If RFC 8773 is updated. I think the following things should be
>>> updated: - The title and abstract only talks about PSK
>>> authentication. The key exchange is likely more important to make
>>> quantum-resistant than the authentication. I think the title and
>>> abstract should talk about PSK key exchange. - I think the
>>> paywalled references should be removed. I think paywalled
>>> references are both a cybersecurity risk and a democracy problem
>>> [1]. I don’t think they belong in RFCs unless absolutely necessary.
>>> RFC 8446bis recently removed all paywalled references. - The
>>> document should refer to section C.4 of RFC8446bis that now
>>> includes a short discussion on that reuse of an PSK identifier
>>> enables tracking. I think RFC8773bis should have a warning early
>>> that the privacy properties are much worse than the normal
>>> certificate-based authentication. This could be completely solved
>>> by mandating ECH. Alternatively, it could be solved by sending the
>>> PSK identifier after flight #1 when things are encrypted.
>>> 3GPP specified the use of server certificate authentication
>>> combined with PSK authentication and key exchange for TLS 1.2. As
>>> that mode was not available in RFC 8446, 3GPP does not specify this
>>> mode for TLS 1.3 but there have recently been discussions in 3GPP
>>> about adding RFC 8773. I think the really bad privacy properties of
>>> PSK in TLS 1.3 is a significant problem for 3GPP. The bad privacy
>>> properties of TLS 1.3 with PSK have also been discussed several
>>> times in EMU WG. I think a mode that sends the PSK identifier
>>> encrypted would make a lot more sense for standard track.
>>> I am not supportive of standard track unless the tracking problem
>>> is solved. If the privacy problems are solved, I am however very
>>> supportive. Adding an extra roundtrip is a small price to pay for
>>> privacy. Adding a field (psk identifier) that can be used for
>>> tracking to current certificate-based TLS is making privacy worse.
>>> I don’t think that is a good idea or worthy of standards track.
>>> Cheers, John Preuß Mattsson
>>> [1]
>>> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ
>>> 
>>> From: TLS mailto:tls-boun...@ietf.org>> on
>>> behalf of Dan Harkins >> > Date: Wednesday, 6 December 2023 at
>>> 14:50 To: TLS@ietf.org  >> > Subject: Re: [T

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-06 Thread Christian Huitema





On 12/6/2023 10:59 AM, Russ Housley wrote:

Christian:


Thanks. I am not 100% sure that we actually have an attack against the 
[EC]DH+PSK combination, but I am confident than if the PSK secret is weak, the 
attacker can get to the early data. If only for that, it is prudent to use long 
enough PSK.


As stated in draft-ietf-tls-8773bis, some people are interested in using the 
external PSK with a certificate to protect against the future invention of a 
Cryptographically Relevant Quantum Computer (CRQC).  Others want to use of a 
public key with a factory-provisioned secret value for the initial enrollment 
of a device in an enterprise network (for example 
draft-ietf-emu-bootstrapped-tls).

For the security consideration, I suggest an additional paragraph:

 Implementations must use sufficiently large external PSKs.  For 
protection
 against the future invention of a CRQC, the external PSK needs to be at
 least 256 bits.

Does that resolve your concern?


Yes.

-- Christian Huitema

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track



Hiya,


(3) The privacy considerations already talk about Appendix E.6 of
[RFC8446].  I am please to add a pointer to ECH, but I do not think
that ECH use should not be mandated.


While I'm a fan of ECH, does it actually do the trick here?
If the adversary has a CRQC then we'd need an updated ECH
that's not vulnerable in that scenario, and we don't have
that now. (And it might be hard to get to, given MTU sizes.)

Cheers,
S.



I suggest:

Appendix E.6 of [RFC8446] discusses identity-exposure attacks on 
PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses 
tracking prevention.  The guidance in these sections remain

relevant.

If an external PSK identity is used for multiple connections, then
an observer will generally be able track clients and/or servers
across connections.  The rotation of the external PSK identity or the
use of the Encrypted Client Hello extension [I-D.ietf-tls-esni] can
mitigate this risk.

Russ



On Dec 6, 2023, at 11:51 AM, John Mattsson
 wrote:

Hi,

I am quite convinced that the security properties are not worse
than a mixture of PSK authentication, PSK key exchange, (EC)DHE key
exchange, and signature authentication.

In some cases, this is very good. You get the quantum-resistance of
the PSK together with the PFS of ECDHE, and the entity
authentication and security policies of certificates. In other
cases, it is not so good as the reuse of a PSK identifier enables
tracking and potentially identification of both the client and the
server. I don’t think that such a field enabling tracking belongs
in modern TLS, but reuse of a PSK identifier is already in RFC 8446
so this document does theoretically not make the worst-case worse.

If RFC 8773 is updated. I think the following things should be
updated: - The title and abstract only talks about PSK
authentication. The key exchange is likely more important to make
quantum-resistant than the authentication. I think the title and
abstract should talk about PSK key exchange. - I think the
paywalled references should be removed. I think paywalled
references are both a cybersecurity risk and a democracy problem
[1]. I don’t think they belong in RFCs unless absolutely necessary.
RFC 8446bis recently removed all paywalled references. - The
document should refer to section C.4 of RFC8446bis that now
includes a short discussion on that reuse of an PSK identifier
enables tracking. I think RFC8773bis should have a warning early
that the privacy properties are much worse than the normal
certificate-based authentication. This could be completely solved
by mandating ECH. Alternatively, it could be solved by sending the
PSK identifier after flight #1 when things are encrypted.

3GPP specified the use of server certificate authentication
combined with PSK authentication and key exchange for TLS 1.2. As
that mode was not available in RFC 8446, 3GPP does not specify this
mode for TLS 1.3 but there have recently been discussions in 3GPP
about adding RFC 8773. I think the really bad privacy properties of
PSK in TLS 1.3 is a significant problem for 3GPP. The bad privacy
properties of TLS 1.3 with PSK have also been discussed several
times in EMU WG. I think a mode that sends the PSK identifier
encrypted would make a lot more sense for standard track.

I am not supportive of standard track unless the tracking problem
is solved. If the privacy problems are solved, I am however very
supportive. Adding an extra roundtrip is a small price to pay for
privacy. Adding a field (psk identifier) that can be used for
tracking to current certificate-based TLS is making privacy worse.
I don’t think that is a good idea or worthy of standards track.

Cheers, John Preuß Mattsson

[1]
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ

 From: TLS mailto:tls-boun...@ietf.org>> on
behalf of Dan Harkins mailto:dhark...@lounge.org>> Date: Wednesday, 6 December 2023 at
14:50 To: TLS@ietf.org  mailto:tls@ietf.org>> Subject: Re: [TLS] Call to Move RFC 8773
from Experimental to Standards Track


Hi,

I approve of this transition to standards track and I am
implementing this as well.

regards,

Dan.

On 11/29/23 7:51 AM, Joseph Salowey wrote:

RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication
with an External Pre-Shared Key) was originally published as
experimental due to lack of implementations. As part of
implementation work for the EMU workitem
draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
ongoing implementation work. Since the implementation status of
RFC 8773 is changing, this is a consensus call to move RFC 8773
to standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis).




This will also help avoid downref for the EMU draft.  Please indicate

if you approve of or object to this transition to standards
track status by December 15, 2023.

Thanks,

Joe, Sean, and Deirdre

___ TLS mailing li

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-06 Thread Russ Housley

John:

I respond to your three suggested changes below:

(1) How about a title of "TLS 1.3 Extension for Using Certificates with an 
External Pre-Shared Key"

(2) None of the normative references are paywalled.  Two references are not 
RFCs or RFC errata or I-Ds or IANA web pages:

[GGM1986] is free access at https://dl.acm.org/doi/10.1145/6490.6503

[K2016] I found the same paper at https://eprint.iacr.org/2016/711.  
I'll point here.

(3) The privacy considerations already talk about Appendix E.6 of [RFC8446].  I 
am please to add a pointer to ECH, but I do not think that ECH use should not 
be mandated.

I suggest:

   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
   PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
   tracking prevention.  The guidance in these sections remain relevant.

   If an external PSK identity is used for multiple connections, then an
   observer will generally be able track clients and/or servers across
   connections.  The rotation of the external PSK identity or the use of
   the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate
   this risk.

Russ


> On Dec 6, 2023, at 11:51 AM, John Mattsson 
>  wrote:
> 
> Hi,
>  
> I am quite convinced that the security properties are not worse than a 
> mixture of PSK authentication, PSK key exchange, (EC)DHE key exchange, and 
> signature authentication.
>  
> In some cases, this is very good. You get the quantum-resistance of the PSK 
> together with the PFS of ECDHE, and the entity authentication and security 
> policies of certificates. In other cases, it is not so good as the reuse of a 
> PSK identifier enables tracking and potentially identification of both the 
> client and the server. I don’t think that such a field enabling tracking 
> belongs in modern TLS, but reuse of a PSK identifier is already in RFC 8446 
> so this document does theoretically not make the worst-case worse.
>  
> If RFC 8773 is updated. I think the following things should be updated:
> - The title and abstract only talks about PSK authentication. The key 
> exchange is likely more important to make quantum-resistant than the 
> authentication. I think the title and abstract should talk about PSK key 
> exchange.
> - I think the paywalled references should be removed. I think paywalled 
> references are both a cybersecurity risk and a democracy problem [1]. I don’t 
> think they belong in RFCs unless absolutely necessary. RFC 8446bis recently 
> removed all paywalled references.
> - The document should refer to section C.4 of RFC8446bis that now includes a 
> short discussion on that reuse of an PSK identifier enables tracking. I think 
> RFC8773bis should have a warning early that the privacy properties are much 
> worse than the normal certificate-based authentication. This could be 
> completely solved by mandating ECH. Alternatively, it could be solved by 
> sending the PSK identifier after flight #1 when things are encrypted.
>  
> 3GPP specified the use of server certificate authentication combined with PSK 
> authentication and key exchange for TLS 1.2. As that mode was not available 
> in RFC 8446, 3GPP does not specify this mode for TLS 1.3 but there have 
> recently been discussions in 3GPP about adding RFC 8773. I think the really 
> bad privacy properties of PSK in TLS 1.3 is a significant problem for 3GPP. 
> The bad privacy properties of TLS 1.3 with PSK have also been discussed 
> several times in EMU WG. I think a mode that sends the PSK identifier 
> encrypted would make a lot more sense for standard track.
>  
> I am not supportive of standard track unless the tracking problem is solved. 
> If the privacy problems are solved, I am however very supportive. Adding an 
> extra roundtrip is a small price to pay for privacy. Adding a field (psk 
> identifier) that can be used for tracking to current certificate-based TLS is 
> making privacy worse. I don’t think that is a good idea or worthy of 
> standards track.
>  
> Cheers,
> John Preuß Mattsson
>  
> [1] 
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ
>  
> From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
> Dan Harkins mailto:dhark...@lounge.org>>
> Date: Wednesday, 6 December 2023 at 14:50
> To: TLS@ietf.org  mailto:tls@ietf.org>>
> Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
> 
> 
>Hi,
> 
>I approve of this transition to standards track and I am implementing
> this as well.
> 
>regards,
> 
>Dan.
> 
> On 11/29/23 7:51 AM, Joseph Salowey wrote:
> > RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with 
> > an External Pre-Shared Key) was originally published as experimental 
> > due to lack of implementations. As part of implementation work for the 
> > EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there 
> > is ongoing implementation work. Since the implementation status of R

Re: [TLS] ECH: Changes to IANA consideration section

Hiya,

On 06/12/2023 19:46, Sean Turner wrote:

Okay a new proposal the ech_outer_extensions registration:
- Set "TLS 1.3" column to “CH”
- Include the following note in our new “Comments” column [0]: "Only appears in
inner CH."

Plenty good enough from my POV.

Cheers,
S.

spt

[0] PRs:
https://github.com/tlswg/rfc8447bis/pull/48
https://github.com/tlswg/rfc8447bis/pull/49

On Nov 29, 2023, at 16:09, Stephen Farrell wrote:

Hiya,

On 27/11/2023 14:35, Sean Turner wrote:

Bumping this up in case anybody missed it.

'case it helps, I'm fine with the original mail you sent and any of
"n/a" or "CH" being used rather than "-". If it helps, I've a very
minuscule hint of a preference for "CH" so you can count me as agreeing
with MT.

But I won't object to any other thing, 'cause I don't think there's a
perfect answer, and it matters very little, and defining a new thing
like "CHI" just for this seems OTT, but meh, I could even live with
that too.

I'd also be fine with this just left to chair/editor discretion FWIW.
While it's good to bring things like that to the list, I don't
think you need to delay based on a small-ish set of responses.

Cheers,
S.

spt

On Nov 21, 2023, at 21:03, Sean Turner wrote:

Hi! I sent over the early allocation request and the IANA folks rightly pointed
out two things that need to be added. This email is to make sure we have
agreement on the two changes to the registrations in s11.1. If you don’t agree
with the values proposed below please let the list know by 1 December 2023.

1. The encrypted_client_hello and ech_outer_extensions registrations need to
indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” is the
obvious value for both. See https://github.com/tlswg/draft-ietf-tls-esni/pull/584

2. The "TLS 1.3” column for ech_outer_extensions registration needs to indicate a
value; remember, this column indicates the messages in which the extension may appear.
Currently, it’s “”. “N/A" has been suggested, which makes sense to me considering
this extension never directly appears in CH, SH, EE, CT, CR, NST, or HRR extensions
field. We can’t use “-“ because that means not used in TLS 1.3. “” is used elsewhere in
the registry by only for unassigned and reserved values. The following PR change “” to
“N/A”: https://github.com/tlswg/draft-ietf-tls-esni/pull/59

Cheers,
spt

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

OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH: Changes to IANA consideration section

Okay a new proposal the ech_outer_extensions registration:
- Set "TLS 1.3" column to “CH”
- Include the following note in our new “Comments” column [0]: "Only appears in 
inner CH."

spt

[0] PRs:
https://github.com/tlswg/rfc8447bis/pull/48
https://github.com/tlswg/rfc8447bis/pull/49

> On Nov 29, 2023, at 16:09, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
> On 27/11/2023 14:35, Sean Turner wrote:
>> Bumping this up in case anybody missed it.
> 
> 'case it helps, I'm fine with the original mail you sent and any of
> "n/a" or "CH" being used rather than "-". If it helps, I've a very
> minuscule hint of a preference for "CH" so you can count me as agreeing
> with MT.
> 
> But I won't object to any other thing, 'cause I don't think there's a
> perfect answer, and it matters very little, and defining a new thing
> like "CHI" just for this seems OTT, but meh, I could even live with
> that too.
> 
> I'd also be fine with this just left to chair/editor discretion FWIW.
> While it's good to bring things like that to the list, I don't
> think you need to delay based on a small-ish set of responses.
> 
> Cheers,
> S.
> 
> 
> 
>> spt
>>> On Nov 21, 2023, at 21:03, Sean Turner  wrote:
>>> 
>>> Hi! I sent over the early allocation request and the IANA folks rightly 
>>> pointed out two things that need to be added. This email is to make sure we 
>>> have agreement on the two changes to the registrations in s11.1. If you 
>>> don’t agree with the values proposed below please let the list know by 1 
>>> December 2023.
>>> 
>>> 1. The encrypted_client_hello and ech_outer_extensions registrations need 
>>> to indicate the value for the "DTLS-Only” column. Unless I am mistaken, “N” 
>>> is the obvious value for both. See 
>>> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
>>> 
>>> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
>>> indicate a value; remember, this column indicates the messages in which the 
>>> extension may appear.  Currently, it’s “”. “N/A" has been suggested, which 
>>> makes sense to me considering this extension never directly appears in CH, 
>>> SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ because that 
>>> means not used in TLS 1.3. “” is used elsewhere in the registry by only for 
>>> unassigned and reserved values.  The following PR change “” to “N/A”: 
>>> https://github.com/tlswg/draft-ietf-tls-esni/pull/59
>>> 
>>> Cheers,
>>> spt
>> ___
>> 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] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-06 Thread Russ Housley

Christian:
> 
> Thanks. I am not 100% sure that we actually have an attack against the 
> [EC]DH+PSK combination, but I am confident than if the PSK secret is weak, 
> the attacker can get to the early data. If only for that, it is prudent to 
> use long enough PSK.

As stated in draft-ietf-tls-8773bis, some people are interested in using the 
external PSK with a certificate to protect against the future invention of a 
Cryptographically Relevant Quantum Computer (CRQC).  Others want to use of a 
public key with a factory-provisioned secret value for the initial enrollment 
of a device in an enterprise network (for example 
draft-ietf-emu-bootstrapped-tls).

For the security consideration, I suggest an additional paragraph:

Implementations must use sufficiently large external PSKs.  For 
protection
against the future invention of a CRQC, the external PSK needs to be at
least 256 bits.

Does that resolve your concern?

Russ


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

Re: [TLS] [tlswg/rfc8447bis] Add text discouraging registration of code points from other WGs and RGs. (PR #50)

Well, my hope would be that given that these drafts are being effectively 
proposed for RG/WG adoption, the RG/WG chairs would help manage the situation 
once the experts flagged it.

I believe most requests come in after adoption, but that’s based on my fallible 
memory.

Perhaps it's better to say that the applicant must consult TLS WG such as by 
sending email.

That would be fine with me.

Good.  My personal preference, as one of the DE’s, is to have little room for 
personal judgement.

Also, is the omission of Individual stream deliberate? (If so, why)

Do you mean "independent stream" here?

Yes. So was it deliberately omitted and if so why.

Finally, this is not appropriate for some registries (exporters, ALPN) and that 
should be explicitly called out.

So you agree with that point?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

2023-12-06 Thread Valery Smyslov

Hi John,

just a clarification:

The _GOSTR341112_ seems to include authentication and key exchange…. I did not 
think this was how TLS 1.3 cipher suites were supposed to be used.

No, they include only hash (GOSTR341112) and AEAD cipher (MAGMA_MGM 
or KUZNYECHIK_MGM).

Their order in the names is unusual (hash first, cipher second).

Regards,

Valery.

Cheers,

John Preuß Mattsson

From: Sean Turner 
Date: Wednesday, 6 December 2023 at 14:55
To: Salz, Rich , John Mattsson 
Cc: TLS List 
Subject: Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

> On Dec 6, 2023, at 08:02, Salz, Rich  
> wrote:
> 
> Yes, I think information regarding if a cipher suite is for TLS 1.3 is very 
> needed to have.  I already asked for that in
> https://mailarchive.ietf.org/arch/msg/tls/0gDKfXJvAemFDm7MWcS1DTDVIe8/
>  
> In addition, I would also like to information if the cipher suite can be used 
> in QUIC.
>  
> The 8447bis draft added a notes column to every TLS registry. The “1.2 is 
> frozen” draft says to use it to indicate things like “for TLS 1.3 and later”. 
> It’s a free-form text field, so we can direct IANA to put anything we want. :)

Yep we added it via:
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-cc6bdfdfb39824c6

&q=1&e=9148a29f-ecfe-46e0-869e-33ffd8475127&u=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fpull%2F48

spt

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

Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

2023-12-06 Thread Ilari Liusvaara

On Wed, Dec 06, 2023 at 03:46:32PM +, John Mattsson wrote:
> That sounds great.
> 
> Who is doing the work of adding “for TLS 1.3 and later”?
> 
> My understanding is that the currently registered TLS 1.3 cipher suites are:
> 
> Value Description
> 0x13,0x01 TLS_AES_128_GCM_SHA256
> 0x13,0x02 TLS_AES_256_GCM_SHA384
> 0x13,0x03 TLS_CHACHA20_POLY1305_SHA256
> 0x13,0x04 TLS_AES_128_CCM_SHA256
> 0x13,0x05 TLS_AES_128_CCM_8_SHA256
> 0x13,0x06 TLS_AEGIS_256_SHA512
> 0x13,0x07 TLS_AEGIS_128L_SHA256
> 0xC0,0xB0 TLS_ECCPWD_WITH_AES_128_GCM_SHA256
> 0xC0,0xB1 TLS_ECCPWD_WITH_AES_256_GCM_SHA384
> 0xC0,0xB2 TLS_ECCPWD_WITH_AES_128_CCM_SHA256
> 0xC0,0xB3 TLS_ECCPWD_WITH_AES_256_CCM_SHA384
> 0xC0,0xB4 TLS_SHA256_SHA256
> 0xC0,0xB5 TLS_SHA384_SHA384
> 0xC1,0x03 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L
> 0xC1,0x04 TLS_GOSTR341112_256_WITH_MAGMA_MGM_L
> 0xC1,0x05 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S
> 0xC1,0x06 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S

Also,

0x00,0xC6 TLS_SM4_GCM_SM3
0x00,0xC7 TLS_SM4_CCM_SM3 

Both are explicitly flagged as not OK for DTLS. However, using GCM/CCM
in usual way, so not difficult to define how those would work in DTLS
or QUIC (just copy what AES-128 does there).

> Note that “for TLS 1.3 and later” and “DTLS-OK” is not enough as some
> cipher suites (the _ECCPWD_ ones) seem to be valid for TLS 1.2,
> TLS 1.3, DTLS 1.2 but not DTLS 1.3….

If the _ECCPWD_ ones work for TLS 1.3, why wouldn't those work for DTLS
1.3 or QUIC? Those ciphersuites use AES in standard way, and DTLS/QUIC
do serialize the flights.

> Do we need some guidance/requirements on naming and use of TLS 1.3
> cipher suites? The _ECCPWD_ ones seem to include authentication in
> the TLS 1.3. The _GOSTR341112_ seems to include authentication and
> key exchange…. I did not think this was how TLS 1.3 cipher suites
> were supposed to be used.

Well, _ECCPWD_ is just special snowflake as it modifies the key
exchange (I haven't checked if what it does actually works). The GOST
ciphers do not seem to do anything special with key exchange (unlike
other things like seemingly rekeying for every record), so those
presumably should just be TLS_KUZNYECHIK_* and TLS_MAGMA_*.

The rekey-every-record the GOST ciphers do could pose a problem for
defining a mapping to DTLS or QUIC... Unless doing it like AES-GCM
was added to SECSH (a.k.a. SSH).

-Ilari

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-06 Thread John Mattsson

Hi,

I am quite convinced that the security properties are not worse than a mixture 
of PSK authentication, PSK key exchange, (EC)DHE key exchange, and signature 
authentication.

In some cases, this is very good. You get the quantum-resistance of the PSK 
together with the PFS of ECDHE, and the entity authentication and security 
policies of certificates. In other cases, it is not so good as the reuse of a 
PSK identifier enables tracking and potentially identification of both the 
client and the server. I don’t think that such a field enabling tracking 
belongs in modern TLS, but reuse of a PSK identifier is already in RFC 8446 so 
this document does theoretically not make the worst-case worse.

If RFC 8773 is updated. I think the following things should be updated:
- The title and abstract only talks about PSK authentication. The key exchange 
is likely more important to make quantum-resistant than the authentication. I 
think the title and abstract should talk about PSK key exchange.
- I think the paywalled references should be removed. I think paywalled 
references are both a cybersecurity risk and a democracy problem [1]. I don’t 
think they belong in RFCs unless absolutely necessary. RFC 8446bis recently 
removed all paywalled references.
- The document should refer to section C.4 of RFC8446bis that now includes a 
short discussion on that reuse of an PSK identifier enables tracking. I think 
RFC8773bis should have a warning early that the privacy properties are much 
worse than the normal certificate-based authentication. This could be 
completely solved by mandating ECH. Alternatively, it could be solved by 
sending the PSK identifier after flight #1 when things are encrypted.

3GPP specified the use of server certificate authentication combined with PSK 
authentication and key exchange for TLS 1.2. As that mode was not available in 
RFC 8446, 3GPP does not specify this mode for TLS 1.3 but there have recently 
been discussions in 3GPP about adding RFC 8773. I think the really bad privacy 
properties of PSK in TLS 1.3 is a significant problem for 3GPP. The bad privacy 
properties of TLS 1.3 with PSK have also been discussed several times in EMU 
WG. I think a mode that sends the PSK identifier encrypted would make a lot 
more sense for standard track.

I am not supportive of standard track unless the tracking problem is solved. If 
the privacy problems are solved, I am however very supportive. Adding an extra 
roundtrip is a small price to pay for privacy. Adding a field (psk identifier) 
that can be used for tracking to current certificate-based TLS is making 
privacy worse. I don’t think that is a good idea or worthy of standards track.

Cheers,
John Preuß Mattsson

[1] 
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ

From: TLS  on behalf of Dan Harkins 
Date: Wednesday, 6 December 2023 at 14:50
To: TLS@ietf.org 
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

   Hi,

   I approve of this transition to standards track and I am implementing
this as well.

   regards,

   Dan.

On 11/29/23 7:51 AM, Joseph Salowey wrote:
> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with
> an External Pre-Shared Key) was originally published as experimental
> due to lack of implementations. As part of implementation work for the
> EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there
> is ongoing implementation work. Since the implementation status of RFC
> 8773 is changing, this is a consensus call to move RFC 8773 to
> standards track as reflected in
> [RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis).
> This will also help avoid downref for the EMU draft.  Please indicate
> if you approve of or object to this transition to standards track
> status by December 15, 2023.
>
> Thanks,
>
> Joe, Sean, and Deirdre
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

___
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] Adoption call for 'TLS 1.2 Feature Freeze'

2023-12-06 Thread Bob Beck

I support adoption and am willing to review.

On Tue, Dec 5, 2023 at 10:34 PM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

2023-12-06 Thread John Mattsson

I support adoption. I also support making TLS 1.2 not recommended, discouraged, 
and deprecated. TLS 1.2 can be anything from quite good to very bad depending 
on configuration. Any work on TLS 1.2 is just delaying deployment of TLS 1.3.

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Christopher Patton 

Date: Wednesday, 6 December 2023 at 17:03
To: Deirdre Connolly 
Cc: TLS@ietf.org 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
I support adoption.
Chris P.

On Tue, Dec 5, 2023 at 9:34 PM Deirdre Connolly 
mailto:durumcrustu...@gmail.com>> wrote:
At the TLS meeting at IETF 118 there was significant support for the draft 'TLS 
1.2 is in Feature Freeze' 
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call is 
to confirm this on the list.  Please indicate if you support the adoption of 
this draft and are willing to review and contribute text. If you do not support 
adoption of this draft please indicate why.  This call will close on December 
20, 2023.

Thanks,
Deirdre, Joe, and Sean
___
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] RFC88447bis: additional DE instructions

 https://github.com/tlswg/rfc8447bis/pull/50

I have three comments, that I posted to the issue:
1. What does "discourage" mean? Imagine this email exchange:
Author: I want to register my new UNBREAKABLE crypto alg
DE: No
Author: But I can't break it
DE: No
Author: Please
DE: okl
Perhaps it's better to say that the applicant must consult TLS WG such as by 
sending email.

2. Also, is the omission of Individual stream deliberate? (If so, why)

3. Finally, this is not appropriate for some registries (exporters, ALPN) and 
that should be explicitly called out.

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

[TLS] RFC88447bis: additional DE instructions

Hi! A thread over on the IRTF’s CFRG list, see [0], has resulted in a PR, see 
[1], that includes additional instructions for the designated experts related 
to “Expert Review of Current and Potential IETF and IRTF Documents".  Please 
let us know what you think about the contents of the PR (here or in the PR). 
Also, please keep messages related to this PR on this list and off the CFRG 
list.

Thanks,
spt

[0] https://mailarchive.ietf.org/arch/msg/cfrg/QzxwN9hrSGHl0pBdWOhvfZ1UOhM/
[1] https://github.com/tlswg/rfc8447bis/pull/50

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

2023-12-06 Thread Christopher Patton

I support adoption.
Chris P.

On Tue, Dec 5, 2023 at 9:34 PM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] "Notes" column in draft-ietf-tls-rfc8447bis?

I am not aware of any particular work to say which ciphers can be used where.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

2023-12-06 Thread John Mattsson

That sounds great.

Who is doing the work of adding “for TLS 1.3 and later”?

My understanding is that the currently registered TLS 1.3 cipher suites are:

Value
Description
DTLS 1.3
QUIC
0x13,0x01
TLS_AES_128_GCM_SHA256
Y
Y
0x13,0x02
TLS_AES_256_GCM_SHA384
Y
Y
0x13,0x03
TLS_CHACHA20_POLY1305_SHA256
Y
Y
0x13,0x04
TLS_AES_128_CCM_SHA256
Y
Y
0x13,0x05
TLS_AES_128_CCM_8_SHA256
Y
N
0x13,0x06
TLS_AEGIS_256_SHA512
Y
Y
0x13,0x07
TLS_AEGIS_128L_SHA256
Y
Y
0xC0,0xB0
TLS_ECCPWD_WITH_AES_128_GCM_SHA256
N
N
0xC0,0xB1
TLS_ECCPWD_WITH_AES_256_GCM_SHA384
N
N
0xC0,0xB2
TLS_ECCPWD_WITH_AES_128_CCM_SHA256
N
N
0xC0,0xB3
TLS_ECCPWD_WITH_AES_256_CCM_SHA384
N
N
0xC0,0xB4
TLS_SHA256_SHA256
N
N
0xC0,0xB5
TLS_SHA384_SHA384
N
N
0xC1,0x03
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L
N
N
0xC1,0x04
TLS_GOSTR341112_256_WITH_MAGMA_MGM_L
N
N
0xC1,0x05
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S
N
N
0xC1,0x06
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S
N
N

(The DTLS 1.3 and QUIC information is my understanding. It is currently not in 
the IANA registry).

Note that “for TLS 1.3 and later” and “DTLS-OK” is not enough as some cipher 
suites (the _ECCPWD_ ones) seem to be valid for TLS 1.2, TLS 1.3, DTLS 1.2 but 
not DTLS 1.3….

I think the notes column should contain info on DTLS 1.3 and QUIC as well.

Do we need some guidance/requirements on naming and use of TLS 1.3 cipher 
suites?
The _ECCPWD_ ones seem to include authentication in the TLS 1.3. The 
_GOSTR341112_ seems to include authentication and key exchange…. I did not 
think this was how TLS 1.3 cipher suites were supposed to be used.

Cheers,
John Preuß Mattsson

From: Sean Turner 
Date: Wednesday, 6 December 2023 at 14:55
To: Salz, Rich , John Mattsson 
Cc: TLS List 
Subject: Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

> On Dec 6, 2023, at 08:02, Salz, Rich  
> wrote:
>
> Yes, I think information regarding if a cipher suite is for TLS 1.3 is very 
> needed to have.  I already asked for that in
> https://mailarchive.ietf.org/arch/msg/tls/0gDKfXJvAemFDm7MWcS1DTDVIe8/
>
> In addition, I would also like to information if the cipher suite can be used 
> in QUIC.
>
> The 8447bis draft added a notes column to every TLS registry. The “1.2 is 
> frozen” draft says to use it to indicate things like “for TLS 1.3 and later”. 
> It’s a free-form text field, so we can direct IANA to put anything we want. :)

Yep we added it via:
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-cc6bdfdfb39824c6&q=1&e=9148a29f-ecfe-46e0-869e-33ffd8475127&u=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fpull%2F48

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

2023-12-06 Thread Arnaud Taddei

Speaking of this, just a naïve question, is there anyone who knows about a 
survey with say enterprise organizations on how they see TLS1.2 and their plans 
to move to TLS1.3 and where they struggle with?

If not, would it be an idea to organize a survey?

Just 0.02 CHF

From: TLS  on behalf of Sean Turner 
Date: Wednesday, 6 December 2023 at 14:56
To: Stephen Farrell 
Cc: TLS List 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

> On Dec 6, 2023, at 07:57, Stephen Farrell  wrote:
>
> Signed PGP part
>
>
> On 06/12/2023 05:33, Deirdre Connolly wrote:
>> At the TLS meeting at IETF 118 there was significant support for the draft
>> 'TLS 1.2 is in Feature Freeze' (
>> https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/&source=gmail-imap&ust=170247578500&usg=AOvVaw20RCQnXd-R21nczuXpPJrf)
>>   This call
>> is to confirm this on the list.  Please indicate if you support the
>> adoption of this draft and are willing to review and contribute text.
>
> I read the draft and support adopting this. It'll probably
> change as we go in some way or other but it's better that
> the WG figure that out based on a WG draft.
>
> Cheers,
> S.

Yes, it is a starting point. Where we end up is TBD.

spt

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


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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

2023-12-06 Thread David Benjamin

I support adoption and am willing to review.

On Wed, Dec 6, 2023 at 12:34 AM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

2023-12-06 Thread Nimrod Aviram

> As the co-author, I support this and am willing to continue working on it
as needed.
Same here.


On Wed, 6 Dec 2023 at 14:51, Salz, Rich 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/
> )
>  This call is to confirm this on the list.  Please indicate if you support
> the adoption of this draft and are willing to review and contribute text.
> If you do not support adoption of this draft please indicate why.  This
> call will close on December 20, 2023.
>
>
>
> As the co-author, I support this and am willing to continue working on it
> as needed.
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'


> On Dec 6, 2023, at 07:57, Stephen Farrell  wrote:
> 
> Signed PGP part
> 
> 
> On 06/12/2023 05:33, Deirdre Connolly wrote:
>> At the TLS meeting at IETF 118 there was significant support for the draft
>> 'TLS 1.2 is in Feature Freeze' (
>> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call
>> is to confirm this on the list.  Please indicate if you support the
>> adoption of this draft and are willing to review and contribute text.
> 
> I read the draft and support adopting this. It'll probably
> change as we go in some way or other but it's better that
> the WG figure that out based on a WG draft.
> 
> Cheers,
> S.

Yes, it is a starting point. Where we end up is TBD.

spt



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?


> On Dec 6, 2023, at 08:02, Salz, Rich  
> wrote:
> 
> Yes, I think information regarding if a cipher suite is for TLS 1.3 is very 
> needed to have.  I already asked for that in
> https://mailarchive.ietf.org/arch/msg/tls/0gDKfXJvAemFDm7MWcS1DTDVIe8/
>  
> In addition, I would also like to information if the cipher suite can be used 
> in QUIC.
>  
> The 8447bis draft added a notes column to every TLS registry. The “1.2 is 
> frozen” draft says to use it to indicate things like “for TLS 1.3 and later”. 
> It’s a free-form text field, so we can direct IANA to put anything we want. :)

Yep we added it via:
https://github.com/tlswg/rfc8447bis/pull/48

spt

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

2023-12-06 Thread Dan Harkins



  Hi,

  I approve of this transition to standards track and I am implementing
this as well.

  regards,

  Dan.

On 11/29/23 7:51 AM, Joseph Salowey wrote:
RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with 
an External Pre-Shared Key) was originally published as experimental 
due to lack of implementations. As part of implementation work for the 
EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there 
is ongoing implementation work. Since the implementation status of RFC 
8773 is changing, this is a consensus call to move RFC 8773 to 
standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). 
This will also help avoid downref for the EMU draft.  Please indicate 
if you approve of or object to this transition to standards track 
status by December 15, 2023.


Thanks,

Joe, Sean, and Deirdre

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


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

2023-12-06 Thread Peter Gutmann

Deirdre Connolly  writes:

>At the TLS meeting at IETF 118 there was significant support for the draft
>'TLS 1.2 is in Feature Freeze' (
>https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call is
>to confirm this on the list.  Please indicate if you support the adoption of
>this draft and are willing to review and contribute text. If you do not
>support adoption of this draft please indicate why.  This call will close on
>December 20, 2023.

I don't see what the point of this draft is.  For anyone who's already made
the switch to TLS 1.3 it's irrelevant, and for people who will have to support
TLS 1.2 deployments probably for the rest of eternity it makes it impossible
to make any changes or fixes.  At best it does nothing, at worst it makes life
very difficult for anyone who has to keep maintaining TLS 1.2 systems.

Peter.

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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

2023-12-06 Thread Dmitry Belyavsky

I support adoption of this draft.

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
SY, Dmitry Belyavsky
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

2023-12-06 Thread Arnaud Taddei

Am comfortable too

From: TLS  on behalf of Salz, Rich 

Date: Wednesday, 6 December 2023 at 13:50
To: Deirdre Connolly , TLS@ietf.org 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
At the TLS meeting at IETF 118 there was significant support for the draft 'TLS 
1.2 is in Feature Freeze' 
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)
  This call is to confirm this on the list.  Please indicate if you support the 
adoption of this draft and are willing to review and contribute text. If you do 
not support adoption of this draft please indicate why.  This call will close 
on December 20, 2023.

As the co-author, I support this and am willing to continue working on it as 
needed.

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

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

Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

Yes, I think information regarding if a cipher suite is for TLS 1.3 is very 
needed to have.  I already asked for that in
https://mailarchive.ietf.org/arch/msg/tls/0gDKfXJvAemFDm7MWcS1DTDVIe8/

In addition, I would also like to information if the cipher suite can be used 
in QUIC.

The 8447bis draft added a notes column to every TLS registry. The “1.2 is 
frozen” draft says to use it to indicate things like “for TLS 1.3 and later”. 
It’s a free-form text field, so we can direct IANA to put anything we want. :)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'




On 06/12/2023 05:33, Deirdre Connolly wrote:

At the TLS meeting at IETF 118 there was significant support for the draft
'TLS 1.2 is in Feature Freeze' (
https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call
is to confirm this on the list.  Please indicate if you support the
adoption of this draft and are willing to review and contribute text.


I read the draft and support adopting this. It'll probably
change as we go in some way or other but it's better that
the WG figure that out based on a WG draft.

Cheers,
S.



OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'