Not sure I understand your point, Watson, but for the environments that
cannot tweak configuration, or otherwise effectively turn on/off
algorithms, a composite signature with a PQ and an ECC algorithm is the
most viable option.
On Fri, Nov 15, 2024 at 3:02 PM Watson Ladd wrote:
>
>
> On Fri, No
Hiya,
On 16/11/2024 00:17, Joseph Salowey wrote:
This is the working group last call for SSLKEYLOGFILE Extension for
Encrypted Client Hello. Please review draft-ietf-tls-ech-keylogfile-01 [1]
and reply to this thread indicating if you think it is ready for
publication or not. If you do not thi
A few things jumped out about IANA registries. The first is a silly
process question that might be really ugly to address now (and require
the IESG)
Shouldn't the IANA registry here be made by the
draft-ietf-tls-keylogfile? That would make more sense.
And we don't seem to tell IANA to add the new
On Fri, Nov 15, 2024, 3:32 PM Andrey Jivsov wrote:
> Not sure I understand your point, Watson, but for the environments that
> cannot tweak configuration, or otherwise effectively turn on/off
> algorithms, a composite signature with a PQ and an ECC algorithm is the
> most viable option.
>
Why no
I am curious why this draft exclusively proposes ML-DSA, instead of
adopting a composite signature approach as outlined in
draft-ounsworth-pq-composite-sigs, at least as an option. For instance,
id-MLDSA87-ECDSA-P384-SHA512 defined in the draft aligns with CNSA 2.0.
Could supporters of the draft e
On Fri, Nov 15, 2024, 9:13 AM John Mattsson wrote:
> >I'm unenthusiastic but don't strongly oppose adoption of this and
>
> >similar drafts, mostly because I think we should try get some WG
>
> >consensus on guidance for when these things may be needed (if ever)
>
> >and what the consequences mig
On Friday, 15 November 2024 18:38:56 CET, Andrey Jivsov wrote:
I am curious why this draft exclusively proposes ML-DSA,
instead of adopting a composite signature approach as outlined
in draft-ounsworth-pq-composite-sigs, at least as an option. For
instance, id-MLDSA87-ECDSA-P384-SHA512 defined
On Friday, 15 November 2024 18:12:28 CET, John Mattsson wrote:
I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for when these things may be needed (if ever)
and what the consequences might be
I happen to think that standalone ML-DSA in TLS is a controversial issue.
In practice, PQ authentication is not an immediate issue in a sense of
"record now, decrypt later". We expect TLS servers to continue to be
configured with RSA key pair (key+cert) and ECDSA key pair. We are talking
about wha
On Friday, 15 November 2024 18:33:27 CET, Stephen Farrell wrote:
Hiya,
On 15/11/2024 17:12, John Mattsson wrote:
WebPKI might want to wait but the many infrastructure use cases of
TLS, DTLS, and QUIC need to migrate very soon. US government new
requirement is that pure RSASSA, ECDSA, and EdDSA
On 11/15/2024 9:57 AM, Raghu Saxena wrote:
Hey Ed,
On 11/16/24 1:08 AM, evasi...@yandex.ru wrote:
Actually, it is not a problem for them, not at all.
As I stated in the message that you did not copy in the quote: they
would filter out any Hello that has nested InnerHello.
It is pretty automat
I also support WG adoption.
One suggestion in the Introduction:
"ML-DSA [FIPS204] is a post-quantum signature schemes standardised by NIST. It
is a module-lattice based scheme." -> "ML-DSA is a module-lattice-based digital
signature algorithm standardised by NIST in [FIPS204]."
And one suggest
Hi Raghu,
OTTs reading this statement about privacy is probably laughing.
OTTs are collecting the volume of private information - they are the primary
danger for privacy. ECH would not help even theoretically.
Hence, I do not care about privacy. It is not possible anyway.
I remember a good joke, i
>I'm unenthusiastic but don't strongly oppose adoption of this and
>similar drafts, mostly because I think we should try get some WG
>consensus on guidance for when these things may be needed (if ever)
>and what the consequences might be should people deploy 'em in the
>meantime. (By 'em I mean any
This is the working group last call for SSLKEYLOGFILE Extension for
Encrypted Client Hello. Please review draft-ietf-tls-ech-keylogfile-01 [1]
and reply to this thread indicating if you think it is ready for
publication or not. If you do not think it is ready please indicate why.
This call will en
Classic McEllice team shows that over the last 10 years lattice crypto
strength dropped as the equivalence of AES192 to AES128. Will this trend
continue?
In some deployments there may be a need to turn on a PQ method soon, and
keep using, e.g. when configurability is not an option. Also, if a chan
On Fri, Nov 15, 2024, 2:59 PM Andrey Jivsov wrote:
> Classic McEllice team shows that over the last 10 years lattice crypto
> strength dropped as the equivalence of AES192 to AES128. Will this trend
> continue?
>
> In some deployments there may be a need to turn on a PQ method soon, and
> keep us
Christian,
I believe the issue that we are currently observing with "blocked ECH" is
specific to how public SNI is constructed. A given CDN uses a certain
pre-defined public name for all ECH enabled resources - hence an inline
filtering party that wants to prevent ECH can match on that specific pu
Hello Watson,
On Sat, Nov 16, 2024 at 1:47 AM Watson Ladd wrote:
> A few things jumped out about IANA registries. The first is a silly
> process question that might be really ugly to address now (and require
> the IESG)
>
> Shouldn't the IANA registry here be made by the
> draft-ietf-tls-keylogf
On 11/15/2024 4:28 PM, Stephen Farrell wrote:
Hiya,
On 16/11/2024 00:17, Joseph Salowey wrote:
This is the working group last call for SSLKEYLOGFILE Extension for
Encrypted Client Hello. Please review
draft-ietf-tls-ech-keylogfile-01 [1]
and reply to this thread indicating if you think it i
Hiya,
On 16/11/2024 02:48, Yaroslav Rosomakho wrote:
I believe the issue that we are currently observing with "blocked ECH" is
specific to how public SNI is constructed. A given CDN uses a certain
pre-defined public name for all ECH enabled resources - hence an inline
filtering party that want
We have posted a -00.
https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00
On Wed, Oct 23, 2024 at 7:29 PM 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 p
Dear Ed,
On 11/15/24 4:09 AM, evasi...@yandex.ru wrote:
Hi Experts,
I am not a strong person on encryption, but it is evident for me that
“TLS Encrypted Hello”
https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-22 has no
value in fighting censorship.
Whatever DNS name would be used
Very happy to see it.
I'm for workgroup adoption of it.
On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote:
We have posted a -00.
https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00
On Wed, Oct 23, 2024 at 7:29 PM Bas Westerbaan wrote:
Hi all,
Unless I overlook
> Very happy to see it.
>
>I'm for workgroup adoption of it.
+1
From: Alicja Kario
Date: Friday, 15 November 2024 at 15:34
To: Bas Westerbaan
Cc:
Subject: [TLS] Re: ML-DSA in TLS
Very happy to see it.
I'm for workgroup adoption of it.
On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan
Indeed. This one should progress quickly.
Russ
> On Nov 15, 2024, at 9:33 AM, Alicja Kario wrote:
>
> Very happy to see it.
>
> I'm for workgroup adoption of it.
>
> On Friday, 15 November 2024 11:51:31 CET, Bas Westerbaan wrote:
>> We have posted a -00.
>>
>> https://datatracker.ietf.org/d
I support adoption.
I agree with the comments John and Rebecca made, should be easy edits to make
after the -00 is submitted.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
On Fri, Nov 15, 2024 at 8:45 AM Stephen Farrell
wrote:
>
>
>
> On 15/11/2024 10:51, Bas Westerbaan wrote:
> > We have posted a -00.
> >
> > https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00
>
> I'm unenthusiastic but don't strongly oppose adoption of this and
> similar drafts, mo
Hey Ed,
On 11/16/24 1:08 AM, evasi...@yandex.ru wrote:
Actually, it is not a problem for them, not at all.
As I stated in the message that you did not copy in the quote: they would
filter out any Hello that has nested InnerHello.
It is pretty automatic solution. As soon as implemented on DPI, t
Because there are other drafts for the other ideas.
Standardizing how to do ML-DSA in TLS in no way “favors” it or otherwise
indicates any sort of exclusivity. There is nothing in the draft that precludes
other approaches.
-Tim
From: Andrey Jivsov
Sent: Friday, November 15, 2024 12:
Agree with Rebecca's comments on ML-DSA and HashML-DSA. After discussing ML-DSA
a lot with developers, I have noticed that after being used with RSA and ECDSA
where they needed to combine RSA and ECDSA with a hash function, they have a
hard time to understand that ML-DSA does not need an additio
On 15/11/2024 10:51, Bas Westerbaan wrote:
We have posted a -00.
https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00
I'm unenthusiastic but don't strongly oppose adoption of this and
similar drafts, mostly because I think we should try get some WG
consensus on guidance for wh
Hiya,
On 15/11/2024 17:12, John Mattsson wrote:
WebPKI might want to wait but the many infrastructure use cases of
TLS, DTLS, and QUIC need to migrate very soon. US government new
requirement is that pure RSASSA, ECDSA, and EdDSA are forbidden from
after 2035. European countries have similar re
ZjQcmQRYFpfptBannerEnd
I happen to think that standalone ML-DSA in TLS is a controversial issue.
And I respectfully disagree. As been pointed out already, you cannot
authenticate tomorrow on somebody else yesterday’s connection.
In practice, PQ authentication is not an immediate issue in
Reviewer: Susan Hares
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more i
Hi all,
The updated draft
https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/,
incorporates feedback received from the WG. It outlines how ML-DSA in
combination with traditional algorithms can be utilized for authentication
in TLS 1.3.
Further, comments and suggestions are welcome.
On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd wrote:
> ...
> Why not hash based signatures?
>
I think that the stateful ones are perfectly suited for certifications in
X.509 certs, but in the TLS handshake this has to be Sphincs+, at 16.2KB
per signature at the AES-192 security level. In addition
On Fri, 15 Nov 2024 at 23:10, Andrey Jivsov wrote:
> I am curious why this draft exclusively proposes ML-DSA, instead of
> adopting a composite signature approach as outlined in
> draft-ounsworth-pq-composite-sigs, at least as an option. For instance,
> id-MLDSA87-ECDSA-P384-SHA512 defined in the
Hybrids are mandatory for protocols like IKEv2 over UDP to handle
fragmentation (traditional key exchange followed by a PQ KEM), see
https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/.
-Tiru
On Sat, 16 Nov 2024 at 11:43, Watson Ladd wrote:
>
>
> On Fri, Nov 15, 2024, 8:52 PM Andrey
On Fri, Nov 15, 2024, 8:52 PM Andrey Jivsov wrote:
> On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd wrote:
>
>> ...
>> Why not hash based signatures?
>>
>
> I think that the stateful ones are perfectly suited for certifications in
> X.509 certs, but in the TLS handshake this has to be Sphincs+, at
Hi all,
The updated draft https://datatracker.ietf.org/doc/draft-reddy-tls-slhdsa/,
incorporates feedback received from the WG. It specifies how the PQC
signature scheme SLH-DSA can be used for authentication in TLS 1.3.
Further, comments and suggestions are welcome.
Best Regards,
-Tiru
---
On Sat, 16 Nov 2024 at 10:23, Andrey Jivsov wrote:
> On Fri, Nov 15, 2024 at 3:56 PM Watson Ladd wrote:
>
>> ...
>> Why not hash based signatures?
>>
>
> I think that the stateful ones are perfectly suited for certifications in
> X.509 certs, but in the TLS handshake this has to be Sphincs+, at
42 matches
Mail list logo
