I think an adoption call is a bit premature here. We've got some time,
especially in the WebPKI setting.
In particular, we should have a discussion of whether we want to
standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean
towards the latter, but I, at least, would like to hear
On Fri, 18 Oct 2024 at 15:12, Salz, Rich
wrote:
> To me, this trumps geek esthetics about making things line up.
>
To be clear, my objection is not aesthetic or even about implementation
effort. My concern is about rubber-stamping whatever unprincipled things
that NIST comes up with.
I also agr
Dear David Lawrence (cc: Benjamin Schwartz, tls WG),
As a designated expert for the Service Parameter Keys (SvcParamKeys) registry,
can you review the proposed registration modification in
draft-ietf-tls-svcb-ech-06 for us? Please note that Benjamin Schwartz is a
co-author on this document.
P
Agree completely, the only thing that can go wrong with this draft is scope
creep.
-Tim
From: Deirdre Connolly
Sent: Wednesday, October 23, 2024 3:22 PM
To: Alicja Kario
Cc: Bas Westerbaan ;
Subject: [TLS] Re: ML-DSA in TLS
I would rather have a separate I-D for anything beyond M
Hi all,
Unless I overlooked something, we don't have a draft out to assign a
SignatureAlgorithm to ML-DSA for use in TLS.
It's two days past the I-D submission deadline, but I wanted to point you
to a short draft we put together to fill this gap.
https://bwesterb.github.io/tls-mldsa/draft-tls-we
Alicja, John, thanks for your review.
Onto Alicja's open comments:
- illegal_parameter alert if the peer used algorithm not advertised, or
>signature algorithm does not match the certificate
> - decrypt_error when verification of the signature failed
Good points, but these stipulations ar
On Wednesday, 23 October 2024 20:01:28 CEST, John Mattsson wrote:
Let’s have an adoption call asap.
I made some minor suggestions
https://github.com/bwesterb/tls-mldsa/pull/3
good catch on the signature_algorithms_cert part!
and on that front, I wonder if we shouldn't also include SLH-DSA
c
Hey all,
I'm working on implementing server-side ECH in the Go standard library TLS
implementation, and ran across what I think is an error in Section 7.
Additionally I had a question about the distinction between modes described
in that section.
First off on the error, the paragraph about shared
I would rather have a separate I-D for anything beyond ML-DSA (and thanks,
this is great!)
On Wed, Oct 23, 2024 at 2:13 PM Alicja Kario wrote:
> On Wednesday, 23 October 2024 20:01:28 CEST, John Mattsson wrote:
> > Let’s have an adoption call asap.
> >
> > I made some minor suggestions
> > https
Hi all,
Be noted that in this discussion, I don't speak on behalf of anybody else
including the NIST PQC team and my message does not intent to imply any
technical policies in the future. I just wanted to explain some technical
matters.
In SP 800-56C, we specified Z = Z' || T as an option whe
Let’s have an adoption call asap.
I made some minor suggestions
https://github.com/bwesterb/tls-mldsa/pull/3
John
From: Alicja Kario
Date: Wednesday, 23 October 2024 at 19:59
To: Bas Westerbaan
Cc:
Subject: [TLS] Re: ML-DSA in TLS
Hi,
Thanks for the draft, will definitely be helpful.
Few is
Hi,
Thanks for the draft, will definitely be helpful.
Few issues:
* The range 0x0900-0x0903 is reserved for backwards compatibility
I think it will be better to continue the numbering in the 0x08.. space
* the must in "must use id_ML-DSA(...)" probably should be capitalised, as
if it doesn't
Reviewer: Barry Leiba
Review result: Ready with Nits
Just two small comments on this straightforward document:
— Section 3 —
Figure 1: ECH SvcParam with a public_name of "ech-sites.example.com"
The example actually encodes example.net, not example.com
[This was a test to see if we check these
Oh I definitely agree there is a deeper problem here. It seems like NIST
wrote something over-restrictive and then folks did a preemptive compliance
maneuver to try to satisfy it. This is not a good way to do protocol
development and hampers what should ultimately have been the goal for
everyone: m
I agree. X25518MLKEM768 has shipped, so we should just leave it alone.Best,Chris On Oct 17, 2024, at 11:38 AM, David Benjamin wrote:Specifically the X25519MLKEM768 is widely deployed already. I'm not aware of any deployments of the other hybrids. I am very strongly opposed to incompatible changes
15 matches
Mail list logo
