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

Yes. (Draft coauthor here. FWIW, I'm not sure how much bandwidth I'll have to continue moving the draft forward. Regardless, this sounds like a good idea to me.) On Mon, 15 Apr 2024 at 21:14, Joseph Salowey wrote: > At IETF 119 we had discussion that static DH certificates lead to static > key

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

Hi Ilari, thanks for the clarification! I attempted to correct the text. Would you be willing to review the change? It's here: https://github.com/richsalz/tls12-frozen/commit/a1ce7ede97897e291af44f0c2f4fc225a2ca4447 thanks, Nimrod On Tue, 12 Dec 2023 at 19:22, Ilari Liusvaara wrote: > On Fri,

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

> As the co-author, I support this and am willing to continue working on it as needed. Same here. On Wed, 6 Dec 2023 at 14:51, Salz, Rich wrote: > At the TLS meeting at IETF 118 there was significant support for the draft > 'TLS 1.2 is in Feature Freeze' ( > https://datatracker.ietf.org/doc/dra

Re: [TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-03.txt

reflected in the "Updates" header. > > > > cheers, thanks > > t > > > > On Thu, 21 Sept 2023 at 10:22, wrote: > > > > > > Internet-Draft draft-ietf-tls-deprecate-obsolete-kex-03.txt is now > available. > > > It is a work item of the Transport

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

> At the moment the blanket "don't do DH" is in effect saying "use RSA keyex" to a chunk of the market. Does the document in question say in effect "use RSA keyex"? Or could it be read that way? The first sentence is "This document deprecates the use of RSA key exchange and Diffie Hellman". That se

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

> There are no ECDHE or FFDHE cipher suites in TLS 1.3. Cipher suites specify > just the bulk encryption, PRF, and integrity protection mechanism. The key > exchange is fully controlled by . Ah, good point :-) Maybe go with this text instead? In TLS 1.3 connections, clients and servers MAY offer su

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

> My main point is say it once, not repeat it in each section. I think that language was added for fear that readers will only glimpse the document, and somehow conclude that RSA/FFDH is fine with TLS 1.1. (The document is mostly aimed at late adopters of best practices anyway...) So my preference

Re: [TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-02.txt

Internet-Drafts > directories. This Internet-Draft is a work item of the Transport Layer > Security (TLS) WG of the IETF. > >Title : Deprecating Obsolete Key Exchange Methods in TLS 1.2 >Authors : Carrick Bartle > Nimrod Aviram >Fi

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

> Authors, can you please update the document (and fix the clarification that Ekr recently raised) at your convenience? Sure, I'll start working on it. best, Nimrod On Fri, 10 Mar 2023 at 03:35, Christopher Wood wrote: > First, let us apologize for taking so long to conclude this consensus > c

Re: [TLS] Question on draft-ietf-tls-deprecate-obsolete-kex-01.txt

Ah, I understand your question now :-) Sure, the document seems inconsistent/unclear about this at the moment. Once we settle on a decision regarding FFDHE I'll fix this. best, Nimrod On Fri, 3 Mar 2023 at 19:35, Eric Rescorla wrote: > > > On Fri, Mar 3, 2023 at 9:21 AM

[TLS] How are we planning to deprecate TLS 1.2?

Hi Everyone, We’ve recently had a brief side discussion around the issue of letting vendors (or operators) know when something is expected to be deprecated: https://mailarchive.ietf.org/arch/msg/tls/Djk35kp5P5Z1WfmN8_OJj_eYRLo/ Currently, there is no expected deprecation timeline for any specific

Re: [TLS] Question on draft-ietf-tls-deprecate-obsolete-kex-01.txt

Hi Eric and Everyone, draft coauthor here. Appendix C lists "DHE Cipher Suites Refered to by This Document", not ones which are deprecated. The intention of the current text is to permit fully ephemeral DHE over a finite field (FFDHE) with sufficient group size. However, we also have an unresolve

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

> It's also easy and quick to verify that the server *is* behaving correctly and thus is not exploitable. Could you please help me understand how you propose to verify this? For example, assuming an SMTP server that presents a (presumably) custom-generated safe prime. My understanding is that this

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

at a later time, it is reasonable to expect that if a > future revision of a document alters the status of a MUST- > algorithm, it will remain at least a SHOULD or a SHOULD-. > > Russ > > On Dec 16, 2022, at 11:27 AM, Nimrod Aviram > wrote: > >

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

> There needs to be some plan with a schedule that gives downstream users time to get their act in gear. I agree. And the schedule should also allow for deprecation in a reasonable timeline. > Should there be an IETF group to help coordinate things like this? I think it'd be better if each group c

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

Let me clarify that the document also has RSA as a MUST NOT. So there will be no reason to read this document and switch from FFDHE to RSA. On Wed, 14 Dec 2022 at 06:09, Peter Gutmann wrote: > Blumenthal, Uri - 0553 - MITLL writes: > > >I do not support deprecation, because there will be deplo

[TLS] draft-deprecate-obsolete-kex - Comments from WG Meeting

Hi Everyone, Thank you for chiming in with comments and suggestions regarding draft-deprecate-obsolete-kex :-) I've tried to summarize everyone's comments below, hopefully grouped by subject. Apologies in advance if I missed anything (or misspelled names...), please do reply to this thread :-) M

[TLS] draft-ietf-tls-deprecate-obsolete-kex

Hi Everyone, At the upcoming WG meeting, we will give a short update on the status of draft-ietf-tls-deprecate-obsolete-kex ; please find the preliminary slides attached. Our hope is to progress this document to WGLC. Please

Re: [TLS] Working group adoption of draft-aviram-deprecate-obsolete-kex-01

Thanks Joe! > Authors please submit the draft as draft-ietf-tls-deprecate-obsolete-kex-00. Please find the new version here: https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ And the GitHub repo here: https://github.com/nimia/draft-deprecate-obsolete-kex Comments and improve

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

pqscheme; > ref=[[some doc that uses this thing]] from value=5678; > desc=x25519_somepqscheme_v2; ref=[[some doc that uses a newer thing]]. > > David > > On Thu, Apr 28, 2022 at 7:19 AM Nimrod Aviram > wrote: > >> I'd like to reiterate my suggestion: While for now t

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

I'd like to reiterate my suggestion: While for now there is concensus for using concatenation to combine the two shared secrets, we should have a clear upgrade path if we want to use other combination methods in the future. As Douglas notes here [1], the document does commit to concatenation as th

[TLS] Deprecating Obsolete Key Exchange Methods in TLS

Hi Everyone, 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

Re: [TLS] Revised hybrid key exchange draft

r assumption). HKDF has not yet been proven to satisfy this property, under any assumption. best, Nimrod On Mon, 24 Jan 2022 at 18:37, D. J. Bernstein wrote: > Nimrod Aviram writes: > [ regarding the "dual-PRF" security property ] > > Our construction satisfies this prope

Re: [TLS] Revised hybrid key exchange draft

. Bernstein wrote: > Nimrod Aviram writes: > > To summarize, we recommend using our new proposed construction. It’s > fast, > > easy to implement, and provides provable security. > > The baseline construction is faster and is easier to implement, so > you're say

Re: [TLS] Revised hybrid key exchange draft

. > > The nice thing about the hybrid draft is that it isn't a firm commitment > to any particular combination method. Each new key exchange "group" can > define its own combination method. It only suggests a method. So I don't > agree that "[m]issing th

Re: [TLS] Revised hybrid key exchange draft

ry appendix of the past design considerations, and a few > wording changes. > > Last September, Nimrod Aviram, Benjamin Dowling, Ilan Komargodski, Kenny > Paterson, Eyal Ronen, and Eylon Yogev posted a note [2,3] with some > concerns about whether the approach for constructing the hybr

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

iciencies.* > > *The other is to make it so complex there are no obvious deficiencies.* > > * > > - > C. A. R. Hoare* > > > > > > *From: *TLS o

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 < >> u...@ll.mit.edu> wrote: >> >> How does the described AOAP attack apply to TLS K

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

n is better suited to CFRG?) > > Best regards, > > ​​​​​Dan > > > > *From:* TLS *On Behalf Of *Nimrod Aviram > *Sent:* Wednesday, September 1, 2021 3:57 PM > *To:* > *Cc:* Eylon Yogev ; Ilan Komargodski < > ilanko...@gmail.com>; Benjamin Dowling ; Eyal

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

; *The other is to make it so complex there are no obvious deficiencies.* > > * > > - > C. A. R. Hoare* > > > > > > *From: *TLS on behalf of Nimrod Aviram <

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

therefore test a single guess for the starting byte with two sessions, and learn that byte after at most 512 sessions. See [1], [2]. best wishes, Nimrod Aviram, Benjamin Dowling, Ilan Komargodski, Kenny Paterson, Eyal Ronen, Eylon Yogev References: [1] Practical key-recovery attack against APOP, an

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

, for which secure > implementations are known. No detail is provided and that alone should be > sufficient reason to not adopt. > > On 2021-08-27 1:00 p.m., Nimrod Aviram wrote: > > > The implementation guidance to avoid weaknesses in any ephemeral-static > exchange is "do

Re: [TLS] Adoption call for Deprecating FFDH(E) Ciphersuites in TLS

> The implementation guidance to avoid weaknesses in any ephemeral-static exchange is "don't get anything wrong, anything at all Agreed that it's not workable. I'm not sure there is existing and suitable implementation guidance. To avoid the Raccoon attack, one would have to implement the KDF such

Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange Methods in TLS

Looks like we have consensus for the following: - Clients may choose to not support FFDHE, a la Chrome. I don't see consensus for full deprecation of FFDHE, please correct me if I'm wrong. - Clients must not connect when the server uses a group of less than 2048 bits. - Clients may connect when the

[TLS] Deprecating FFDHE + RSA Key Exchange

Dear all, Following the discussion around draft-bartle-tls-deprecate-ffdhe, what are your thoughts on deprecating RSA key exchange, and Finite-Field Diffie-Hellman? (This would probably happen in a separate document.) Considering the following different areas/use cases: 1. On the open Internet/we

Re: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets

Thanks! The PR is here, happy to hear comments and corrections: https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/1 best, Nimrod On Fri, 18 Sep 2020 at 12:04, Nimrod Aviram wrote: > Sounds good to me. > I'm happy to send a PR making these changes, but couldn

Re: [TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets

note > regarding the risks as identified by the Raccoon attack. > > Douglas > > > On Wed, Sep 16, 2020 at 12:27 PM Nimrod Aviram > wrote: > > > > Dear all, > > > > We are writing to ask about the possible security impact of > > variable-length secrets

[TLS] Hybrid key exchange in TLS 1.3 and variable-length secrets

Dear all, We are writing to ask about the possible security impact of variable-length secrets on the "Hybrid key exchange in TLS 1.3" RFC [1]. As you probably know, when using key material of variable length and processing this material using hash functions, a timing side channel may arise. In br

Re: [TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack

munity. Feel free to send a PR > https://github.com/tlswg/tls-subcerts and we can discuss on-list. > > Nick > > On Fri, Mar 20, 2020 at 11:12 AM Nimrod Aviram > wrote: > >> Hi Nick, >> >> Thank you again for the detailed explanation. >> We agree with yo

Re: [TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack

20, 2020 at 9:23 AM Nimrod Aviram > wrote: > >> Hi Nick, >> >> Thank you for the detailed response! >> >> In light of your explanation, we are curious why high-profile servers >> using Delegated Credentials need to support TLS-RSA? Most of the relevant

Re: [TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack

Bleichenbacher attack To: Nimrod Aviram Cc: , Juraj Somorovsky Hello Nimrod, Robert and Juraj, Thank you for the report! The fact that a single signature oracle computation can be used to create a DC and therefore intercept multiple connections for up to 7 days is something we considered when

[TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack

Hi folks, We're writing to ask (and share some concerns) about the potential impact of a Bleichenbacher attack when delegated credentials are in use. This issue is already discussed in the standard: In Section 3: ``` It was noted in [XPROT] that certificates in use by servers that support ou