[TLS] Re: [EXT] Re: Second WG Adoption Call for Use of SLH-DSA in TLS 1.3

I’m with David Benjamin on this. —Regards,UriSecure Resilient Systems and TechnologiesMIT Lincoln LaboratoryOn Jul 16, 2025, at 11:33, David Benjamin wrote: I would add that there is a cost to unnecessary variability in this space. Whether or not SLH-DSA is appropriate for 3GPP (I'm

[TLS] Re: [External⚠️] Re: [EXT] Re: [EXTERNAL] Re: Dual certificates in TLS proposal

And you want a composite signature in TLS - why?—Regards,UriSecure Resilient Systems and TechnologiesMIT Lincoln LaboratoryOn Jun 18, 2025, at 19:48, Yaroslav Rosomakho wrote: On Thu, Jun 19, 2025 at 1: 33 AM Watson Ladd wrote: On Wed, Jun 18, 2025, 4: 30 PM Yaroslav Rosomakho wrot

[TLS] Re: [EXT] Re: [EXTERNAL] Re: Dual certificates in TLS proposal

Agree with Watson here. Don’t see a use case, or a threat - within TLS context - that this would help with. — Regards, Uri Secure Resilient Systems and Technologies MIT Lincoln Laboratory > On Jun 18, 2025, at 18:41, Watson Ladd wrote: > > !---

[TLS] Re: ML-KEM recommended column

I think this PR should mention risks introduced by hybrid solutions as well – which (obviously) differ from those introduced by non-hybrid. -- V/R, Uri From: Bellebaum, Thomas Date: Friday, June 6, 2025 at 06:15 To: tls@ietf.org Subject: [EXT] [TLS] ML-KEM recommended column Hello toge

[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

> An interesting point here. For the current approach – indeed, ephemeral KEX does not need PKI. > > However, consider AuthKEM proposal, and KEMTLS – while ephemeral keys > certainly won’t depend on PKI, the static ones will. But you can't have the AuthKEM keys going all the way up the PKI, but

[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

> There’s maintenance of the code for both parts of the KEM and ensuring > they’re properly integrated, maintenance of parallel PKI structures, need > to allocate the costs for two moves [1] instead of one which already makes > some users argue (which can be a royal pain in a large deployment), li

[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

I consider risks associated with hybrids, so my deployment will not use them. Care to share? Perhaps you know something that many others don’t. I know that (purely) cryptographically “as strong or stronger” is not the end. Which many others don’t seem to take into account, or even care about.

[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

t; On Apr 17, 2025, at 13:58, Blumenthal, Uri - 0553 - MITLL > wrote: > > “Needlessly” - well, I guess in getting tired and irritated by the incessant > attempts of a cheat minority to override the choice the overwhelming majority > (which is what I call 75%-25% split) made.

[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

the other way around). — Regards, Uri Secure Resilient Systems and Technologies MIT Lincoln Laboratory > On Apr 17, 2025, at 13:35, Stephen Farrell wrote: > >  > >> On 17/04/2025 18:23, Blumenthal, Uri - 0553 - MITLL wrote: >> Don’t try to stuff your perception of ri

[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

However, the approach of pure PQ carries risks. You consider pure-PQ risks – then don’t use it. I consider risks associated with hybrids, so my deployment will not use them. To each his own. Don’t try to stuff your perception of risks and correctness into everybody else’s throat. smi

[TLS] Re: [EXT] Re: I-D Action: draft-ietf-tls-mlkem-00.txt

> Sure. On the same note – how do we know that there will be no new research findings about ECC? (Besides the fact that once CRQC is built, it becomes useless.) Not useless. It would still be a good anti-ddos / cookies technique until each phone is a CRQC. The truth is probably somewhere in

[TLS] Re: [EXT] Re: I-D Action: draft-ietf-tls-mlkem-00.txt

Will the authors consider a section 6.4 on risks involved with lattice-based structures ? I like what Simon Josefsson used in one of his drafts: "new research findings may be published at any time that may warrant implementation reconsiderations". Sure. On the same note – how do we know that the

[TLS] Re: [EXT] Re: WG Adoption Call for Use of ML-DSA in TLS 1.3

I support the adoption. Might be able to review it. -- V/R, Uri From: tirumal reddy Date: Wednesday, April 16, 2025 at 04:22 To: Sean Turner Cc: TLS List Subject: [EXT] [TLS] Re: WG Adoption Call for Use of ML-DSA in TLS 1.3 I support adoption and I will review it. -Tiru On Tue, 15 Apr

[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

>> “Consensus” is not about reaching no dissenters. > > Consensus doesn't require unanimity, but it does require fairly > considering and trying to resolve each objection---which is exactly what > the list records show didn't happen here. I, for one, considered (I daresay) fairly your objections,

[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

Combining posts from two people into one answer. On 16/04/2025 00:02, Benjamin Kaduk wrote: > > I can see a case being made that this draft does improve the deployability of > TLS if we start with a baseline of draft-ietf-tls-ecdhe-mlkem and note that > that mechanism is not deployable in some

[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

Sean Turner writes: > Hi! It looks like we have consensus to adopt this draft as a working > group item. Um, what? There were several people (including me) raising objections on list to basic flaws in this draft “Consensus” is not about reaching no dissenters. It’s about the “prevailing” opini

[TLS] Re: [EXT] Re: Boring cryptography, and the opposite extreme

Thank you, Bas! And to save time for those who don’t want to follow the NIST mailing list trail – here’s the response from Leo Ducas posted there: Dear All, Thank you, Kevin, Charles, Yixin, Jean-Pierre for your careful analysis and report. While most of the points below are acknowledged in

[TLS] Re: [EXT] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

I support adoption of this draft and am happy to review. I support adoption. Might be able to review. -Original Message- From: Sean Turner Sent: 01 April 2025 13:58 To: TLS List Subject: [TLS] WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3 We are continuing

[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

> I believe that adopting the draft will allow those who > wish to use pure PQC (for whatever reasons they may > have) to do so while at the same time not in any way > impacting anybody else who doesn't want to do that. Those who wish to use pure PQC do not need permission. This is about IETF

[TLS] Re: The TLS WG has placed draft-connolly-tls-mlkem-key-agreement in state "Call For Adoption By WG Issued"

I support adoption. I agree with John that reuse of ephemeral keys is a far bigger security problem, in theory and even more so in practice. Coincidentally, I disagree with Stephen – there’s no need to encourage or discourage either hybrids or pure KEMs. -- V/R, Uri From: John Mattsson Date:

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

MLKEM1024 is the CNSA 2.0 approved key exchange https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html Yes. secp384r1 is the CNSA 1.0 approved key exchange https://www.rfc-editor.org/rfc/rfc9151.html

[TLS] Re: [EXT] Re: PQ Cipher Suite I-Ds: adopt or not?

I agree that ecdhe-mlkem should advance now. At the same time, “pure” mlkem should advance - because there’s no way the main “contentious point” of “hybrid vs pure” would be resolved. —Regards,UriSecure Resilient Systems and TechnologiesMIT Lincoln LaboratoryOn Dec 23, 2024, at 16:29, Rob Sayre wr

[TLS] Re: [EXT] PQ Cipher Suite I-Ds: adopt or not?

There are a number of Individual I-Ds that specify PQ cipher suite for TLS currently being developed that specify either “pure” PQ or composite/hybrid: ML-KEM Post-Quantum Key Agreement for TLS 1.3; see https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

D. J. Bernstein wrote: > More recently, NSA's Dickie George is on video claiming that NSA generated > the Dual EC points randomly and that Dual EC is secure. Do you have a link to the video? Such a comment is surprising as it is a very bad PR strategy. “No comment” is a far better strategy.

[TLS] Re: [EXT] Re: Fwd: New Version Notification for draft-farrell-tls-pqg-00.txt

I’m with Ekr on this – his points are right on. And disagree with Stephen – Eric explained why clearly enough. On Sun, Dec 15, 2024 at 12:13 PM Stephen Farrell mailto:stephen.farr...@cs.tcd.ie>> wrote: Hiya, Answering a few points at once: On 15/12/2024 17:05, Eric Rescorla wrote: > I don'

[TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement

I think we ought to consider it our duty to develop guidance for those deploying e.g. TLS now that we're adding a plethora of new ciphersuites, some useful, some way less so, and some possibly even risky. So, you want a consensus in guidance? What to recommend for what use case? > Thus

[TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement

To: Blumenthal, Uri - 0553 - MITLL Cc: tls@ietf.org Subject: [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement Hiya, On 15/12/2024 02:33, Blumenthal, Uri - 0553 - MITLL wrote: > Stephen, I don’t think attempting to develop consensus in this case > would be either useful or productive.

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

D. J. Bernstein wrote: > More recently, NSA's Dickie George is on video claiming that NSA generated > the Dual EC points randomly and that Dual EC is secure. Do you have a link to the video? Such a comment is surprising as it is a very bad PR strategy. “No comment” is a far better strategy. T

[TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement

14, 2024, at 19:29, Stephen Farrell wrote: >  > Hiya, > > On 15/12/2024 00:07, Blumenthal, Uri - 0553 - MITLL wrote: >> Those who agree with BSI – let them use Hybrid KEM, as they have their >> reasons. >> Those who agree with NSA – let them use pure ML-KE

[TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement

. . . however forceful, or insistent on being heard, Dan may be at times, history has shown that he is often enough ultimately proved right, years or decades later. An arguable point. However "inconvenient", IMHO his voice should not be suppressed. Of course. However, there must be a limit

[TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-agreement

+1 for adoption While I'm stronly against wide deployment of pure ML-KEM at this moment in time, I'm very much in favour of adoption of this document, having stable definitions for such codepoints, even if they will get doployed only in closed networks is still useful. +1 for adoption. And I am

[TLS] Re: [EXT] Re: ML-DSA in TLS

> To clarify, are you continuing to claim that there's "no damage possible > (at least, in the TLS context) caused by PQ DSA break", despite the > facts that (1) upgrades often take a long time and (2) attackers aren't > going to announce their secret attacks? For (1) I call it not an “upgrade” (

[TLS] Re: [EXT] Re: ML-DSA in TLS

> To clarify, are you continuing to claim that there's "no damage possible > (at least, in the TLS context) caused by PQ DSA break", despite the > facts that (1) upgrades often take a long time and (2) attackers aren't > going to announce their secret attacks? For (1) I call it not an “upgrade”

[TLS] Re: [EXT] Re: ML-DSA in TLS

> [ regarding encryption vs. signatures: ] >> There’s no damage possible (at least, in the TLS context) caused by PQ >> DSA break > > Not true. I already explained what's wrong with this argument: > https://mailarchive.ietf.org/arch/msg/tls/77uUYhGJYNVQIp9heMY9bkbKbaA/ >

[TLS] Re: [EXT] Re: ML-DSA in TLS

>> Where do you draw the line? > > Simple: require hybrids. Any upgrade from pre-quantum crypto to > post-quantum crypto is obliged to keep the pre-quantum crypto and to > use the post-quantum crypto as an extra layer of defense, rather than > removing the pre-quantum crypto. Why do you draw the

[TLS] Re: [EXT] Re: ML-DSA in TLS

Are you saying that you're now in favor of hybrids for encryption but not for signatures? What's the relevant difference? No, I’m still for non-hybrid PQ KEM and signatures. But I recognize (though disagreeing with) the arguments of those who want hybrid KEMs. I do not buy the arguments for hyb

[TLS] Re: [EXT] Re: ML-DSA in TLS

Scott Fluhrer (sfluhrer) writes: > My real question is "why is there such push-back from such a small change?" For the same reason there would have been pushback if the KEM rollouts had done PQ instead of ECC+PQ: that would have been reckless from a security perspective. Given how the two (KEM a

[TLS] Re: [EXT] Re: ML-DSA in TLS

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

[TLS] Re: [EXT] Re: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Respectfully disagree with Alicja. There is no need to steer people towards hybrids. For example, we don’t need hybrids (based on our understanding of cryptography/math and the quality of our crystal balls ;) and don’t intend to employ them. Others may prefer hybrids, and it’s fine with me. ;-

[TLS] Re: [EXT] Re: New Version Notification for draft-tls-reddy-slhdsa-00.txt

>> not recommended for use in signature_algorithms > > People deploying TLS can do the performance measurements for themselves > and decide whether high confidence in security is affordable for their > applications. Shouldn't speed be given lower weight than security in > decisions of what to rec

[TLS] Re: [EXT] [Pqc] Re: Planned changes to Cloudflare's post-quantum deployment

I second the request to add support for secp384r1mlkem1024, as that’s the only hybrid KEX that makes sense for us. Thank you! -- V/R, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex there are n

[TLS] Re: [EXT] Re: draft-kwiatkowski-tls-ecdhe-mlkem and P-384

As far as I’m concerned – no need: P384 (or no ECC at all, aka – no hybrid) would suffice. TNX -- V/R, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies.

[TLS] Re: [EXT] Re: draft-kwiatkowski-tls-ecdhe-mlkem and P-384

If we do hybrid at all - it makes perfect sense then to specify ECDHE over P-384 and ML-KEM-1024. Thx—Regards,UriSecure Resilient Systems and TechnologiesMIT Lincoln LaboratoryOn Sep 8, 2024, at 20:06, kris wrote: Hello, I'm sorry, possibly I've missed some emails. If there is an interest I prop

[TLS]Re: [EXT] Re: Is NIST actually prohibiting X25519?

NIST cannot prohibit a curve, or an algorithm. But they may not approve it – and for customers that require approved technology and algorithms, it would prevent them from using anything that’s not explicitly approved. -- V/R, Uri There are two ways to design a system. One is to make it so simpl

[TLS]Re: [EXTERNAL] Re: Curve-popularity data?

CNSA 1.0 requires P-384 or RSA-3072, and does not allow P-256. CNSA 2.0 requires ML-KEM, and does not approve any of the ECC curves. But there’s a “transition period”, during which P-384 could presumably be used. -- V/R, Uri From: Scott Fluhrer (sfluhrer) Date: Wednesday, June 5, 2024 at

Re: [TLS] [EXT] Re: Deprecating Static DH certificates in the obsolete key exchange document

I see two possibilities: 1. Nobody in the real world employs static DH anymore – in which case this draft is useless/pointless; or 2. On private networks people employ static DH to implicitly authenticate their peers (a-lá MQV) – in which case this draft is harmful. Overall, I’m amazed b

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

I support Kris, and would like to see codepoints added for MLKEM-512, MLKEM-768, and MLKEM-1024. -- V/R, Uri On 3/19/24, 00:11, "TLS on behalf of Kris Kwiatkowski" mailto:tls-boun...@ietf.org> on behalf of k...@amongbytes.com > wrote: !--

Re: [TLS] [EXT] Re: Time to first byte vs time to last byte

Please, let us not assume every website is behind a CDN. Isn't that assumption reasonable? At least for global websites --- without CDN performance sucks. Of course it isn’t. As a reference point: Consider reading the New York Times in Canberra, Well, if you have nothing better to d

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

Also, what are the WG's thoughts on including standalone PQC signatures in the same draft? I think that including standalone PQC sigs would be very desirable. I don't think there is any particular reason to include PQC signatures in the same draft as PQ key establishment. In TLS 1.3, key

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

Also, what are the WG's thoughts on including standalone PQC signatures in the same draft? I think that including standalone PQC sigs would be very desirable. From: TLS On Behalf Of Deirdre Connolly Sent: Tuesday, March 5, 2024 9:15 PM To: TLS@ietf.org Subject: [TLS] ML-KEM key agreeme

Re: [TLS] [EXT] Re: Time to first byte vs time to last byte

On Sat, 9 Mar 2024 at 10:23, Bas Westerbaan wrote: Given that especially for the web, CDNs used much higher initcwnds, Please, let us not assume every website is behind a CDN. Isn't that assumption reasonable? At least for global websites --- without CDN performance sucks. Of co

Re: [TLS] [EXT] Re: ML-KEM key agreement for TLS 1.3

I would like to see Deirdre’s request satisfied, and a full number assigned. Regards, Uri > On Mar 7, 2024, at 09:19, Salz, Rich > wrote: > >  > This Message Is From an External Sender > This message came from outside the Laboratory. > Back to the topic at hand. I think it'd very bad if we'd

Re: [TLS] [EXT] Re: [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

-- V/R, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies.

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

>On Wed, Jan 3, 2024, at 15:30, Eric Rescorla wrote: >> In the interest of clarity, I favor the WG declining to work on >> extending TLS 1.2, so these cipher suites should be marked as >> Recommended=No. I'm just concerned that closing the registries entirely >> will not have the best results. >

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

This draft will likely be ignored, except by the Web browser crowd, Swift UI, and such ilk. One problem with this draft is that such “fanatical/extremist” documents diminish credibility of the body that sanctioned them in the eyes of those who deal with “real” equipment (again, excluding st

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

important that we get it right … And I don’t think we did. TNX From: TLS On Behalf Of Salz, Rich Sent: Tuesday, January 2, 2024 10:06 AM To: Blumenthal, Uri - 0553 - MITLL Cc: TLS@ietf.org Subject: Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze' My starting

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

>jQcmQRYFpfptBannerEnd >>  Those who can move to 1.3+, will do so, regardless of this draft. Those who >>can’t, would >>  do whatever’s appropriate in their case – again, regardless of this draft. > > Same as for any other IETF document. :) :-) Yes, but not quite – as other IETF docum

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

>>  I'm not Martin, but I believe that his point is that both TLS ciphersuites >>and TLS supported groups/EC curves >>  permit registration outside of the IETF process based on the existence of.a >> specification. As long as PQC can >>  fit into new ciphersuites and group types, then anyone can

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

-1 to Tim. You can tell the reader whatever you want. The fact remains that if the only way to add QR to the currently deployed TLS-1.2-based “stuff” is modifying TLS-1.2, then that’s what will be done in that particular case.   I hope that the majority of the installed base would be abl

Re: [TLS] [EXT] Re: What is the TLS WG plan for quantum-resistant algorithms?

Do we want rfc describing the final NIST standards? And for which? I'm ok with that — in this order of priority: ml-kem, ml-dsa, slh-dsa. Probably yes, and in the order you described. For which algorithms do we want to assign codepoints once the NIST standards are out? Codepoints are cheap

Re: [TLS] [EXT] Re: WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

the Laboratory. > |---! > > Blumenthal, Uri - 0553 - MITLL writes: > >> I’m aware of at least one company (using the term loosely) that uses custom >> group, > > How does that work with TLS 1.3? > > Pete

Re: [TLS] [EXT] Re: WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

Hubert, I’m aware of at least one company (using the term loosely) that uses custom group, and probably understands FFDH(E) better than you or me. Since they had their reasons for choosing custom, “can change … to use well-known groups” (obviously) does not apply. Regards, Uri > On Jul 14, 2

Re: [TLS] [EXT] Re: WG Last Call for draft-ietf-tls-deprecate-obsolete-kex

Yes to Viktor's and Peter's comments. I can't understand fanaticism expressed in this "deprecate..." attempt. Besides, it is simply unwise. -- V/R, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex

Re: [TLS] [EXT] AuthKEM: Splitting the draft and next steps

In short - yes please. Thanks! Regards, Uri > On Jul 4, 2023, at 02:01, Thom Wiggers wrote: > >  > This Message Is From an External Sender > This message came from outside the Laboratory. > Hi all, > > It has been a while since I have had time to work on the IETF draft for > AuthKEM (``dra

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

n, Apr 02, 2023 at 02:54:57AM +, Blumenthal, Uri - 0553 - MITLL > wrote: >> CNSA-1.0 allows ECC only over P-384, unlike it’s predecessor Suite B >> that also permitted P-256. P-521 is not included either. See >> https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/C

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

CNSA-1.0 allows ECC only over P-384, unlike it’s predecessor Suite B that also permitted P-256. P-521 is not included either. See https://media.defense.gov/2021/Sep/27/2002862527/-1/-1/0/CNSS%20WORKSHEET.PDF (page 1). CNSA-2.0 allows only Kyber-1024. Not -768. See https://media.defense.gov/20

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

size to the keyshare. like secp384r1_kyber768 combines two equivalent > security levels. > Those that want to be extra conservative can go secp521r1_kyber1024 which > won’t be much worse than secp384r1_kyber1024 in performance or size. > > > > From: TLS On Behalf Of Blumenthal, Ur

Re: [TLS] Consensus call on codepoint strategy for draft-ietf-tls-hybrid-design

Can we add secp256r1_kyber768 option for those who prefer NIST curves? I support this. I would also like secp384r1_kyber1024 option, please. Thanks On 29 Mar 2023, at 10:48, Christopher Wood wrote: As discussed during yesterday's meeting, we would like to assess consensus for

Re: [TLS] Resurrect AuthKEM?

Richard, yes, you git it right. From: Richard Barnes Date: Tuesday, March 21, 2023 at 4:32 PM To: Blumenthal, Uri - 0553 - MITLL Cc: tls@ietf.org Subject: Re: [TLS] Resurrect AuthKEM? Hi Uri, Just to be clear, the AuthKEM draft you mean is this one? https://datatracker.ietf.org/doc/draft

[TLS] Resurrect AuthKEM?

I’m surprised to see that there isn’t much (isn’t any?) discussion of the AuthKEM draft. It seems pretty obvious that with the advent of PQ algorithms, the sheer sizes of signatures and public keys would make {cDm}TLS existing authentication and key exchange impractical in bandwidth-constra

Re: [TLS] [Pqc] Did TLS AuthKEM die?

e need to communicate and select] options. From: Blumenthal, Uri - 0553 - MITLL Date: Friday, 27 January 2023 at 16:09 To: loic.ferre...@orange.com , Thom Wiggers Cc: John Mattsson , Mike Ounsworth , p...@ietf.org , tls@ietf.org Subject: Re: [Pqc] [TLS] Did TLS AuthKEM die? Thank you Ur

Re: [TLS] [Pqc] Did TLS AuthKEM die?

Restricted De : Blumenthal, Uri - 0553 - MITLL Envoyé : jeudi 26 janvier 2023 21:08 À : FERREIRA Loïc INNOV/IT-S ; Thom Wiggers Cc : John Mattsson ; Mike Ounsworth ; p...@ietf.org; tls@ietf.org Objet : Re: [Pqc] [TLS] Did TLS AuthKEM die? How would you compare CAKE-HI and cTLS? Loïc

Re: [TLS] about hash and post-quantum ciphers

John, I agree with all of your points. TNX P.S. Maybe it would be good for NIST to standardize BLAKE3. But until it does – … -- V/R, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex there

Re: [TLS] [Pqc] Did TLS AuthKEM die?

get there. ;-) I realize the above is rather sketchy – please feel free to ask more questions, and I’ll do my best to answer them. Thanks! Orange Restricted De : Pqc De la part de Blumenthal, Uri - 0553 - MITLL Envoyé : mercredi 25 janvier 2023 22:49 À : Thom Wiggers Cc : John

Re: [TLS] [Pqc] Did TLS AuthKEM die?

I'll first ask the first question, and then try to clarify a few of the other things raised in this thread. > Is AuthKEM dead? I'd say it's hibernating. The draft has indeed expired: there was nothing significant to add since the last time we edited/updated it. I also couldn't make it to

Re: [TLS] Did TLS AuthKEM die?

makes a lot more sense than ECDH KEM. Yes, absolutely. From: TLS on behalf of Blumenthal, Uri - 0553 - MITLL Date: Tuesday, 24 January 2023 at 19:15 To: Mike Ounsworth , p...@ietf.org , tls@ietf.org Subject: Re: [TLS] Did TLS AuthKEM die? I truly hope AuthKEM is alive. -- V/R

Re: [TLS] Did TLS AuthKEM die?

I truly hope AuthKEM is alive. -- V/R, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies.

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

100% support the BCP route. -- V/R, Uri On 12/22/22, 10:16, "TLS on behalf of Peter Gutmann" wrote: Hal Murray writes: >Would a BCP be a better approach? That might provide a good setting to >discuss the issues. There is no reason to limit a BCP to TLSv1.2 or FFDHE. Tha

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

PM Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> wrote:\ I think I’ve made my point already – there are devices that use FFDHE, which remain secure (so far), and may require access by new . Thus, an RFC that would prohibit it, sounds, as you said yourself, premature.Deprecated does no

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

thanks, Rob On Tue, Dec 13, 2022 at 3:01 PM Blumenthal, Uri - 0553 - MITLL wrote: That sounds like deprecation to me (stop building new things this way...) Build new things that stop interoperating with old things? Does not sound smart to me. Not to mention that the

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

IETF should not perpetually support systems that can't be upgraded. Yeah, who cares for systems like SCADA. Sure. On Tue, Dec 13, 2022 at 7:51 AM Blumenthal, Uri - 0553 - MITLL wrote: I do not support deprecation, because there will be deployed devices (IoT, SCADA) that a

Re: [TLS] consensus call: deprecate all FFDHE cipher suites

I do not support deprecation, because there will be deployed devices (IoT, SCADA) that aren’t upgradable – and the new stuff will have to access them. I’ll spare the group my personal opinion about this draft. -- V/R, Uri From: TLS on behalf of Ira McDonald Date: Tuesday, Decembe

Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert?

Victor, actually, I take it back - you may be right in that last point. Need to think. Regards, Uri > On Oct 7, 2022, at 14:59, Blumenthal, Uri - 0553 - MITLL > wrote: > >  >>> On Oct 7, 2022, at 14:42, Viktor Dukhovni wrote: >>> >>> On Fri, Oct 0

Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert?

> On Oct 7, 2022, at 14:42, Viktor Dukhovni wrote: > > On Fri, Oct 07, 2022 at 06:19:15PM +, Blumenthal, Uri - 0553 - MITLL > wrote: > >> Then publish the certificate. Then the victim is unable to read email >> encrypted to her. A DoS that costs the attacker

Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert?

> >You can replay the CSR and get the certificate request by the original party > >signed by whatever CA you want, but would that do you any good if you don't > >have the private key? > > That's exactly the point, which others have also made in the thread. Yes, > you > can do this, but then

Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert?

Peter, "Compromised" in the context must necessarily mean "someone stole the key", because if someone "broke the crypto" - then none of the certs issued by that CA is worth the weight of electrons that carried it. Oh, and could you please be a little more constructive? -- V/R, Uri On 10/7/2

Re: [TLS] [lamps] [EXTERNAL] Re: Q: Creating CSR for encryption-only cert?

It largely isn’t necessary. I like proof of possession for issuance, but mostly just to avoid nuisances. But this topic is widely misunderstood. I think if you took a poll of PKI professionals, you’d find that lots of them erroneously believe that issuance of a certificate certifies that the

[TLS] Q: Creating CSR for encryption-only cert?

TL;DR Need to create a CSR for a key pair whose algorithm does not allow signing (either because it’s something like Kyber, or because restriction enforced by HSM). How to do it? Longer version: There are several use cases that require certifying long-term asymmetric keys that are only capable

Re: [TLS] OCSP and browsers

Now we have ACME, why not move to 3-day certs issued daily and avoid the need for revocation entirely? For your use case – perhaps. For my – no way. On Fri, Sep 16, 2022 at 11:43 AM Salz, Rich wrote: I think this is of general interest, so I’m posting here rather than poking friends

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

+1 on the 3 proposed by Scott and P256+Kyber512 proposed by Kris. “Me too”: +1 to the above. From: TLS On Behalf Of Kris Kwiatkowski Sent: Wednesday, August 17, 2022 3:31 PM To: tls@ietf.org I support those choices, but would also add P256+Kyber512. * (1) same reason as below (by Scott) *

Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

Why both X25519+Kyber512 and P256+Kyber512? Because there are good HW implementations supporting P256, and (at least for some people) it’s good enough? smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https:/

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

Robert, I can’t agree more. Except: Structured Lattices indeed have been around not as long as, e.g., RSA or ECC - but for how long have RSA or ECC have been around Bauer they were included in cryptographic protocols? Without Hybrid? Thanks! Regards, Uri > On Aug 9, 2022, at 16:58, Robert R

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

> > I thought a Quantum Annoyance was someone who keeps banging on about > > imaginary > > attacks that don't exist as a means of avoiding having to deal with actual > > attacks that have been happening for years without being addressed. > > That is a little unfair but only a little. I don't thin

Re: [TLS] Before we PQC... Re: PQC key exchange sizes

In yesterday’s working group meeting we had a bit of a discussion of the impact of the sizes of post-quantum key exchange on TLS and related protocols like QUIC. As we neglected to put Kyber’s key sizes in our slide deck (unlike the signature schemes), I thought it would be a good idea to get th

Re: [TLS] PQC key exchange sizes

What are the implications for environments that require NIST Sec Level 3 or 5? Regards, Uri > On Jul 26, 2022, at 11:33, Martin Thomson wrote: > > On Tue, Jul 26, 2022, at 11:21, Stephen Farrell wrote: >> Be interested in how that'd change the CH if ECH is used too. >> I guess the answer might

Re: [TLS] Better TLS Client Authentication

This is not about what was there earlier, nor what has been in wider use so far (in which case, password clearly wins ;). Rather – what is the best (from security and usability point of view) mechanism now. I say – FIDO (or U2F, whatever) is the closest contender, if not the outright winner

Re: [TLS] Better TLS Client Authentication

+1 for FIDO Regards, Uri > On May 24, 2022, at 01:11, Tim Cappalli > wrote: > >  > You mentioned FIDO, but I didn't see a reason why you don't want to use it. > The industry has largely accepted the mature FIDO standards stack (WebAuthn & > CTAP) as the strong authentication method that rep

Re: [TLS] Deprecating Obsolete Key Exchange Methods in TLS

Following the discussions around draft-bartle-tls-deprecate-ffdh and draft-aviram-tls-deprecate-obsolete-kex, and after consulting the chairs, we have merged the two drafts into draft-aviram-tls-deprecate-obsolete-kex. The merged draft prescribes the following: RSA key exchange is a MUST NOT

Re: [TLS] Revised hybrid key exchange draft

I don't see much benefit in the revised construction. -- Regards, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies.

Re: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

while the document is not yet finalized. I think we’re OK as-is. On Wed, 1 Sept 2021 at 23:34, Blumenthal, Uri - 0553 - MITLL wrote: How does the described AOAP attack apply to TLS KDF? -- Regards, Uri There are two ways to design a system. One is to make is so simple

  1   2   3   >