I honestly think it is not, given the context – not until you read the IANA section. I would suggest: no changes (including any extensions). On 10/12/2024, 17:18, "Salz, Rich" wrote:English is hard. :). I think "no new features" is clear, given the context of the words around it. I could change it
Does this diff address your concern? What about the title? As I recall, the
draft originally said “TLS 1.2 is frozen” but there were some who wanted it
changed.
--- a/draft-ietf-tls-tls12-frozen.md
+++ b/draft-ietf-tls-tls12-frozen.md
@@ -70,7 +70,7 @@ Use of TLS 1.3 is growing and fixes some k
The point of this draft was to go on the record (“it’s an RFC it must be true”)
and say explicitly what the IETF will NOT be doing, and enforcing that by
directing IANA (and the experts). Will this stop someone from re-using
codepoints and backporting to their TLS 1.2 stack? Nope. It even work
Hello,
1. **Alignment of NamedGroup X25519MLKEM768** with the order of shared
secrets, as per Section 3.2 of draft-ietf-tls-hybrid-design.
- I suggest updating the name to mlkem768_x25519, while keeping the
codepoint unchanged (if that is acceptable). If
this change is made, I also re
On Tue, Dec 10, 2024 at 4:28 PM Kris Kwiatkowski
wrote:
> Following the feedback from the last TLS meeting at IETF@121, I have
> opened this PR to change the name from X25519MLKEM768 to MLKEM768X25519.
> This change aligns with draft-ietf-tls-hybrid-design-11 (section 3.2).
>
Well, maybe the Spa
This document has consensus to adopt, please post a 00 draft
named draft-ietf-tls-rfc9147bis to be included as a working group document.
On Mon, Dec 2, 2024 at 9:38 AM Joseph Salowey wrote:
> This is a call for adoption of draft-rescorla-tls-rfc9147bis-00[1] as the
> basis for an RFC9147 bis doc
The TLS WG has placed draft-rescorla-tls-rfc9147bis in state
Adopted by a WG (entered by Sean Turner)
The document is available at
https://datatracker.ietf.org/doc/draft-rescorla-tls-rfc9147bis/
___
TLS mailing list -- tls@ietf.org
To unsubscribe send
Hi all,
I think this document is ready for publication.
Cheers,
Thom Wiggers
Op ma 9 dec 2024 om 17:53 schreef Sean Turner :
> Just a reminder that this WG last call is still ongoing.
>
> spt
>
> > On Dec 3, 2024, at 16:26, Sean Turner wrote:
> >
> > This is the working group last call for TL
As for it accidentally becoming “MTI”, well I’m pretty sure that won’t happen
(barring Q-day happening and the current hybrid key exchanges no longer making
sense).
Since the draft has “N” for the recommended column, I’m also pretty sanguine
about it.
As for people implementing it instead of h
jQcmQRYFpfptBannerEnd
For the second paragraph, I would prefer “no changes and no new extension
values”. I don’t have a better idea for the title, so even if I think it’s not
100% precise, I’m good with keeping it.
How about this?
This document specifies that outside of
urgent security fixes, an
Looks good. Thanks! From: Salz, Rich Date: Tuesday, 10 December 2024 at 18:41To: Yaron Sheffer , Alicja Kario Cc: TLS List Subject: Re: [TLS] Re: Working Group Last Call for TLS 1.2 is in Feature FreezejQcmQRYFpfptBannerEndFor the second paragraph, I would prefer “no changes and no new extension va
I would suggest "For TLS, it is important to note that PQC efforts are
exclusively for TLS 1.3 or later."
To me, the draft (even v3) is not clear on this point. At some point in future,
PQ will become an urgent security issue, and the wording "outside of urgent
security fixes" in the draft see
Thanks for the update. Just a quick reminder that my questions at the bottom of
email [1] remain unaddressed.
Usama
[1] https://mailarchive.ietf.org/arch/msg/tls/6QoaLDE3_2UQTcawV2QQznQ5Pbs/
Aha, I missed that, sorry. I will reply on-thread now.
___
T
Considering the following two statements in I-D, I have two questions:
> For TLS it is important to note that the focus of these efforts is
> TLS 1.3 or later. Put bluntly, post-quantum cryptography for TLS 1.2
> WILL NOT be supported.
To me the two sentences are contradicting. Which one
One of the things we need to be honest with ourselves about is that telling
people not to do it won’t prevent them from doing it.
So this decision is saying that WHEN people decide do PQC with TLS 1.2, they
will be doing so without IETF guidance about how to do it. If this is the path
we cho
On 10.12.24 16:02, Salz, Rich wrote:
The second sentence is intended to be a clarification and emphasis of
the first. I’m not aware of any TLS WG efforts to define PQC and
register them for TLS 1.2 and I believe the WG assumption – perhaps
unstated? – is that these things require and assume TL
For the second paragraph, I would prefer “no changes and no new extension values”. I don’t have a better idea for the title, so even if I think it’s not 100% precise, I’m good with keeping it. From: Salz, Rich Date: Tuesday, 10 December 2024 at 17:45To: Yaron Sheffer , Alicja Kario Cc: TLS List Sub
On 10.12.24 17:47, Salz, Rich wrote:
How about this:
For TLS it is important to note that the focus of these efforts is
exclusively TLS 1.3 or later. Put bluntly, post-quantum cryptography
for TLS 1.2 WILL NOT be supported (see {{iana}}) at any time and
anyone wishing to deploy post-quantum
English is hard. :). I think "no new features" is clear, given the context of
the words around it. I could change it to "no changes" without changing the
intended meaning if people prefer that.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send
Thanks for the update. Just a quick reminder that my questions at the
bottom of email [1] remain unaddressed.
Usama
[1] https://mailarchive.ietf.org/arch/msg/tls/6QoaLDE3_2UQTcawV2QQznQ5Pbs/
smime.p7s
Description: S/MIME Cryptographic Signature
___
I think the draft is confusing to the point of almost being misleading, in particular with its use of the word “feature”. Based on the words “feature freeze” people on this list have interpreted it as merely “the TLS WG will no longer work on TLS 1.2”. But by blocking IANA registrations, this has m
No, support for a new ciphersuite, especially one that uses new primitives,
is a _new feature._
At least, that's how we operate, and I am not aware of any discussions
about
that being confusing to customers... So I'm pretty sure that "Most people"
is
not correct.
On Tuesday, 10 December 2024
Daniel
I’m writing in response to your request below. I am told that your email
server may require me to agree to terms before delivery, which I will not be
doing, so it may be that this response is not delivered directly.
While I am an author of RFC 9680 it is an IETF consensus document and t
23 matches
Mail list logo
