Hi! The chairs have judged that there is consensus to request an early code
point for this draft-ietf-tls-tlsflags. I will send a message to the DEs and
IANA to get this code point assigned.
The following PR creates the TLS Flags sub-registry where we can manage the
actual flags. I asserted tha
Hi! The chairs have judged that there is consensus to request an early code
point for this I-D.
While there was some discussion about what the Name value should be, there was
no consensus on a new Name value and it is not clear that choosing a different
name from where the values comes from is
At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS and
DTLS I-D; see [0] and [1]. There has been some list discussion; see [2] and
[3]. The I-D has been revised a few times since IETF 119 to incorporate list
feedback. This message is to judge consensus on whether there is
I don't think a MUST would be totally inappropriate but it's possible to
get into a state where you have a mismatch due to DNS latency or partial
rollback, so this MUST will be violated in practice in some cases (though
as you indicate, that's not good). ECH has a way to recover from these
conditio
Hiya,
On 23/10/2024 18:29, Bas Westerbaan wrote:
Unless I overlooked something, we don't have a draft out to assign a
SignatureAlgorithm to ML-DSA for use in TLS.
I don't think a gap in the set of documentation is
anywhere near a good reason to add things to TLS.
I also agree with ekr that
>
> Unfortunately, the mechanism to combine the two signatures can also
> fail, and its failure can end up totally undermining security.
> So it is not just pure backup.
Yes.
I don't agree with composite signatures being slightly more complicated.
> I think that composite signatures are much mo
> Today for the WebPKI there is no security benefit to enabling
post-quantum certificates (in stark contrast with post-quantum key
agreement.) On the other hand, there is a big cost with extra bytes on the
wire. As it stands, we do not intend to enable post-quantum certificates by
default before th
On Thu, Oct 24, 2024 at 8:52 AM Tim Hollebeek
wrote:
>
> My personal feelings on pure vs composite are actually the union of several
> previous comments:
>
> 1. Like EKR, I actually have a weak preference for composite, all other
> things being equal. Failures happen and I like backup mechanis
My personal feelings on pure vs composite are actually the union of several
previous comments:
1. Like EKR, I actually have a weak preference for composite, all other
things being equal. Failures happen and I like backup mechanisms
when they are relatively affordable and can be afforded.
On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote:
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 toget
Thanks for noticing the example.net error. Fixed! [1].
I think we made that a SHOULD for contrast with the requirement that the server
prove authority for public_name. If the server isn't authoritative for
public_name, the connection will fail completely, so that's a MUST. If the
server has
> -Original Message-
> From: ilariliusva...@welho.com
> Sent: Thursday, October 24, 2024 1:03 PM
> To:
> Subject: [TLS] Re: ML-DSA in TLS
>
> On Thu, Oct 24, 2024 at 03:51:50PM +, Tim Hollebeek wrote:
> > 3. Composite is slightly more complicated, though not as complicated as its
Today for the WebPKI there is no security benefit to enabling post-quantum
certificates (in stark contrast with post-quantum key agreement.) On the
other hand, there is a big cost with extra bytes on the wire. As it stands,
we do not intend to enable post-quantum certificates by default before the
On Wednesday, 23 October 2024 22:46:08 CEST, Bas Westerbaan wrote:
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
On Thursday, 24 October 2024 04:47:02 CEST, Eric Rescorla wrote:
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
On Thu, Oct 24, 2024 at 8:55 AM John Mattsson
wrote:
> I have gotten the understanding, see e.g., [1-2], that the WebPKI might
> wait for FN-DSA or wait even longer for something like MAYO, UOC, HAWK, and
> SQISign.
>
>From a performance perspective MAYO looks really nice, but we'd be really
pus
In my opinion, we’ll end up standardizing both. At the very least, I (Cisco)
have some customers who want ML-DSA only, and other customers that insist on
hybrid, and so we’ll need to support both.
Standardizing ML-DSA only appears to be straightforward – we just need to
assign some code words,
Hi Scott, Ekr,
Good points. In the telecom industry, which is seen as critical infrastructure,
we do not have time and we use TLS/DTLS/QUIC for a large number of interfaces.
We already have governments and customers telling us that all public-key crypto
should be quantum-resistant by 2030. I wo
David Dong via RT writes:
> 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.
Yes, the request is rev
I support the adoption. I also think we will end up standardizing pure ML-DSA
anyway.
Modify the TLS protocol to rely on multiple certificates (one of which might
be a traditional RSA certificate and one an ML-KEM only certificate)?
+1. Composite signatures are also interesting, but since TLS a
20 matches
Mail list logo
