Hi All,
Thanks for the feedback. Just to clarify a few points, yes this would
be intended as a last resort solution. We think the negative impact on
interactive clients (and in particular, browsers) can be mitigated in
large part by asking user permission before spending compute. That
would probab
On 05.12.24 11:03, Ben Smyth wrote:
If they aren't in the model, then analysis is only good up to KeyUpdate.
Sure, I completely agree. We have no guarantees on what is not in the
formal model. More precisely, I would like the FATT to comment on the
following:
Since issues have already been
On Thu, Dec 05, 2024 at 02:32:21PM -0800, Watson Ladd wrote:
> On Thu, Dec 5, 2024 at 7:31 AM Viktor Dukhovni wrote:
> >
> > On Sat, Nov 02, 2024 at 07:12:02AM +, John Mattsson wrote:
> >
> > > Eric Rescorla wrote:
> > > >Is reuse of ML-KEM keys worse in some way than the reuse of ECDHE keys?
I second D.J. Bernstein's concerns, but my other issue with giving options
like this is that they will creep up into MTI sets or default sets, with
higher priority than hybrids.
I find it less ideal that the document on pure ML-KEM (or signature) and
hybrids are disassociated, causing the progress
Well, I am on the same page that ‘pure ML-KEM’ should be one option. While I
would agree with you that hybrid makes sense (and should be another option), I
am not as inclined as some people to say “and that is so clearly the right
trade-off that we should forbid any other option”. There are pe
> Which one? Yours or Panos et al? :)
I don’t care – we just need something reasonable, and those both qualify…
From: Salz, Rich
Sent: Friday, December 6, 2024 5:58 PM
To: Scott Fluhrer (sfluhrer) ; Andrey Jivsov
; TLS@ietf.org
Subject: Re: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
As
>> If you object to the adoption of this document please respond to this
>> thread by December, 9 2024.
>Based on this, I would have expected only those objecting to respond.
Yes, it is often the case that "if you object please post" is the construction
used in the email. The IETF community ge
> Hence, Cisco will implement it; I am essentially just asking for code
points.
Code points have been allocated:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
https://www.ietf.org/archive/id/draft-connolly-tls-mlkem-key-agreement-05.html#name-iana-consid
On Fri, 6 Dec 2024, 10:06 Muhammad Usama Sardar, <
muhammad_usama.sar...@tu-dresden.de> wrote:
> On 05.12.24 11:03, Ben Smyth wrote:
>
> If they aren't in the model, then analysis is only good up to KeyUpdate.
>
> Sure, I completely agree. We have no guarantees on what is not in the
> formal model
[1] https://datatracker.ietf.org/doc/draft-ietf-uta-require-tls13/
Thanks for pointer to this. It looks like a more detailed version of
tls12-frozen draft. Is there a good reason not to merge the two documents? Is
it due to different WGs? or different intended status? or something else?
It wa
Scott Fluhrer (sfluhrer) writes:
> I understand that people want to discuss the hybrid KEM draft more
> (because there are more options there) - can we at least get the less
> controversial part done?
See https://blog.cr.yp.to/20240102-hybrid.html. Using just PQ, rather
than ECC+PQ, would incur se
A few quick questions. Sorry if I am missing something obvious or some
background.
On 04.12.24 08:04, Valery Smyslov wrote:
note, that UTA WG has issued a WGLC for draft-ietf-uta-require-tls13-02 (New
Protocols Must Require TLS 1.3) [1].
[1]https://datatracker.ietf.org/doc/draft-ietf-uta-re
I'm adding an RFC 9680 coauthor to the To line to request IETF LLC
attention to the antitrust issues here.
Scott Fluhrer (sfluhrer) writes:
> There are people whose cryptographic expertise I cannot doubt who say
> that pure ML-KEM is the right trade-off for them
Please note that antitrust law for
For Ericsson, we are planning to use X25519MLKEM768 as soon as possible and
make that the default choice. We would like X25519MLKEM768 published as an RFC,
be RECOMMENDED=Y, and MTI asap. This is already the de facto standard. All
standalone ECC (secp256r1, secp384r1, x25519, x448) should soon b
14 matches
Mail list logo
