On Tue, Mar 25, 2025 at 6:26 AM Salz, Rich wrote:
> The formatting is really messed up here. I will preface my inline comments
> with “R$ 25-Mar” I removed the points where we agree (mainly I changed the
> text and you approved it :)
>
> *WG may tell them to migrate to TLS 1.3. In order to avoid
I was mostly looking for something like "DTLS usage is not restricted" or "This
restriction does not apply to use in DTLS" as a separate sentence. It's the
fact that the entry, rather than the restriction, is the subject of the current
sentence. That's correct for the "intended for use in TLS 1.
Hi Viktor,
Thanks for the detail explanation.
> Noting the sizes in an order that is different from the wire order is not
> IMHO a significant issue, given explicit language defining the wire order
> elsewhere, ... though of course switching the order of exposition, just in
> case someone mig
On 18 Mar 2025, at 11:53, Salz, Rich wrote:
>> So, again: This draft should either be expanded to say what TLS clients and
>> servers and configuration SHOULD / MUST do with D-level components, or tell
>> readers why it is not. Telling developers "go look at every doc that is
>> liked from a D-
Hi,
I have read this draft and have two questions.
1. X25519MLKEM768 is the concatenation of ML-KEM and X25519. Why
SecP256r1MLKEM768/SecP384r1MLKEM1024 use a different order? ML-KEM part comes
after the EC share.
2. In Section 3.1.3. Server share:
When the SecP256r1MLKEM768 group is negotia
Hi Rich,
Thank you.
This looks good, except this change that was agreed:
OLD: Any registries created after this document is approved for publication
NEW: Any TLS registry created after this document is approved for publication
Sent you a PR to fix this https://github.com/tlswg/tls12-frozen/pull
I had talked with IANA about this last week and we think one column is best.
From: Mike Bishop
Date: Thursday, March 27, 2025 at 3:41 PM
To: Salz, Rich , The IESG
Cc: draft-ietf-tls-tls12-fro...@ietf.org
, tls-cha...@ietf.org
, tls@ietf.org , s...@sn3rd.com
Subject: Re: Mike Bishop's No Obje
This case is a protocol error and should abort the handshake, not handle
retry configs. I think that's the correct behavior. This is spelled out in
the draft already:
https://www.ietf.org/archive/id/draft-ietf-tls-esni-24.html#section-6.1.5-5
https://www.ietf.org/archive/id/draft-ietf-tls-esni-24.h
Thanks for catching the one one that almost got away :). Your changes look
good, merged.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
On Thu, Mar 27, 2025 at 10:10:49AM +, Sun Shuzhou wrote:
> I have read this draft and have two questions.
>
> 1. X25519MLKEM768 is the concatenation of ML-KEM and X25519. Why
> SecP256r1MLKEM768/SecP384r1MLKEM1024 use a different order? ML-KEM
> part comes after the EC share.
Inconsequentia
10 matches
Mail list logo
