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
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
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
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
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
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
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
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
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
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
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
> 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' (
>>
> 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
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
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
At the TLS meeting at IETF 118 there was significant support for the draft 'TLS
1.2 is in Feature Freeze'
> 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' (
>
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
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
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
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
On Tue, Dec 05, 2023 at 06:24:33PM -0800, Christian Huitema wrote:
>
> Yes. Both are used to compute the "early secret" -- external PSK for the
> initial handshake, resumption PSK in subsequent handshakes. If the secrets
> are "short" and the attacker can use early data as some kind of oracle,
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).
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
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]
I support adoption.
On Thu, 7 Dec 2023 at 05:55, David Schinazi
wrote:
> I support adoption.
> David
>
> On Wed, Dec 6, 2023 at 4:16 PM Rob Sayre wrote:
>
>> Hi,
>>
>> I support adoption.
>>
>> thanks,
>> Rob
>>
>>
>> On Tue, Dec 5, 2023 at 9:35 PM Deirdre Connolly
>> wrote:
>>
>>> At the TLS
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:
Hi,
I support adoption.
thanks,
Rob
On Tue, Dec 5, 2023 at 9:35 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
I support adoption.
David
On Wed, Dec 6, 2023 at 4:16 PM Rob Sayre wrote:
> Hi,
>
> I support adoption.
>
> thanks,
> Rob
>
>
> On Tue, Dec 5, 2023 at 9:35 PM Deirdre Connolly
> wrote:
>
>> At the TLS meeting at IETF 118 there was significant support for the
>> draft 'TLS 1.2 is in Feature
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,
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
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
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:
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
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
35 matches
Mail list logo
