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

[Nimrod Aviram]

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 exchange which is undesirable.  Although the current draft deprecates
> static DH ciphersuites, it seems that RFC 5246 allows the client to provide
> a certificate with a static DH keypair to provide static parameters in
> (EC)DHE in TLS 1.2 (I don't know of any implementations that do this).
>
> Should the draft deprecate these ClientCertificateTypes and mark the
> entries (rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, ecdsa_fixed_ecdh) as
> 'D' discouraged?
>
> Please respond with any comments on this proposal by April 30,2024.
>
> Thanks,
>
> Sean, Deirdre and Joe
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

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, Dec 08, 2023 at 05:47:01PM +, Salz, Rich wrote:
> >
> > Good point.  https://github.com/richsalz/tls12-frozen/pull/12 has the
> > change.  I’ll wait until/if this is adopted by the WG to merge it.
>
> Reading through the document, I noticed the following:
>
> "To securely deploy TLS 1.2, either renegotiation must be disabled
> entirely, or this extension must be present." (where this extension
> means renegotiation_info)
>
>
> Entirely disabling renegotiation is not sufficient to fix the
> renegotiation issue in TLS 1.2. For fixing the issue, renegotiation_info
> MUST be required both ways.
>
> And then there is the other part to the triple handshake attack where
> using TLS exporters for authentication without extended_master_secret
> extension is insecure, even if renegotiation is not supported at all
> by either side and both sides implement renegotiation_info.
>
> And then there is more dangerously flawed stuff, e.g., session tickets
> (technically an extension).
>
>
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

> 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/draft-rsalz-tls-tls12-frozen/
> )
>  This call is to confirm this on the list.  Please indicate if you support
> the adoption of this draft and are willing to review and contribute text.
> If you do not support adoption of this draft please indicate why.  This
> call will close on December 20, 2023.
>
>
>
> As the co-author, I support this and am willing to continue working on it
> as needed.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

Thanks! Both points sound good to me.
I pushed these changes to the main branch, I guess we'll wait to accumulate
more (hopefully small) changes before publishing a new version.

thanks,
Nimrod


On Thu, 21 Sept 2023 at 18:24, Thomas Fossati 
wrote:

> Hi,
>
> Maybe I am completely confused but It also looks like the "SHOULD NOT
> non-ephemeral ECDH" (second para of §2) is already in the "general
> guidelines" of RFC9325.
>
> If you want to reiterate the point (which is good), you could just
> reference it?
>
> cheers, t
>
> On Thu, 21 Sept 2023 at 17:13, Thomas Fossati 
> wrote:
> >
> > Hi,
> >
> > It looks like the requirements in §2 and §3 regarding FFDH(E) update
> > the guidance given in RFC9325 (i.e., SHOULD NOT => MUST NOT).
> >
> > I guess this must be 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 Layer Security (TLS) WG of the IETF.
> > >
> > >Title:   Deprecating Obsolete Key Exchange Methods in TLS 1.2
> > >Authors: Carrick Bartle
> > > Nimrod Aviram
> > >Name:draft-ietf-tls-deprecate-obsolete-kex-03.txt
> > >Pages:   20
> > >Dates:   2023-09-21
> > >
> > > Abstract:
> > >
> > >This document deprecates the use of RSA key exchange and Diffie
> > >Hellman over a finite field in TLS 1.2, and discourages the use of
> > >static elliptic curve Diffie Hellman cipher suites.
> > >
> > >Note that these prescriptions apply only to TLS 1.2 since TLS 1.0
> and
> > >1.1 are deprecated by [RFC8996] and TLS 1.3 either does not use the
> > >affected algorithm or does not share the relevant configuration
> > >options.
> > >
> > > The IETF datatracker status page for this Internet-Draft is:
> > >
> https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/
> > >
> > > There is also an HTML version available at:
> > >
> https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-03.html
> > >
> > > A diff from the previous version is available at:
> > >
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-deprecate-obsolete-kex-03
> > >
> > > Internet-Drafts are also available by rsync at:
> > > rsync.ietf.org::internet-drafts
> > >
> > >
> > > ___
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

> 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 seems pretty clear.

There are a few valid arguments, from yourself and others here, to soften
the prescription regarding FFDHE from MUST NOT to SHOULD NOT, or similar.
That's a reasonable position to take, but at this stage I guess the
discussion is mostly around the presentation and structure of the document.

best,
Nimrod


On Fri, 14 Jul 2023 at 10:02, Peter Gutmann 
wrote:

> Viktor Dukhovni  writes:
>
> >What benefit do we expect from forcing weaker security (RSA key exchange
> or
> >cleartext in the case of SMTP) on the residual servers that don't do
> either
> >TLS 1.3 or ECDHE?
>
> This already happens a lot in wholesale banking, the admins have dutifully
> disabled DH because someone said so and so all keyex falls back to RSA
> circa
> 1995, and worst possible situation to be in.
>
> There needs to be clear text in there to say that if you can't do ECC then
> do
> DH but never RSA, or even just "keep using DH because it's still vastly
> better
> than the alternative of RSA".  At the moment the blanket "don't do DH" is
> in
> effect saying "use RSA keyex" to a chunk of the market.
>
> Peter.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

> 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 supported_groups and
key_share extensions corresponding to FFDHE (note that in TLS 1.3, the key
exchange is not determined by the cipher suite, but rather by these
extensions).


On Thu, 13 Jul 2023 at 16:04, Hubert Kario  wrote:

> On Wednesday, 12 July 2023 19:13:02 CEST, Viktor Dukhovni wrote:
> > On Wed, Jul 12, 2023 at 12:40:13PM -0400, Sean Turner wrote:
> >
> >>> On Jul 11, 2023, at 13:52, Salz, Rich  wrote:
> >>>  ...
> >>
> >> This appears in s2:
> >>
> >> Note that TLS 1.0 and 1.1 are deprecated by [RFC8996]
> >> and TLS 1.3 does not support FFDH [RFC8446].
> >
> > And section 3:
> >
> >
> >
> https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-02.html#section-3
> >
> > Clients MUST NOT offer and servers MUST NOT select FFDHE cipher
> > suites in TLS 1.2 connections. This includes all cipher suites
> > listed in the table in Appendix C. (Note that TLS 1.0 and 1.1 are
> > deprecated by [RFC8996].) FFDHE cipher suites in TLS 1.3 do not
> > suffer from the problems presented in Section 1; see [RFC8446].
> > Therefore, clients and servers MAY offer FFDHE cipher suites in TLS
> > 1.3 connections.
> >
> > Note that at least in Postfix (opportunistic STARTTLS), this advice will
> > be ignored.  FFDHE will remain supported in TLS 1.2, with ECDHE
> > preferred when offered by the client:
> >
> > https://tools.ietf.org/html/rfc7435
> >
> > The default group used by the server is either a compiled-in 2048-bit
> > group or one of the groups from appendix of RFC7919 built-in to OpenSSL.
> > There are zero reports of clients that can't handle 2048-bit groups (as
> > opposed to 1024).  Point "3" in the introduction may be outdated w.r.t.
> > to current practice.
> >
>
> And in general, it's far better to use FFDHE kex with legacy client than
> RSA.
> Getting RSA right is very hard, using ephemeral secrets for FFDHE is
> trivial
> and recommended practice already.
>
> also
>
> >  Therefore, clients and servers MAY offer FFDHE cipher suites in TLS
> >1.3 connections.
>
> 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 supported_groups and key_share extensions.
> --
> Regards,
> Hubert Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

> 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 is to keep repeating that, if that's OK.

> Y-> N
I'm confused, probably because I'm not familiar enough with RFC8447bis and
friends :-)
N "Indicates that the item has not been evaluated by the IETF and that the
IETF has made no statement about the suitability of the associated
mechanism."
So why would we have cipher suites with FFDHE as N? I thought we'd mark
them all as Discouraged.
I guess this impacts whether the appendices are normative, so let's first
try to help me get unconfused :-)

> we should probably change the name of the Appendices from “XXX Cipher
Suites Deprecated by This Document” to “Deprecated XXX Cipher Suites” to
not mislead readers that this document did all the deprecation.
Yep, SGTM. I'll make that change.


On Wed, 12 Jul 2023 at 21:31, Salz, Rich 
wrote:

> >This appears in s2:
> >Note that TLS 1.0 and 1.1 are deprecated by [RFC8996]
> >and TLS 1.3 does not support FFDH [RFC8446].
> >You’re suggesting that this be moved to s1?
>
> My main point is say it once, not repeat it in each section.
>
> > If that’s the case then maybe make Appendix B normative (and resort the
> Appendices), list the Y->N changes above in s5, and leave the rest
> informative (since they’re already or will be N)?
>
> That's a good idea.
>
> > And, we should probably change the name of the Appendices from “XXX
> Cipher Suites Deprecated by This Document” to “Deprecated XXX Cipher
> Suites” to not mislead readers that this document did all the deprecation.
> But, I do like the idea of adding a reference to this document for all the
> registry entries listed in Appendices - kind of like a tombstone.
>
> And two more good ideas.  In one email: an IETF record perhaps.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

Hi,

Since the draft has DHE cipher suites as a MUST NOT, I believe the
appropriate value is indeed "Discouraged".
(From 8447bis: "N: Indicates that the item has not been evaluated by the
IETF and that the IETF has made no statement about the suitability of the
associated mechanism." That seems incongruent with MUST NOT.)

We might as well add text to change the RSA cipher suites to "D".
It'd be great if one of the chairs could please chime in and let us know if
this sounds reasonable?

thanks,
Nimrod


On Wed, 29 Mar 2023 at 08:28, John Mattsson  wrote:

> Hi,
>
>
>
> 5.  IANA Considerations
>
>
>
> This document requests IANA to mark the cipher suites listed in Appendix
> C as not recommended in the "TLS Cipher Suites" registry. Note that all
> cipher suites listed in Appendix A and in Appendix D are already marked
> as not recommended in the registry.
>
> How do we split the IANA actions for cipher suites between this document, 
> RFC8447, and draft-mattsson-tls-psk-ke-dont-dont-dont?
>
> ”N” seems highly inappropriate for TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
>
> that is very clearly a “D”
>
> What about TLS_DHE_RSA_WITH_AES_128_GCM_SHA256. Is that a ”N”? The
> definition of discourage is clear with RFC8447bis. The definition of
> deprecated is not as clear.
>
>
>
> Cheers,
>
> John
>
>
> *From: *TLS  on behalf of internet-dra...@ietf.org <
> internet-dra...@ietf.org>
> *Date: *Sunday, 26 March 2023 at 00:54
> *To: *i-d-annou...@ietf.org 
> *Cc: *tls@ietf.org 
> *Subject: *[TLS] I-D Action: draft-ietf-tls-deprecate-obsolete-kex-02.txt
>
>
> A New Internet-Draft is available from the on-line 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
>Filename: draft-ietf-tls-deprecate-obsolete-kex-02.txt
>Pages   : 20
>Date: 2023-03-25
>
> Abstract:
>This document deprecates the use of RSA key exchange and Diffie
>Hellman over a finite field in TLS 1.2, and discourages the use of
>static elliptic curve Diffie Hellman cipher suites.
>
>Note that these prescriptions apply only to TLS 1.2 since TLS 1.0 and
>1.1 are deprecated by [RFC8996] and TLS 1.3 either does not use the
>affected algorithm or does not share the relevant configuration
>options.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/
>
> There is also an HTML version available at:
>
> https://www.ietf.org/archive/id/draft-ietf-tls-deprecate-obsolete-kex-02.html
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-deprecate-obsolete-kex-02
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

> 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
> call. We should have closed this much sooner.
>
> After reviewing the responses on the mailing list, and taking into
> consideration discussions that took place during meetings, it is our
> assessment that there is rough consensus to deprecate FFDHE in TLS 1.2,
> i.e., all TLS_DHE_* ciphersuites.
>
> Authors, can you please update the document (and fix the clarification
> that Ekr recently raised) at your convenience?
>
> Best,
> Chris, Joe, Sean
>
> > On Dec 13, 2022, at 9:46 AM, Sean Turner  wrote:
> >
> > During the tls@IETF 115 session topic covering
> draft-ietd-tls-deprecate-obsolete-kex, the sense of the room was that there
> was support to deprecate all FFDHE cipher suites including well-known
> groups. This message starts the process to judge whether there is consensus
> to deprecate all FFDHE cipher suites including those well-known groups.
> Please indicate whether you do or do not support deprecation of FFDHE
> cipher suites by 2359UTC on 6 January 2023. If do not support deprecation,
> please indicate why.
> >
> > NOTE: We had an earlier consensus call on this topic when adopting
> draft-ietd-tls-deprecate-obsolete-kex, but the results were inconclusive.
> If necessary, we will start consensus calls on other issues in separate
> threads.
> >
> > Cheers,
> > Chris, Joe, and Sean
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

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 Nimrod Aviram 
> wrote:
>
>> 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.
>>
>
> That's what I got from the title of Appendix CA, but then what does this
> text
> mean:
>
> "All the cipher suites that do not meet the above requirements are
>  listed in the table in Appendix C."
>
> Because, as you say, some of the suites in C meet this requirement.
>
>
>
>>
>> However, we also have an unresolved consensus call regarding whether/to
>> what extent to permit FFDHE when this document (hopefully) becomes an
>> official RFC:
>> https://mailarchive.ietf.org/arch/msg/tls/iZGV0kKHfbV5MrO-owB8mFwfffw/
>> so at any rate, the current text around FFDHE is mostly a placeholder.
>> I do hope to present at the upcoming WG meeting and resolve this issue,
>> which should be the last one (famous last words, I know).
>>
>> Happy to answer further questions, or generally get a discussion going on
>> here before the meeting.
>>
>
> OK, so we don't need to spend too much time on this, but I'd still like to
> understand
> the intent :)
>
> -Ekr
>
>
>>
>> best,
>> Nimrod
>>
>>
>>
>>
>> On Thu, 2 Mar 2023 at 23:19, Eric Rescorla  wrote:
>>
>>> Hi folks,
>>>
>>> I was just reading draft-ietf-tls-deprecate-obsolete-kex-01.txt
>>> and the combination of Section 3 and Appendix C is confusing
>>> to me.
>>>
>>> Specifically, the text says:
>>>
>>>Clients and servers MAY offer fully ephemeral FFDHE cipher suites in
>>>TLS 1.2 connections under the following conditions:
>>>
>>>1.  Clients and servers MUST NOT reuse ephemeral DHE public keys
>>>across TLS connections for all existing (and future) TLS
>>>versions.  Doing so invalidates forward secrecy properties of
>>>these connections.  For DHE, such reuse may also lead to
>>>vulnerabilities such as those used in the [Raccoon] attack.  See
>>>Section 6 for related discussion.
>>>
>>>2.  The group size is at least 2048 bits.
>>>
>>>...
>>>
>>>All the cipher suites that do not meet the above requirements are
>>>listed in the table in Appendix C.
>>>
>>>
>>> And then Appendix C lists, for instance:
>>>
>>>TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>>>
>>> Which as I understand it, can be used with the above requirements
>>> as long as you use a suitable group, so this makes me think maybe
>>> I don't understand the text. What cipher suites is this intended
>>> to permit in TLS 1.2?
>>>
>>> -Ekr
>>>
>>>
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

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
primitive or protocol version. As one example, it seems like we plan to
deprecate RSA key exchange in TLS 1.2 soon (as part of
draft-ietf-tls-deprecate-obsolete-kex). However, so far we did not
explicitly communicate this to vendors, and it seems like vendors either
have to follow the mailing list and deduce the likelihood of an upcoming
deprecation, or face a deprecation RFC at some random point in time (from
their point of view).

And whatever the specifics of RSA key exchange deprecation, this will
likely not be the last time we deprecate something :-)

Specifically, we will have to decide when/if to deprecate version 1.2 of
TLS within, say, the next 20 years.

One possible solution is to publish “expected deprecation timeline”
documents:
Let’s fix some timeframe which “is enough for everyone to upgrade at least
once” (famous last words, I know). I think of this timeframe as 3 or 5
years, but it could as well be 8 or 10 years, and this solution would still
be viable; let’s denote the number of years as X. So, an “expected
deprecation timeline” document could specify that within X years,
implementations MUST support TLS 1.3, and within 2X years, implementations
MUST NOT support TLS 1.2. (If X=8 years, then we specify that by 2031
implementations MUST support TLS 1.3, and by 2039 implementations MUST NOT
support TLS 1.2.) This would clarify the WG’s expectations to vendors, and
would save the WG valuable time discussing whether enough implementations
in the field support the new protocol/primitive.

Is there interest here in such a solution?

Credit where it’s due: This is based on an idea I heard from Dan Bernstein
- thanks Dan.

Best,
Nimrod
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

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 unresolved consensus call regarding whether/to
what extent to permit FFDHE when this document (hopefully) becomes an
official RFC:
https://mailarchive.ietf.org/arch/msg/tls/iZGV0kKHfbV5MrO-owB8mFwfffw/
so at any rate, the current text around FFDHE is mostly a placeholder.
I do hope to present at the upcoming WG meeting and resolve this issue,
which should be the last one (famous last words, I know).

Happy to answer further questions, or generally get a discussion going on
here before the meeting.

best,
Nimrod




On Thu, 2 Mar 2023 at 23:19, Eric Rescorla  wrote:

> Hi folks,
>
> I was just reading draft-ietf-tls-deprecate-obsolete-kex-01.txt
> and the combination of Section 3 and Appendix C is confusing
> to me.
>
> Specifically, the text says:
>
>Clients and servers MAY offer fully ephemeral FFDHE cipher suites in
>TLS 1.2 connections under the following conditions:
>
>1.  Clients and servers MUST NOT reuse ephemeral DHE public keys
>across TLS connections for all existing (and future) TLS
>versions.  Doing so invalidates forward secrecy properties of
>these connections.  For DHE, such reuse may also lead to
>vulnerabilities such as those used in the [Raccoon] attack.  See
>Section 6 for related discussion.
>
>2.  The group size is at least 2048 bits.
>
>...
>
>All the cipher suites that do not meet the above requirements are
>listed in the table in Appendix C.
>
>
> And then Appendix C lists, for instance:
>
>TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>
> Which as I understand it, can be used with the above requirements
> as long as you use a suitable group, so this makes me think maybe
> I don't understand the text. What cipher suites is this intended
> to permit in TLS 1.2?
>
> -Ekr
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

> 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 would require two primality tests, for the
modulus p and for (p-1)/2.
Several folks here have argued that these primality tests would be
prohibitively expensive for TLS clients to perform per-handshake (and this
is also my general understanding of the cost of primality tests).

Could you please elaborate what client behavior you propose, and how you
envision clients to bear the cost?

(To concede a point in advance: It is obviously possible to _assume_ that
if the server presents a modulus, then it "must" be a safe prime, or it
meets some desired security notion that the server operator has deemed
sufficient for the connection. However, experience shows that this is not
necessarily the case in practice; see e.g. the "Small Subgroups" paper
referenced in the draft. Since you used the word "verify", I'm assuming
that's not what you meant?)

best,
Nimrod




On Mon, 2 Jan 2023 at 15:52, Hubert Kario  wrote:

> On Thursday, 22 December 2022 23:26:26 CET, Carrick Bartle wrote:
> >> the latter is basically unexploitable with properly behaving
> >> hosts in TLSv1.2
> >
> > Well, right, that's the trick. The issue that people have
> > pointed out with FFDHE is that it's very easy to have a host
> > that is not properly behaving (see RFC 7919, which is referenced
> > in our draft).
>
> It's also easy and quick to verify that the server *is* behaving correctly
> and thus is not exploitable.
>
> > On Wed, Dec 21, 2022 at 5:14 AM Hubert Kario  wrote:
> > On Tuesday, 20 December 2022 19:37:14 CET, Rob Sayre wrote:
> >> On Tue, Dec 20, 2022 at 4:53 AM Hubert Kario  wrote:
> >> Thus the deprecation of it is a matter of taste, not
> >> cryptographic
> >> necessity.
> >>
> >> I'm sorry if I'm being dense here, but isn't all of this a
> >> SHOULD NOT in RFC 9325?
> >>
> >>
> https://www.rfc-editor.org/rfc/rfc9325.html#name-recommendations-cipher-suit
> >>
> >> Maybe I'm misreading that RFC, but given that it's a BCP, it
> >> seems like deprecation is a natural step that reflects IETF
> >> consensus.
> >
> > that RFC marks both TLS_RSA_* and TLS_DHE_* as "SHOULD NOT".
> > Given that the former is still being exploited close to 25 years after
> the
> > Bleichenbacher attack was discovered, while the latter is basically
> > unexploitable with properly behaving hosts in TLSv1.2, I don't think it's
> > correct to consider them at the same level.
> >
> > Yes, if you have ECDHE available, you SHOULD NOT use DHE in TLSv1.2. But
> if
> > everything you have is either TLS_RSA_* and TLS_DHE_*, then you're far
> > better
> > of with TLS_DHE_*.
>
> --
> Regards,
> Hubert Kario
> Principal Quality Engineer, RHEL Crypto team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

I'm not sure such an implicit approach best serves everyone's interests...
Vendors would be better served if we explicit communicate expected
timelines for deprecation, and expected timelines where maintaining support
is a "must"/MUST/SHOULD.
And this WG would be better served if we have explicitly communicated such
timelines, since then deprecation is straightforward, instead of the
current situation where we need to have discussions such as the current one.

But I think having this discussion in this thread makes it hard to have the
discussion around FFDHE. Let me bring up this point in a separate thread
later, after the dust around FFDHE has settled :-)

best,
Nimrod


On Fri, 16 Dec 2022 at 18:49, Russ Housley  wrote:

> There have been attempts in the past to signal this to product planners:
>
>SHOULD+This term means the same as SHOULD.  However, it is likely
>   that an algorithm marked as SHOULD+ will be promoted at
>   some future time to be a MUST.
>
>SHOULD-This term means the same as SHOULD.  However, an algorithm
>   marked as SHOULD- may be deprecated to a MAY in a future
>   version of this document.
>
>MUST-  This term means the same as MUST.  However, we expect at
>   some point that this algorithm will no longer be a MUST in
>   a future document.  Although its status will be determined
>   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:
>
> > 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 coordinates this for itself.
> We should do this, if we can. I would suggest "Intent to Deprecate"
> documents that e.g. make it clear that you cannot count on TLS 1.2 only in,
> say, 2030. Otherwise we'll have the same conversation around that
> deprecation then.
>
> Is there interest in this?
>
>
>
> On Fri, 16 Dec 2022 at 09:41, Hal Murray  wrote:
>
>>
>> say...@gmail.com said:
>> > For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
>> > endlessly keeping old cipher suites alive. The unwise cost-cutting in
>> those
>> > areas does not constrain the rest of the internet.
>>
>> Agreeded, but the software maintainers can't just drop support for X
>> because
>> it has been deprecated.  There needs to be some plan with a schedule that
>> gives downstream users time to get their act in gear.
>>
>> Should there be an IETF group to help coordinate things like this?  If
>> nothing
>> else, there should be a RFC explaining the problem to vendors planning to
>> ship
>> software that can't be updated -- and showing their potential customers
>> what
>> to consider.
>>   Maybe data sheets should list the RFCs they depend upon -- with a big
>> red
>> arrow nwxt to the ones that have been obsoleted or deprecated.
>>
>> IoT and embedded are not the only problems.  There are many companies
>> that run
>> old stable software.  Ubuntu supports LTS releases for 5 years with 5
>> more
>> available for a fee.
>>   https://ubuntu.com/about/release-cycle
>> Do we have to worry about this area?  Or will the companies like Ubuntu
>> take
>> care of their customers?
>>
>>
>>
>>
>> --
>> These are my opinions.  I hate spam.
>>
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

> 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 coordinates this for itself.
We should do this, if we can. I would suggest "Intent to Deprecate"
documents that e.g. make it clear that you cannot count on TLS 1.2 only in,
say, 2030. Otherwise we'll have the same conversation around that
deprecation then.

Is there interest in this?



On Fri, 16 Dec 2022 at 09:41, Hal Murray  wrote:

>
> say...@gmail.com said:
> > For my part, I'm sick of "IoT" or "SCADA" or "embedded" vendors just
> > endlessly keeping old cipher suites alive. The unwise cost-cutting in
> those
> > areas does not constrain the rest of the internet.
>
> Agreeded, but the software maintainers can't just drop support for X
> because
> it has been deprecated.  There needs to be some plan with a schedule that
> gives downstream users time to get their act in gear.
>
> Should there be an IETF group to help coordinate things like this?  If
> nothing
> else, there should be a RFC explaining the problem to vendors planning to
> ship
> software that can't be updated -- and showing their potential customers
> what
> to consider.
>   Maybe data sheets should list the RFCs they depend upon -- with a big
> red
> arrow nwxt to the ones that have been obsoleted or deprecated.
>
> IoT and embedded are not the only problems.  There are many companies that
> run
> old stable software.  Ubuntu supports LTS releases for 5 years with 5 more
> available for a fee.
>   https://ubuntu.com/about/release-cycle
> Do we have to worry about this area?  Or will the companies like Ubuntu
> take
> care of their customers?
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

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 deployed devices (IoT,
> >SCADA) that aren’t upgradable – and the new stuff will have to access
> them.
>
> It's actually much worse than just SCADA, there are deployments in things
> like
> wholesale banking where the semi-deprecation of DH suites has led to them
> falling back to RSA instead.  This pointless removal of FFDHE, while it'll
> be
> written as MUST NOT FFDHE, will actually be MUST RSA in some environments.
>
> In other words not only will it not make things any more secure, it'll make
> some things much, much less secure.
>
> Peter.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

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 :-)

My intent here is only to make sure we have a good record of the comments
made. I hope to follow up soon with a suggested way forward for the draft.

thanks,
Nimrod
===
Scott Fluhrer: We can only check for group structure if it's a safe prime,
and even for a safe prime it's too expensive. Suggest limiting groups to a
safelist.
Mike Ounsworth: Automated scanning tools routinely flag standardized FFDHE
groups.
Daniel Kahn Gillmor and Thom Wiggers: This is because of the Logjam paper
and precomputation. But they missed that the advice to generate your own DH
params was for 1024 bit parameters for sofware that didn't support anything
else.
Daniel Kahn Gillmor: Would be good to discourage non-standard groups, while
acknowledging the original argument for non-standard groups and explaining
why it doesn't motivate non-standard groups today.

Viktor Dukhovni: Postfix is far from the only one with non-standardized,
built-in default groups. Even for Postfix there are several groups,
depending on the version. Would be hard to build a list of widespread
groups.
Ben Kaduk: Can we start a registry for safe, widespread groups?

Martin Thomson: We tried using a safelist (that included only 7919 groups?
- Nimrod) but people use weird groups, and we couldn't turn that on.
David Benjamin: Agree, better to turn off FFDHE entirely.
The deployability issue with 7919 is also documented in
https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo/
https://mailarchive.ietf.org/arch/msg/tls/DzazUXCUZDUpVgBPVHOwatb65dA/

Uri Blumenthal: We should neither recommend or discourage non-standard
groups. Leave it to each operator to decide for themselves, they likely
know what they're doing.
Jonathan Hoyland and Martin Thomson: The pen-testing comment provides a
counterargument.

Uri Blumenthal: The draft is unnecessarily strict, from both deployment and
security points of view. Examples of stuff that should be retained: RSA,
FFDHE. PQ implications: all the NIST PQC winners and finalists are KEMs,
not KA - aka, similar to RSA rather than DH.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

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 chime in with
comments, issues and questions!

best,
Nimrod


Deprecating Obsolete Key Exchange, IETF 114.pdf
Description: Adobe PDF document
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

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 improvements welcome!

best,
Nimrod


On Tue, 14 Jun 2022 at 02:53, Joseph Salowey  wrote:

> draft-aviram-deprecate-obsolete-kex-01 has been revised and merged in
> content from draft-bartle-tls-deprecate-ffdh to address some of the
> concerns raised in the adoption call. The chairs think this is a good
> starting point for adoption as a working group item. Authors please submit
> the draft as draft-ietf-tls-deprecate-obsolete-kex-00.
>
> Thanks,
>
> Joe, Chris and Sean
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

Ah, got it. You're saying the Reference column would allow us to introduce
other combination methods if needed, through separate defining documents.
That sounds good to me as an upgrade path. Thanks!


On Thu, 28 Apr 2022 at 22:29, David Benjamin  wrote:

> I don't think the upgrade path needs any mention or changes. It's no
> different from what we always do: allocate a new code point.
>
> Now that we've removed all the in-protocol combinator schemes from the
> early versions, what remains is simply *a* method for defining a
> NameGroup out of a pile of KEMs. It makes no commitment but the
> tautological one: NamedGroups defined using this method will use this
> method.
>
> The method doesn't preclude us from defining NameGroups via other
> methods---after all, the existing NameGroups are defined differently
> <https://datatracker.ietf.org/doc/html/rfc8446#section-7.4>. Should
> someone wish to define a hybrid NamedGroup with a different combination
> method (e.g. perhaps to hybrid with a KEMs that does not meet the
> requirements in this document), they can simply not cite this document.
>
> Likewise, I don't think it's useful to extend the registry here. Any
> NamedGroup, this method or otherwise, already needs a standard name (the
> Description column) and a defining document (the Reference column). Those
> two are sufficient to distinguish value=1234; desc=x25519_somepqscheme;
> 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 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
>> the combination method. One possible upgrade path is for the relevant code
>> points in the NamedGroup registry to indicate not only the key exchange
>> algorithms, but also the combination method. I'm not sure whether this is
>> sufficient for an upgrade path, but it seems necessary.
>>
>> As for the document itself, I support moving it forward. As Douglas
>> noted, if we would eventually introduce a new key combination method, that
>> can happen in a new document.
>>
>> [1]
>> https://mailarchive.ietf.org/arch/msg/tls/SGyUKtTWoW9h9rX6Mo64fwfmxMY/
>>
>>
>>
>> On Wed, 27 Apr 2022 at 18:28, Christopher Wood 
>> wrote:
>>
>>> This email commences a two week WGLC for draft-ietf-tls-hybrid-design,
>>> located here:
>>>
>>>https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>>>
>>> We do not intend to allocate any code points at this time and will park
>>> the document after the call is complete. Once CFRG produces suitable
>>> algorithms for consideration, we will then add them to the NamedGroup
>>> registry through the normal process [1] and move the document forward.
>>>
>>> Please review the draft and send your comments to the list. This WGLC
>>> will conclude on May 13.
>>>
>>> Best,
>>> Chris, for the chairs
>>>
>>> [1]
>>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

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 the
combination method. One possible upgrade path is for the relevant code
points in the NamedGroup registry to indicate not only the key exchange
algorithms, but also the combination method. I'm not sure whether this is
sufficient for an upgrade path, but it seems necessary.

As for the document itself, I support moving it forward. As Douglas noted,
if we would eventually introduce a new key combination method, that can
happen in a new document.

[1] https://mailarchive.ietf.org/arch/msg/tls/SGyUKtTWoW9h9rX6Mo64fwfmxMY/



On Wed, 27 Apr 2022 at 18:28, Christopher Wood  wrote:

> This email commences a two week WGLC for draft-ietf-tls-hybrid-design,
> located here:
>
>https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> We do not intend to allocate any code points at this time and will park
> the document after the call is complete. Once CFRG produces suitable
> algorithms for consideration, we will then add them to the NamedGroup
> registry through the normal process [1] and move the document forward.
>
> Please review the draft and send your comments to the list. This WGLC will
> conclude on May 13.
>
> Best,
> Chris, for the chairs
>
> [1]
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Deprecating Obsolete Key Exchange Methods in TLS

[Nimrod Aviram]

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
.

The merged draft prescribes the following:
1. RSA key exchange is a MUST NOT.
2. Non-ephemeral finite-field DH is a MUST NOT.
3. Non-ephemeral ECDH is a SHOULD NOT.
4. Ephemeral finite-field DH (DHE) is a MAY, only when fully ephemeral, and
only using a well-known group of size at least 2048 bits.

We added greater justification for point 3

above to address concerns previously raised on the list.

We'd love to hear your thoughts.

best wishes,
Carrick and Nimrod
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Revised hybrid key exchange draft

[Nimrod Aviram]

Thank you for the discussion :-)

1. The construction is proven to satisfy this property under precise
assumptions about its components. A formal theorem statement can be found
in Theorem 1 on page 11 of ePrint 2022/065
<https://eprint.iacr.org/2022/065>. A discussion of how to instantiate
those components can be found in Section 5 of the same paper. We think the
resulting assumptions are reasonable when SHA-256 is used in the
instantiation, as in our reference implementation
<https://github.com/nimia/kdf_reference_implementation/blob/main/reference_implementation.c>
.

2. There is no conjecture involved, beyond whether the assumptions required
for the proof hold. Such assumptions are quite common in cryptography.

3. Please see my previous email to the list: Current proofs for TLS 1.3
generally require HKDF to act as a dual-PRF (or as a random oracle - an
even stronger 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 property.
>
> To make sure I understand:
>
>(1) You mean that the construction is _conjectured_ to satisfy this
>property, i.e., to be a dual PRF? There must be some sort of
>limit on the hash functions allowed here; is SHA-256 allowed?
>
>(2) The basis for this conjecture is your previous claim that the
>construction provides "provable security"?
>
>(3) Meanwhile you claim that the H(x,y) construction used in the
>hybrid-key-exchange draft doesn't provide "provable security"?
>
> In any case, can you please clarify what precisely you mean by "provable
> security" in the previous claim that the construction provides "provable
> security"? Clarity is a prerequisite for evaluation of the claim. Thanks
> in advance.
>
> ---Dan
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Revised hybrid key exchange draft

[Nimrod Aviram]

Current proofs for TLS 1.3 generally require HKDF to act as a dual-PRF (or
as a random oracle - an even stronger assumption). HKDF has not yet been
proven to satisfy this property, under any assumption. Our construction
satisfies this property.

best,
Nimrod


On Mon, 24 Jan 2022 at 17:13, D. J. 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 saying it doesn't provide "provable security"? Can you please
> clarify what precisely you mean by "provable security" here?
>
> ---Dan
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Revised hybrid key exchange draft

[Nimrod Aviram]

> I might have preferred a more efficient option though.
By efficient, are you referring to the computation cost, or the
implementation complexity?
As to the former, the new construction requires ~7 microseconds, whereas
HKDF.extract requires ~1.
As to the implementation complexity, if that's your main concern, could you
please elaborate about your concern?
FWIW, our Python reference implementation
<https://github.com/nimia/kdf_reference_implementation/blob/main/kdf_reference_implementation.py#L54>
is quite short. We also provide a C implementation that wasn't hard to
write (for me). And I can't imagine this causing interop problems.

> The nice thing about the hybrid draft is that it isn't a firm commitment
to any particular combination method.
> It only suggests a method.
That's not my understanding. My reading is that the draft prescribes a
combination method, and if adopted and standardized, it would be
concatenation, for all group combinations.
Do you envision a scenario where a different combination method is
standardized? If so, could you please elaborate how this would come to pass
- perhaps as a revision of the eventual hybrid standard?
Douglas, could you please chime in regarding this issue? If standardized,
do you envision changing/adding combination methods?

thanks,
Nimrod



On Fri, 21 Jan 2022 at 02:03, Martin Thomson  wrote:

> I am not convinced that the extra effort is justified.
>
> However, I am convinced that the proposed construction is complex.
>
> combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2),
> data=1||F(k1)))
> H1(k) = H('derive1' || k)
> H2(k) = H('derive2' || k)
> F(m) =
> H(0||m1)||H(1||m1)||...||H(j-1||m1)||H(0||m2)||H(1||m2)||...||H(j-1||m2)||H(0||mn)||H(1||mn)||...||H(j-1||mn)
> for m = m1||m2||...||mn and j =~ 3
>
> It's nice that this is a dual PRF; that's something I think we've wanted
> for a number of other reasons in TLS.  I might have preferred a more
> efficient option though.
>
> Comparing that to k1 || k2 means - for me - this needs much stronger
> justification.
>
> Perhaps if the CFRG were to standardize a dual (or multi) PRF that were
> more efficient I would be more favourably inclined toward its inclusion -
> in a revision of the core specification.
>
> 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 this opportunity would effectively further embed the
> problem" (or maybe "effectively" is doing a little too much work there).
>
> On Wed, Jan 19, 2022, at 22:21, Nimrod Aviram wrote:
> > Hi Everyone,
> >
> >
> > As Douglas wrote, we have discussed the issues together at length, and
> > we thank him for the productive (and friendly :-)) conversation.
> >
> >
> > Our paper, which describes our concerns, can be found here:
> > https://eprint.iacr.org/2022/065
> >
> > And a reference implementation of our proposed KDF:
> >
> https://github.com/nimia/kdf_reference_implementation/blob/main/kdf_reference_implementation.py#L60
> >
> >
> > A few points from our side:
> >
> > Firstly, our proposed construction is simple to implement (see the
> > Python code above), and adds a modest overhead of a few microseconds
> > (see the paper).
> >
> >
> > Re: point a) from Douglas’ first mail: Admittedly, our concerns are
> > broader than Hybrid Key Exchange in TLS. However, we view the
> > standardization of Hybrid Key Exchange as an opportunity to add defense
> > in depth. Missing this opportunity would effectively further embed the
> > problem. We don’t see another such opportunity on the horizon: If we
> > standardize a TLS extension in a few years, getting everyone to deploy
> > the extension would be hard. Whereas here everyone has to deploy the
> > new thing anyway, so we might as well make it as robust as we can.
> >
> >
> > Consider the following: SHA-1 weaknesses to collisions were first
> > really highlighted in 2005. TLS version 1.0 was standardised in 2006
> > and hardcoded the use of SHA-1, and MD5 (admittedly, for use in HMAC).
> > TLS 1.2 was standardised in 2008, and formal deprecation of SHA-1
> > occurred in 2011 by NIST. The standard deprecating the use of SHA-1 in
> > TLS 1.2 digital signatures occurred in 2021. In 2016, TLS support
> > (according to Qualys SSL Labs SSL survey) was over 90%. In 2020, TLS
> > 1.0 support was still above 50%, despite practical chosen-prefix
> > collision attacks against SHA-1 being possible. Being robust against
> > future threats w

Re: [TLS] Revised hybrid key exchange draft

[Nimrod Aviram]

Hi Everyone,

As Douglas wrote, we have discussed the issues together at length, and we
thank him for the productive (and friendly :-)) conversation.

Our paper, which describes our concerns, can be found here:
https://eprint.iacr.org/2022/065

And a reference implementation of our proposed KDF:
https://github.com/nimia/kdf_reference_implementation/blob/main/kdf_reference_implementation.py#L60

A few points from our side:

Firstly, our proposed construction is simple to implement (see the Python
code above), and adds a modest overhead of a few microseconds (see the
paper).

Re: point a) from Douglas’ first mail: Admittedly, our concerns are broader
than Hybrid Key Exchange in TLS. However, we view the standardization of
Hybrid Key Exchange as an opportunity to add defense in depth. Missing this
opportunity would effectively further embed the problem. We don’t see
another such opportunity on the horizon: If we standardize a TLS extension
in a few years, getting everyone to deploy the extension would be hard.
Whereas here everyone has to deploy the new thing anyway, so we might as
well make it as robust as we can.

Consider the following: SHA-1 weaknesses to collisions were first really
highlighted in 2005. TLS version 1.0 was standardised in 2006 and hardcoded
the use of SHA-1, and MD5 (admittedly, for use in HMAC). TLS 1.2 was
standardised in 2008, and formal deprecation of SHA-1 occurred in 2011 by
NIST. The standard deprecating the use of SHA-1 in TLS 1.2 digital
signatures occurred in 2021. In 2016, TLS support (according to Qualys SSL
Labs SSL survey) was over 90%. In 2020, TLS 1.0 support was still above
50%, despite practical chosen-prefix collision attacks against SHA-1 being
possible. Being robust against future threats when given the option is
something that we should seriously take time to consider.

As to ekr’s response that the standard already states we need a
collision-resistant hash function: Brendel et al. [1] proved that the TLS
1.3 ECDHE handshake survives losing the collision resistance of the hash
function, as long as HKDF retains its pseudorandomness property. However,
HKDF does not provably possess this property to begin with, with respect to
the (EC)DH shared secret input, since this input is fed as the message
input to HMAC, and HMAC/HKDF is not a dual PRF.

To summarize, we recommend using our new proposed construction. It’s fast,
easy to implement, and provides provable security. We see no reason to
entrench a problem if we’re already changing the protocol in this area, and
requiring implementation changes anyway.

Best,

Nimrod, Ben, Ilan, Kenny, Eyal, and Eylon

[1] https://www.felixguenther.info/publications/ESORICS_BreFisGun19.pdf



On Tue, 11 Jan 2022 at 21:08, Douglas Stebila  wrote:

> Hello TLS working group,
>
> We've posted a revised version of "Hybrid key exchange in TLS 1.3" [1].
> Based on revision requests from the last draft, the main change is removing
> the unnecessary 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 hybrid shared
> secret in this document -- direct concatenation -- was risky in a scenario
> where the hash function used in TLS key derivation and transcript hashing
> is not collision resistant.  Nimrod and his colleagues exchanged many
> emails with us over the past few months to help us understand their
> concerns.  In the end we think the concerns are low and we have not made
> any changes in this draft, although if we receive different guidance from
> the working group, we'll do so.
>
> There were two types of concerns that Nimrod and his colleagues identified
> [2,3]:
>
> a) An attacker who can find collisions in the hash function can cause
> different sessions to arrive at the same session key.  This concern is
> largely independent of this hybrid key exchange draft, as it focuses on
> collisions in the transcript hash, and affects existing TLS 1.3 even
> without this draft being adopted.  If the TLS working group thinks this is
> a concern that should be addressed, it seems like it should be addressed at
> the overall level of TLS 1.3, rather than for this specific hybrid key
> exchange draft.
>
> b) An attacker who can find collisions in the hash function and has a
> certain level of control over the first of the two shared secrets in the
> hybrid shared secret concatenation may be able to carry out an iterative
> attack to recover bytes of the second shared secret.  The iterative is
> similar to the APOP attacks [4,5] and also somewhat similar to the CRIME
> attack [6].  After discussing further with Nimrod and his colleagues, we
> identified that the following conditions need to be s

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

[Nimrod Aviram]

I'd like to understand your position better.

> Since (if memory serves me) KDF is HMAC-based, rather than merely
SHA-based – it won’t matter from the security point of view whether SHA256
will or will not show collisions.
So, if I understand correctly, you argue that the text David Benjamin
quoted from Appendix E.1 is wrong?
The second paragraph in Appendix E.1.1:
https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1.1
"This requires the underlying hash function to be collision resistant..."

Moreover, if it won’t matter from the security point of view whether SHA256
will or will not show collisions, then this implies that (hypothetically)
switching from SHA256 to e.g. MD5 will not degrade security.
Is this your position? If so, could you please provide references that
support this position, e.g. prove security under a non-CR hash function?

> I don’t think so.
If I understand correctly, you wrote this in response to me saying "an
attacker that can establish multiple PSKs of their choice with another
party can cause two sessions with two different PSKs to share the same
early_secret... This likely violates the security proof for TLS 1.3, in and
of itself."
Is this what you're referring to? And I understand that you claim that an
attacker achieving this would not violate any proven security property of
TLS 1.3?

best,
Nimrod


On Thu, 2 Sept 2021 at 23:32, Blumenthal, Uri - 0553 - MITLL 
wrote:

> The APOP attack demonstrates that concatenating secrets may be dangerous,
> as a general cryptographic practice.
>
>
>
> I disagree with the word “general” here.
>
>
>
> As to the TLS KDF, if future SHA256 cryptanalysis results in collisions,
>
>
>
> Since (if memory serves me) KDF is HMAC-based, rather than merely
> SHA-based – it won’t matter from the security point of view whether SHA256
> will or will not show collisions.
>
>
>
> This likely violates the security proof for TLS 1.3, in and of itself.
>
>
>
> I don’t think so.
>
>
>
> A similar violation of the security guarantee seems to arise when using
> hybrid key exchange with a PQ KEM.
>
>
>
> I absolutely don’t think so.
>
>
>
> Or if that's what you're asking: As we write, we are unaware of a way to
> apply the APOP attack to the TLS KDF.
>
>
>
> Excellent, thanks! I concur here.
>
>
>
> We view this as an opportunity to defend-in-depth against such issues,
> 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 KDF?
>
>
>
> --
>
> Regards,
>
> Uri
>
>
>
> *There are two ways to design a system. One is to make is so simple there
> are obviously no deficiencies.*
>
> *The other is to make it so complex there are no obvious deficiencies.*
>
> *
>   
>  -
> C. A. R. Hoare*
>
>
>
>
>
> *From: *TLS  on behalf of Nimrod Aviram <
> nimrod.avi...@gmail.com>
> *Date: *Wednesday, September 1, 2021 at 15:58
> *To: *"" 
> *Cc: *Eylon Yogev , Ilan Komargodski <
> ilanko...@gmail.com>, Benjamin Dowling , Eyal
> Ronen 
> *Subject: *[TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3
>
>
>
> (This note is also available on Github
> <https://github.com/nimia/kdf_public#readme> for ease of reading.)
>
>
>
> This note identifies a possible security problem in the "Hybrid key
> exchange in
> TLS 1.3" document, stemming from how cryptographic secrets are combined. In
> short: constructions that concatenate secrets are vulnerable when the
> underlying
> hash function is not collision-resistant. We are unaware of a full attack
> that leverages the underlying problem. However, we view this as an
> opportunity
> to defend-in-depth against such issues, while the document is not yet
> finalized.
> We propose a new construction that seems robust to this potential issue,
> and we
> are in the process of writing a technical report that includes a full
> security
> proof.
>
> # Concatenating Secrets May Be Dangerous
>
> The APOP attack (see appendix for a brief description) demonstrates that
> concatenating secrets to potentially attacker-controlled input might be
> dangerous. Currently, the "Hybrid key exchange in TLS 1.3" document uses
> secret
> concatenation as the preferred way to combine secrets. (This was an
> understandable design choice given how little this issue has been studied.)
>
> We recommend a defense-in-depth approach ag

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

[Nimrod Aviram]

gt;> 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 KDF?
>>
>>
>>
>> --
>>
>> Regards,
>>
>> Uri
>>
>>
>>
>> *There are two ways to design a system. One is to make is so simple there
>> are obviously no deficiencies.*
>>
>> *The other is to make it so complex there are no obvious deficiencies.*
>>
>> *
>>  
>>   -
>> C. A. R. Hoare*
>>
>>
>>
>>
>>
>> *From: *TLS  on behalf of Nimrod Aviram <
>> nimrod.avi...@gmail.com>
>> *Date: *Wednesday, September 1, 2021 at 15:58
>> *To: *"" 
>> *Cc: *Eylon Yogev , Ilan Komargodski <
>> ilanko...@gmail.com>, Benjamin Dowling , Eyal
>> Ronen 
>> *Subject: *[TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3
>>
>>
>>
>> (This note is also available on Github
>> <https://github.com/nimia/kdf_public#readme> for ease of reading.)
>>
>>
>>
>> This note identifies a possible security problem in the "Hybrid key
>> exchange in
>> TLS 1.3" document, stemming from how cryptographic secrets are combined.
>> In
>> short: constructions that concatenate secrets are vulnerable when the
>> underlying
>> hash function is not collision-resistant. We are unaware of a full attack
>> that leverages the underlying problem. However, we view this as an
>> opportunity
>> to defend-in-depth against such issues, while the document is not yet
>> finalized.
>> We propose a new construction that seems robust to this potential issue,
>> and we
>> are in the process of writing a technical report that includes a full
>> security
>> proof.
>>
>> # Concatenating Secrets May Be Dangerous
>>
>> The APOP attack (see appendix for a brief description) demonstrates that
>> concatenating secrets to potentially attacker-controlled input might be
>> dangerous. Currently, the "Hybrid key exchange in TLS 1.3" document uses
>> secret
>> concatenation as the preferred way to combine secrets. (This was an
>> understandable design choice given how little this issue has been
>> studied.)
>>
>> We recommend a defense-in-depth approach against this potential issue. We
>> should
>> not concede to an attacker even the ability to cause a collision in an
>> internal
>> state of the key schedule. Moreover, this part of TLS is likely
>> particularly
>> amenable to ossification: Whatever we standardize will likely persist for
>> 5-10
>> years. (We do note that TLS mixes in the client and server nonces, so
>> additional
>> offensive techniques would be required to exploit this for a full attack.)
>>
>> We note that concatenation is also used in the "TLS 1.3 Extended Key
>> Schedule"
>> document.
>>
>> # Our proposed construction
>>
>> We have identified an alternative construction that we believe could
>> provide
>> defense-in-depth against this issue. We are in the process of writing a
>> technical report that includes a full security proof.
>> The required assumptions on the hash function appear to be much milder
>> than
>> collision resistance; instead, we likely only need
>> multi-preimage-resistance:
>> Essentially, requiring only that computing preimages for multiple images
>> is
>> hard.
>>
>> The construction is:
>> combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2),
>> data=1||F(k1)))
>> where || denotes concatenation, H denotes the underlying hash function,
>> and:
>> H1(k) = H('derive1' || k)
>> H2(k) = H('derive2' || k)
>> F is defined as follows:
>> Let m denote the input to F. We split m into blocks, according to the
>> block size
>> of H:
>> m = m1||m2||...||mn
>> Let j~=3 denote an “expanding factor” (the value chosen for j in practice
>> depends on how strong an assumption we want to rely on; we expect 3 to be
>> enough).
>> Then
>> F(m) =
>> H(0||m1)||H(1||m1)||...||H(j-1||m1)||H(0||m2)||H(1||m2)||...||H(j-1||m2)||H(0||mn)||H(1||mn)||...||H(j-1||mn)
>>
>> This construction is cheap to calculate and would be used only in the key
>> schedule, which is not

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

[Nimrod Aviram]

Hi Dan,

The assumptions for the ETSI proofs don't match the scenario we're
considering, but are rather stronger.
We assume the adversary gets to control some part of the secret
concatenation (e.g. when KEMs are used), and that honest parties may re-use
secrets (e.g. when static ECDH is used).
The ETSI proofs model HKDF either as a random oracle, or as a weakly secure
KDF.

In particular, they use two assumptions to model HKDF in the ETSI
constructions:

1. HKDF is modelled as a random oracle, which is inherently
collision-resistant. Specifically, each random oracle takes a query tuple
(s, r, c), where s is keying material, r is salt and c is context values,
and returns a random bit string if the query is not entirely equal to a
previous query value. The HKDF paper does not claim security in the
presence of attacker-controlled entropy [1], so this assumption seems
rather strong.

2. HKDF is modelled as a weakly secure KDF. In this assumption, both the
secret value s and the salt r are randomly selected, and (r,a) is given to
the adversary, where a is a description of the secret space that s is drawn
from. The adversary is allowed to specify a context value c and an output
length, and has to distinguish the output from the KDF from a random string
of the same length. The adversary is not allowed to query the KDF more than
once. Note that for the purposes of Cascade KDF, the secret value s is the
concatenation of all secrets output from the hybrid KEM, and they seem to
assume one of which is IND-CPA secure.

In either case, the adversary is not able to inject KEM ciphertexts or
secrets.

(I am mostly relaying here an explanation by my colleague Ben Dowling,
thanks Ben :-)
best,
Nimrod

[1] https://eprint.iacr.org/2010/264.pdf, starting from the bottom of page
8.


On Thu, 2 Sept 2021 at 23:29, Dan Brown  wrote:

> Dear Nimrod and team:
>
> How does your concern compare to Campagna and Petcher’s report
>
> https://eprint.iacr.org/2020/1364
>
> which has security proofs for concatenation-based KDF?
>
> (Maybe a detailed discussion 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
> Ronen 
> *Subject:* [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3
>
>
>
> (This note is also available on Github
> <https://urldefense.com/v3/__https:/github.com/nimia/kdf_public*readme__;Iw!!COg3wY07Hnb7!5OmIbV58bG3VGtwYOI1gL73xJz_hfm6BqfyKoWRKT25K7-yOj4ziPAfkU9BCeC0$>
> for ease of reading.)
>
>
>
> This note identifies a possible security problem in the "Hybrid key
> exchange in
> TLS 1.3" document, stemming from how cryptographic secrets are combined. In
> short: constructions that concatenate secrets are vulnerable when the
> underlying
> hash function is not collision-resistant. We are unaware of a full attack
> that leverages the underlying problem. However, we view this as an
> opportunity
> to defend-in-depth against such issues, while the document is not yet
> finalized.
> We propose a new construction that seems robust to this potential issue,
> and we
> are in the process of writing a technical report that includes a full
> security
> proof.
>
> # Concatenating Secrets May Be Dangerous
>
> The APOP attack (see appendix for a brief description) demonstrates that
> concatenating secrets to potentially attacker-controlled input might be
> dangerous. Currently, the "Hybrid key exchange in TLS 1.3" document uses
> secret
> concatenation as the preferred way to combine secrets. (This was an
> understandable design choice given how little this issue has been studied.)
>
> We recommend a defense-in-depth approach against this potential issue. We
> should
> not concede to an attacker even the ability to cause a collision in an
> internal
> state of the key schedule. Moreover, this part of TLS is likely
> particularly
> amenable to ossification: Whatever we standardize will likely persist for
> 5-10
> years. (We do note that TLS mixes in the client and server nonces, so
> additional
> offensive techniques would be required to exploit this for a full attack.)
>
> We note that concatenation is also used in the "TLS 1.3 Extended Key
> Schedule"
> document.
>
> # Our proposed construction
>
> We have identified an alternative construction that we believe could
> provide
> defense-in-depth against this issue. We are in the process of writing a
> technical report that includes a full security proof.
> The required assumptions on the hash function appear to be much milder than
> collision resistance; instead, we likely only need
> mul

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

[Nimrod Aviram]

The APOP attack demonstrates that concatenating secrets may be dangerous,
as a general cryptographic practice.
As to the TLS KDF, if future SHA256 cryptanalysis results in collisions, an
attacker that can establish multiple PSKs of their choice with another
party can cause two sessions with two different PSKs to share the same
early_secret. If the other party reuses ECDH(E) values, the attacker can
also cause the handshake_secret to be identical.
This likely violates the security proof for TLS 1.3, in and of itself.
A similar violation of the security guarantee seems to arise when using
hybrid key exchange with a PQ KEM.

Or if that's what you're asking: As we write, we are unaware of a way to
apply the APOP attack to the TLS KDF.
We view this as an opportunity to defend-in-depth against such issues,
while the document is not yet finalized.


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 there
> are obviously no deficiencies.*
>
> *The other is to make it so complex there are no obvious deficiencies.*
>
> *
>   
>  -
> C. A. R. Hoare*
>
>
>
>
>
> *From: *TLS  on behalf of Nimrod Aviram <
> nimrod.avi...@gmail.com>
> *Date: *Wednesday, September 1, 2021 at 15:58
> *To: *"" 
> *Cc: *Eylon Yogev , Ilan Komargodski <
> ilanko...@gmail.com>, Benjamin Dowling , Eyal
> Ronen 
> *Subject: *[TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3
>
>
>
> (This note is also available on Github
> <https://github.com/nimia/kdf_public#readme> for ease of reading.)
>
>
>
> This note identifies a possible security problem in the "Hybrid key
> exchange in
> TLS 1.3" document, stemming from how cryptographic secrets are combined. In
> short: constructions that concatenate secrets are vulnerable when the
> underlying
> hash function is not collision-resistant. We are unaware of a full attack
> that leverages the underlying problem. However, we view this as an
> opportunity
> to defend-in-depth against such issues, while the document is not yet
> finalized.
> We propose a new construction that seems robust to this potential issue,
> and we
> are in the process of writing a technical report that includes a full
> security
> proof.
>
> # Concatenating Secrets May Be Dangerous
>
> The APOP attack (see appendix for a brief description) demonstrates that
> concatenating secrets to potentially attacker-controlled input might be
> dangerous. Currently, the "Hybrid key exchange in TLS 1.3" document uses
> secret
> concatenation as the preferred way to combine secrets. (This was an
> understandable design choice given how little this issue has been studied.)
>
> We recommend a defense-in-depth approach against this potential issue. We
> should
> not concede to an attacker even the ability to cause a collision in an
> internal
> state of the key schedule. Moreover, this part of TLS is likely
> particularly
> amenable to ossification: Whatever we standardize will likely persist for
> 5-10
> years. (We do note that TLS mixes in the client and server nonces, so
> additional
> offensive techniques would be required to exploit this for a full attack.)
>
> We note that concatenation is also used in the "TLS 1.3 Extended Key
> Schedule"
> document.
>
> # Our proposed construction
>
> We have identified an alternative construction that we believe could
> provide
> defense-in-depth against this issue. We are in the process of writing a
> technical report that includes a full security proof.
> The required assumptions on the hash function appear to be much milder than
> collision resistance; instead, we likely only need
> multi-preimage-resistance:
> Essentially, requiring only that computing preimages for multiple images is
> hard.
>
> The construction is:
> combined_key = H(HMAC(key=H1(k1), data=2||F(k2)) xor HMAC(key=H2(k2),
> data=1||F(k1)))
> where || denotes concatenation, H denotes the underlying hash function,
> and:
> H1(k) = H('derive1' || k)
> H2(k) = H('derive2' || k)
> F is defined as follows:
> Let m denote the input to F. We split m into blocks, according to the
> block size
> of H:
> m = m1||m2||...||mn
> Let j~=3 denote an “expanding factor” (the value chosen for j in practice
> depends on how strong an assumption we want to rely on; we expect 3 to be
> enough).
> Then
> F(m) =
> H(0||m1)||H(1||m1)||...||H(j-1||m1)||H(0||m2)||H(1||m2)||...||H

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

[Nimrod Aviram]

e
because
it demonstrates the attack well. Broadly, in APOP the challenger sends a
challenge, and the responder needs to respond with:
MD5(challenge || password)
where || denotes concatenation.

The attacker wants to e.g. test whether the password starts with 'a'. They
pick an MD5 collision x, y such that MD5(x) = MD5(y) and both x and y end
with
'a'. They wait for the client to connect in two different sessions, and send
x[:-1] and y[:-1] as the challenges, where [:-1] denotes removing the last
byte
from a string. If the password starts with 'a', and the MD5 blocks align,
then
the response will be the same for both challenges. The attacker can
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 MD5-based
challenge-response authentication. Leurent, Gaetan.

[2] Practical Password Recovery on an MD5 Challenge and Response.
Sasaki, Yu and Yamamoto, Go and Aoki, Kazumaro.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

Hi Rene,

We are agreed on the strategy for mitigating Raccoon. We seem to disagree
on how easy it is to implement in constant time.
I'd like to understand your position better: Are you OK with implementers
reusing secret DH values without the above mitigation?
If not, it sounds like you suggest describing this mitigation strategy in
an RFC, and requiring it when DH secrets are reused, in the same vein the
Bleichenbacher mitigation is required. Is this your preferred course of
action?
If this is not your preferred course of action, could you please describe
what is? If you suggest leaving the situation as-is, I'd appreciate it if
you could please state so, so I could better understand your position.

best,
Nimrod


On Fri, 27 Aug 2021 at 20:50, Rene Struik  wrote:

> Hi Nimrod:
>
> All the quoted Raccoon attack (of which you are a coauthor) does is
> highlight that poorly designed post-processing of a shared key
> (variable-size bit-string representation) could be used to extract secret
> info by solving an instance of the hidden number problem.
>
> Let us not over-state the importance of this attack, though: the attack
> (for those who care) is easy to mitigate, e.g., as follows:
> a) Let K be the derived shared key; let K1, ..., Kt be a set of keys
> including this key K (where this set has keys of byte-size L-1 and L,
> respectively, say L-1 once and L for all others);
> b) Compute kj:=kdf(Kj) for all j=1,...,t;
> c) Select select kj, where Kj corresponds to K.
> Note: (if t:=2) if K has size L-1, set, e.g., K':=K xor random L-byte
> offset; if K has size L, set, e.g., K':=trunc_{L-1}(K) xor random
> {L-1}-byte offset.
>
> Contrary to what you claim, this seems to be easy to implement in
> constant-time, however if not, this would still most likely thwart the
> attack (since one cannot apply the HNP any more {since one has to guess
> which leaks are real (correct j value) and which are spurious).
>
> Bottom line (for me) is that one should not use attacks that are easy to
> mitigate as a pretext for deprecating things. There may be other reasons
> that have more merit, but the draft in the adoption call does not provide
> any of this. Hence, my feedback to reject the individual draft as it stands
> (based on lack of proper detail).
>
> As Peter Gutmann already said in the thread, what problem is one trying to
> solve here???
>
> Contrary to what Filippo suggests, I do think one should query why
> implementors do not heed advice that has been around for a long time (in
> that case, they should rightfully assume some blame). Implementors have
> duty of care too.
>
> [my email of Aug 13, 2021, 9.58am EDT]
> I think this document should absolutely *not* be adopted, without
> providing far more technical justification. The quoted Raccoon attack is an
> easy to mitigate attack (which has nothing to do with finite field groups,
> just with poor design choices of postprocessing, where one uses
> variable-size integer representations for a key). There are also good
> reasons to have key exchanges where one of the parties has a static key,
> whether ecc-based or ff-based (e.g., sni, opaque), 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 "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 that
> it is constant time, even for variable-length secrets. This is possible, at
> least in principle, but I'm not aware of any implementation that does it or
> plans to do it, and neither of any document that describes the complex
> strategy for achieving this.
>
>
> On Fri, 27 Aug 2021 at 12:26, Filippo Valsorda 
> wrote:
>
>> 2021-08-27 05:08 GMT+02:00 Joseph Salowey :
>>
>> Thanks for all the discussion on this topic.  There are several modes
>> that TLS 1.2 can operate with respect to DH.  Below is a proposal on
>> cases to merge some of the cases covered by this draft into the obsolete
>> keyex draft.  I'd like to see if there is some consensus to make this
>> change before we adopt it into the working group.
>>
>> 1. static-static where both client and server have DH certificates with
>> long term keys.  I think we have general consensus that this mode should be
>> a must not.  To deprecate this mode I think we need to state that clients
>> MUST NOT use certificates of type rsa_fixed_dh and dsa_fixed_dh and
>> server MUST NOT request them.  Would the wor

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

[Nimrod Aviram]

> 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 that
it is constant time, even for variable-length secrets. This is possible, at
least in principle, but I'm not aware of any implementation that does it or
plans to do it, and neither of any document that describes the complex
strategy for achieving this.


On Fri, 27 Aug 2021 at 12:26, Filippo Valsorda 
wrote:

> 2021-08-27 05:08 GMT+02:00 Joseph Salowey :
>
> Thanks for all the discussion on this topic.  There are several modes that
> TLS 1.2 can operate with respect to DH.  Below is a proposal on cases to
> merge some of the cases covered by this draft into the obsolete keyex
> draft.  I'd like to see if there is some consensus to make this change
> before we adopt it into the working group.
>
> 1. static-static where both client and server have DH certificates with
> long term keys.  I think we have general consensus that this mode should be
> a must not.  To deprecate this mode I think we need to state that clients
> MUST NOT use certificates of type rsa_fixed_dh and dsa_fixed_dh and
> server MUST NOT request them.  Would the working group support merging this
> guidance into the obsolete keyex draft?
>
> 2. ephemeral-static where the client uses an ephemeral key and the server
> uses a long term key.  This mode does not provide forward secrecy.  I'm not
> sure we have reached consensus on how far to deprecate this option.  Would
> the working group support MUST NOT use these ciphersuites unless forward
> secrecy does not matter for your use case and any implementation guidance
> provided to avoid weaknesses is followed?
>
>
> The implementation guidance to avoid weaknesses in any ephemeral-static
> exchange is "don't get anything wrong, anything at all, all the way down to
> your field arithmetic libraries". I don't think that's a workable
> recommendation, and I believe we should deprecate modes that are so unsafe
> to implement.
>
> 3. ephemeral-ephemeral  - I think these are already covered in the
> obsolete keyex draft.
>
> Thanks,
>
> Joe
>
> On Sun, Aug 22, 2021 at 9:32 PM Carrick Bartle 
> wrote:
>
> >   which is a main reason cited for deprecating RSA
> in draft-aviram-tls-deprecate-obsolete-kex.
>
> Have the authors look at Post-Quantum KEMs?
>
>
> I'm not sure why PQ KEMs are relevant here.
>
>
> On Aug 17, 2021, at 10:41 AM, Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
> >  Regardless of the Raccoon attack, the static DH and ECDH ciphersuites
> do not provide
> >  forward secrecy,
>
> Unless you use semi-static exchange, which in many cases makes sense.
>
> >   which is a main reason cited for deprecating RSA
> in draft-aviram-tls-deprecate-obsolete-kex.
>
> Have the authors look at Post-Quantum KEMs?
>
> >  Do you object to just the citation of the Raccoon attack or do you also
> feel that we
> >  should keep these ciphersuites that do not provide forward secrecy
> around?
>
> I think these suites should stay around.
>
> While static-static indeed do not provide forward secrecy (and many of us
> – though not everybody! – carry for that), static-ephemeral DH and ECDH are
> perfectly fine from that point of view.
>
>
>
> On Fri, Aug 13, 2021 at 10:20 AM Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
>
> I agree with Rene’s points.
>
> --
> Regards,
> Uri
>
>
>
> *From: *TLS  on behalf of Rene Struik <
> rstruik@gmail.com>
> *Date: *Friday, August 13, 2021 at 09:58
> Dear colleagues:
>
> I think this document should absolutely *not* be adopted, without
> providing far more technical justification. The quoted Raccoon attack is an
> easy to mitigate attack (which has nothing to do with finite field groups,
> just with poor design choices of postprocessing, where one uses
> variable-size integer representations for a key). There are also good
> reasons to have key exchanges where one of the parties has a static key,
> whether ecc-based or ff-based (e.g., sni, opaque), for which secure
> implementations are known. No detail is provided and that alone should be
> sufficient reason to not adopt.
>
> Rene
>
> On 2021-07-29 5:50 p.m., Joseph Salowey wrote:
>
> This is a working group call for adoption for Deprecating FFDH(E)
> Ciphersuites in TLS (draft-bartle-tls-deprecate-ffdhe-00
> ). We
> had a presentation for this draft at the IETF 110 meeting and since it is
> a similar topic to the key exchange deprecation draft the chairs want to
> get a sense if the working group wants to adopt this draft (perhaps the
> drafts could be merged if both move forward).  Please review the draft and
> post your comments to the list by Friday, August 13, 2021.
>
> Thanks,
>
> The TLS chairs
>
>
>
> 

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

[Nimrod Aviram]

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 server uses a well-known, safe prime group
of at least 2048 bits (well-known might mean "from RFC 7919 plus the
built-in Postfix group", or other reasonable definitions).
- Clients may connect when the server uses a custom safe prime group of at
least 2048 bits, if the client verifies that the prime is safe.

The only point where we don't have consensus seems to be:
- For clients who choose to support FFDHE, when the server uses a custom
group of at least 2048 bits, and the client isn't willing to check
safe-primality, what should the client do?
(This only applies when FFDHE is chosen in practice, rather than ECDHE.)
My personal opinion is that both options - either allowing or forbidding
the client to connect - would be reasonable here.
Perhaps it'd be best to leave this specific point to the next WG meeting?
We can still make progress on the document in the meanwhile.

I'll also ask around if we can get some metrics, in general and
specifically pertaining to that last point.

thanks again everyone,
Nimrod

-- Forwarded message -
From: Viktor Dukhovni 
Date: Sat, 31 Jul 2021 at 19:12
Subject: Re: [TLS] Adoption call for Deprecating Obsolete Key Exchange
Methods in TLS
To: 


On Sat, Jul 31, 2021 at 12:57:39PM +, Peter Gutmann wrote:
> Viktor Dukhovni  writes:
>
> >I strongly doubt there's a non-negligible server population with weak
locally
> >generated groups.
>
> Would you care to rephrase that so we can make sure you're saying what we
> think you're saying in order to disagree with it?

OK, who goes around bothering to actually generate custom DH parameters,
and with what tools, but then does not use a "strong" (Sophie Germain)
prime?

The only weakness I expect to encounter is a deprecated size of e.g.
512, 768 or 1024 bits.  Clients can easily detect that and enforce a
floor, but of course still don't get to negotiate a minimum.

Clients also don't get to negotiate the size of the server's RSA public
key, or as you mentioned various other ways for the server to not screw
up.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Deprecating FFDHE + RSA Key Exchange

[Nimrod Aviram]

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/web, both key exchange methods have been superseded
by ECDH. Browser support for FFDHE has been entirely removed IIUC, so
formally deprecating FFDHE should not be a problem (right?). Are there any
reasons to avoid deprecating FFDHE and RSA on the open Internet?
2. On local networks, deprecating both key exchange methods may leave some
endpoints without any key exchange algorithms. Could you please give
feedback on the following:
a. Is the number of such endpoints large enough that we shouldn’t deprecate
these methods?
b. If the answer to the above is yes, what would be a good plan/timeline to
deprecate them?

We could also consider limiting FFDHE to well-known groups of at least 2048
bits, with fully ephemeral secrets. But this would likely cause enough
interoperability problems that we might as well deprecate it fully, right?

thanks,
Nimrod
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

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't find the
> repository for the document.
> Could you please point me to it?
>
> best,
> Nimrod
>
>
> On Thu, 17 Sep 2020 at 17:12, Douglas Stebila  wrote:
>
>> Given that all the finalists and alternate candidates have fixed
>> length shared secrets, and your observations on the potential for
>> timing attacks, I'm fine with dealing with only fixed length secrets,
>> removing the paragraph discussing the possibility for variable-length
>> shared secrets from the TLS 1.3 hybrid KEX draft, and adding a 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 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 broad terms, when the secret is longer, the hash
>> > function may need to process more blocks internally. In some unfortunate
>> > circumstances, this has led to timing attacks, e.g. Lucky Thirteen [2]
>> > and the newly-disclosed Raccoon Attack [3]. To be clear, we are not
>> > aware of any attack on the proposed standard. Rather, we view this as
>> > an opportunity to defend-in-depth against such attacks, while work on
>> > the standard is in progress.
>> >
>> > Our proposal is to add language to the RFC explaining that
>> variable-length
>> > secrets may enable such attacks, and should therefore be avoided when
>> > possible.  Currently, the language seems to allow for variable-length
>> > secrets, should the need arise:
>> > "Variable-length shared secrets ... if it is envisioned that this
>> specification
>> > be used with algorithms which do not have fixed-length shared secrets
>> ..."
>> >
>> > We also note that a related RFC exists, "Hybrid Post-Quantum Key
>> > Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2"
>> > [4]. However, that RFC apparently only uses BIKE, Kyber or SIKE as the
>> > PQ KEM. To our knowledge, all three KEMs have fixed-length secrets. It
>> > may be prudent to add cautionary language to that document as well,
>> > in case other KEMs are used in the future.
>> >
>> > Kind regards,
>> > The Raccoon Team
>> >
>> > [1]
>> https://www.ietf.org/id/draft-ietf-tls-hybrid-design-00.html#name-open-questions
>> > [2] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6547131
>> > [3] https://raccoon-attack.com/
>> > [4]
>> https://tools.ietf.org/id/draft-campagna-tls-bike-sike-hybrid-05.html#name-key-exchange-algorithms
>> >
>> >
>> > ___
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

Sounds good to me.
I'm happy to send a PR making these changes, but couldn't find the
repository for the document.
Could you please point me to it?

best,
Nimrod


On Thu, 17 Sep 2020 at 17:12, Douglas Stebila  wrote:

> Given that all the finalists and alternate candidates have fixed
> length shared secrets, and your observations on the potential for
> timing attacks, I'm fine with dealing with only fixed length secrets,
> removing the paragraph discussing the possibility for variable-length
> shared secrets from the TLS 1.3 hybrid KEX draft, and adding a 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 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 broad terms, when the secret is longer, the hash
> > function may need to process more blocks internally. In some unfortunate
> > circumstances, this has led to timing attacks, e.g. Lucky Thirteen [2]
> > and the newly-disclosed Raccoon Attack [3]. To be clear, we are not
> > aware of any attack on the proposed standard. Rather, we view this as
> > an opportunity to defend-in-depth against such attacks, while work on
> > the standard is in progress.
> >
> > Our proposal is to add language to the RFC explaining that
> variable-length
> > secrets may enable such attacks, and should therefore be avoided when
> > possible.  Currently, the language seems to allow for variable-length
> > secrets, should the need arise:
> > "Variable-length shared secrets ... if it is envisioned that this
> specification
> > be used with algorithms which do not have fixed-length shared secrets
> ..."
> >
> > We also note that a related RFC exists, "Hybrid Post-Quantum Key
> > Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2"
> > [4]. However, that RFC apparently only uses BIKE, Kyber or SIKE as the
> > PQ KEM. To our knowledge, all three KEMs have fixed-length secrets. It
> > may be prudent to add cautionary language to that document as well,
> > in case other KEMs are used in the future.
> >
> > Kind regards,
> > The Raccoon Team
> >
> > [1]
> https://www.ietf.org/id/draft-ietf-tls-hybrid-design-00.html#name-open-questions
> > [2] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6547131
> > [3] https://raccoon-attack.com/
> > [4]
> https://tools.ietf.org/id/draft-campagna-tls-bike-sike-hybrid-05.html#name-key-exchange-algorithms
> >
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

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 broad terms, when the secret is longer, the hash
function may need to process more blocks internally. In some unfortunate
circumstances, this has led to timing attacks, e.g. Lucky Thirteen [2]
and the newly-disclosed Raccoon Attack [3]. To be clear, we are not
aware of any attack on the proposed standard. Rather, we view this as
an opportunity to defend-in-depth against such attacks, while work on
the standard is in progress.

Our proposal is to add language to the RFC explaining that variable-length
secrets may enable such attacks, and should therefore be avoided when
possible.  Currently, the language seems to allow for variable-length
secrets, should the need arise:
"Variable-length shared secrets ... if it is envisioned that this
specification
be used with algorithms which do not have fixed-length shared secrets ..."

We also note that a related RFC exists, "Hybrid Post-Quantum Key
Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2"
[4]. However, that RFC apparently only uses BIKE, Kyber or SIKE as the
PQ KEM. To our knowledge, all three KEMs have fixed-length secrets. It
may be prudent to add cautionary language to that document as well,
in case other KEMs are used in the future.

Kind regards,
The Raccoon Team

[1]
https://www.ietf.org/id/draft-ietf-tls-hybrid-design-00.html#name-open-questions
[2] https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6547131
[3] https://raccoon-attack.com/
[4]
https://tools.ietf.org/id/draft-campagna-tls-bike-sike-hybrid-05.html#name-key-exchange-algorithms
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

Hi Nick, thanks!

I sent a PR here:
https://github.com/tlswg/tls-subcerts/pull/60

best wishes,
Nimrod


On Fri, 20 Mar 2020 at 20:45, Nick Sullivan  wrote:

> Hi Nimrod,
>
> This is a working group document, so it's open to comments and suggestions
> from anyone in the IETF community. 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 your preference for option 1.
>> Would it help if I contribute a draft of the new text for the security
>> considerations section?
>>
>> best wishes,
>> Nimrod
>>
>>
>> On Fri, 20 Mar 2020 at 18:57, Nick Sullivan  wrote:
>>
>>>
>>>
>>> On Fri, Mar 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
>>>> clients (or all of them?) support ephemeral key exchange in TLS. So would
>>>> it be possible to improve the state-of-the-art by forbidding TLS-RSA and
>>>> demanding correct keyUsage, at least in such high-profile scenarios?
>>>>
>>>
>>> This doesn't stop the attack, it just reduces the probability that a new
>>> oracle will be exploitable in servers that implement DCs. If the oracle
>>> exists in existing legacy servers where the cert is used, it doesn't matter
>>> what DC-enabled servers do. Removing support for TLS-RSA in TLS 1.2 is a
>>> valid TLS policy choice for today's age, but enforcing it in the protocol
>>> document doesn't improve the security versus known attacks like DROWN.
>>> Requiring EC keys for DC-enabled certificates is also an artificial
>>> limitation that should be avoided -- not all CAs support EC certs and not
>>> all software supports EC code.
>>>
>>> What you really want is to prevent keys from being used across different
>>> contexts. I see two options for this:
>>>
>>> 1) Add strong wording in the security considerations section about how
>>> it is dangerous to use the same key in different contexts. Advise
>>> implementers to use DC-enabled certificates only for signing DCs, not for
>>> terminating TLS or SSL -- if their software allows it.
>>> 2) Enforce on the client-side that DC-enabled certificates can only be
>>> used for DC handshakes. This option prevents DC certificates from being
>>> used in an DC-capable server by DC-enabled clients, but it doesn't prevent
>>> the certificate from being deployed on legacy services exposing an oracle.
>>> The downside of this restriction is that it adds complexity for server
>>> implementations (need the ability to load certificates dynamically based on
>>> client hello), and operators (two certificates need to be managed per
>>> service, not just one).
>>>
>>> My preference is for 1)
>>>
>>>
>>>> Assuming this is not possible, we agree with your conclusion. It looks
>>>> like the second alternative is more effective - to discourage the use
>>>> of DC-enabled certificates in contexts where an oracle may be present.
>>>> One possible defense-in-depth is to use DC only with EC certificates.
>>>>
>>>> best wishes,
>>>> Robert, Juraj and Nimrod
>>>>
>>>> -- Forwarded message -
>>>> From: Nick Sullivan 
>>>> Date: Fri, 20 Mar 2020 at 01:21
>>>> Subject: Re: [TLS] Delegated Credentials: The impact of a hypothetical
>>>> Bleichenbacher attack
>>>> To: Nimrod Aviram 
>>>> Cc:  , Juraj Somorovsky <
>>>> juraj.somorov...@upb.de>
>>>>
>>>>
>>>> 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 writing this specification. The mitigation
>>>> you proposed in option 1 (requiring the keyEncipherment KeyUsage to
>>>> not be present on DC-capable certificates) is sound in theory, but unlikely
>>>> to be effective in p

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

[Nimrod Aviram]

Hi Nick,

Thank you again for the detailed explanation.
We agree with your preference for option 1.
Would it help if I contribute a draft of the new text for the security
considerations section?

best wishes,
Nimrod


On Fri, 20 Mar 2020 at 18:57, Nick Sullivan  wrote:

>
>
> On Fri, Mar 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
>> clients (or all of them?) support ephemeral key exchange in TLS. So would
>> it be possible to improve the state-of-the-art by forbidding TLS-RSA and
>> demanding correct keyUsage, at least in such high-profile scenarios?
>>
>
> This doesn't stop the attack, it just reduces the probability that a new
> oracle will be exploitable in servers that implement DCs. If the oracle
> exists in existing legacy servers where the cert is used, it doesn't matter
> what DC-enabled servers do. Removing support for TLS-RSA in TLS 1.2 is a
> valid TLS policy choice for today's age, but enforcing it in the protocol
> document doesn't improve the security versus known attacks like DROWN.
> Requiring EC keys for DC-enabled certificates is also an artificial
> limitation that should be avoided -- not all CAs support EC certs and not
> all software supports EC code.
>
> What you really want is to prevent keys from being used across different
> contexts. I see two options for this:
>
> 1) Add strong wording in the security considerations section about how it
> is dangerous to use the same key in different contexts. Advise implementers
> to use DC-enabled certificates only for signing DCs, not for terminating
> TLS or SSL -- if their software allows it.
> 2) Enforce on the client-side that DC-enabled certificates can only be
> used for DC handshakes. This option prevents DC certificates from being
> used in an DC-capable server by DC-enabled clients, but it doesn't prevent
> the certificate from being deployed on legacy services exposing an oracle.
> The downside of this restriction is that it adds complexity for server
> implementations (need the ability to load certificates dynamically based on
> client hello), and operators (two certificates need to be managed per
> service, not just one).
>
> My preference is for 1)
>
>
>> Assuming this is not possible, we agree with your conclusion. It looks
>> like the second alternative is more effective - to discourage the use of
>> DC-enabled certificates in contexts where an oracle may be present. One
>> possible defense-in-depth is to use DC only with EC certificates.
>>
>> best wishes,
>> Robert, Juraj and Nimrod
>>
>> -- Forwarded message -
>> From: Nick Sullivan 
>> Date: Fri, 20 Mar 2020 at 01:21
>> Subject: Re: [TLS] Delegated Credentials: The impact of a hypothetical
>> Bleichenbacher attack
>> To: Nimrod Aviram 
>> Cc:  , Juraj Somorovsky <
>> juraj.somorov...@upb.de>
>>
>>
>> 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 writing this specification. The mitigation you
>> proposed in option 1 (requiring the keyEncipherment KeyUsage to not be
>> present on DC-capable certificates) is sound in theory, but unlikely to be
>> effective in practice since many servers (including many of the ones
>> identified in DROWN) ignore the requirement that keyEncipherment
>> KeyUsage is present. Stating this requirement in the text of this document
>> is unlikely to prevent existing oracles from being leveraged if the
>> certificate is used in multiple contexts and is likely to introduce
>> complexity on the CA side, so I'm inclined not to include this requirement.
>> I'd be happy to hear an argument to the contrary, though.
>>
>> I'm more inclined to incorporate some text into the security
>> considerations to discourage the use of DC-enabled certificates in
>> contexts where an oracle may be present. Servers may even go as far as to
>> use a different certificate for DC-enabled handshakes vs regular handshakes
>> --- although very few servers support this sort of dynamic certificate
>> switching in practice so it would be difficult to make a hard requirement
>> here.
>>
>> Nick
>>
>> On Thu, Mar 19, 2020 at 6:08 AM Nimrod Aviram 
>> wrote:
>>
>>> Hi folks,
>>>
>>>

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

[Nimrod Aviram]

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 clients
(or all of them?) support ephemeral key exchange in TLS. So would it be
possible to improve the state-of-the-art by forbidding TLS-RSA and
demanding correct keyUsage, at least in such high-profile scenarios?

Assuming this is not possible, we agree with your conclusion. It looks like
the second alternative is more effective - to discourage the use of
DC-enabled certificates in contexts where an oracle may be present. One
possible defense-in-depth is to use DC only with EC certificates.

best wishes,
Robert, Juraj and Nimrod

-- Forwarded message -
From: Nick Sullivan 
Date: Fri, 20 Mar 2020 at 01:21
Subject: Re: [TLS] Delegated Credentials: The impact of a hypothetical
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 writing this specification. The mitigation you
proposed in option 1 (requiring the keyEncipherment KeyUsage to not be
present on DC-capable certificates) is sound in theory, but unlikely to be
effective in practice since many servers (including many of the ones
identified in DROWN) ignore the requirement that keyEncipherment KeyUsage
is present. Stating this requirement in the text of this document is
unlikely to prevent existing oracles from being leveraged if the
certificate is used in multiple contexts and is likely to introduce
complexity on the CA side, so I'm inclined not to include this requirement.
I'd be happy to hear an argument to the contrary, though.

I'm more inclined to incorporate some text into the security considerations
to discourage the use of DC-enabled certificates in contexts where an
oracle may be present. Servers may even go as far as to use a different
certificate for DC-enabled handshakes vs regular handshakes --- although
very few servers support this sort of dynamic certificate switching in
practice so it would be difficult to make a hard requirement here.

Nick

On Thu, Mar 19, 2020 at 6:08 AM Nimrod Aviram 
wrote:

> 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 outdated protocols such as SSLv2 can be used to forge
>signatures for certificates that contain the keyEncipherment KeyUsage
>([RFC5280] section 4.2.1.3).  In order to prevent this type of cross-
>protocol attack, we define a new DelegationUsage extension to X.509
>that permits use of delegated credentials.  (See Section 4.2.)
> ```
>
> And Section 4.2:
> ```   The client MUST NOT accept a delegated credential unless
>the server's end-entity certificate satisfies the following criteria:
>
>*  It has the DelegationUsage extension.
>
>*  It has the digitalSignature KeyUsage (see the KeyUsage extension
>   defined in [RFC5280]).
> ```
>
> Currently, it seems the standard does not discuss the common situation
> where the certificate has both the digitalSignature and keyEncipherment
> KeyUsages.
> If we understand correctly, for such certificates using Bleichenbacher's
> attack to forge a single signature once over a delegated credential,
> would grant an attacker the equivalent of a man-in-the-middle certificate.
> Section 3 mentions SSLv2, and this protocol indeed enabled a severe form
> of Bleichenbacher's attack, but these attacks are not limited to older
> protocol versions.
> There have been implementations of TLS 1.2 vulnerable to Bleichenbacher's
> attack, even by server operators as competent as Facebook, as discussed
> e..g. in the ROBOT paper.
>
> Also, coming back to SSLv2, one problem at the time was that the
> recommended way to disable SSLv2 in OpenSSL did not in fact disable
> SSLv2. Administrators who followed the guidelines falsely assumed they
> had disabled the protocol, but had no way to verify it was disabled. It
> would be prudent to assume this may happen again, e.g. administrators will
> be unaware that they have obsolete or vulnerable cryptography enabled.
>
> In light of the above, we would recommend one of two alternatives:
> 1. Change the text in Section 4.2 to say "[the certificate] has the
> digitalSignature KeyUsage, and does not have the keyEncipherment KeyUsage.
> Furthermore, the certificate does not share its public key with any
> certificate that has the keyEncip

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

[Nimrod Aviram]

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 outdated protocols such as SSLv2 can be used to forge
   signatures for certificates that contain the keyEncipherment KeyUsage
   ([RFC5280] section 4.2.1.3).  In order to prevent this type of cross-
   protocol attack, we define a new DelegationUsage extension to X.509
   that permits use of delegated credentials.  (See Section 4.2.)
```

And Section 4.2:
```   The client MUST NOT accept a delegated credential unless
   the server's end-entity certificate satisfies the following criteria:

   *  It has the DelegationUsage extension.

   *  It has the digitalSignature KeyUsage (see the KeyUsage extension
  defined in [RFC5280]).
```

Currently, it seems the standard does not discuss the common situation
where the certificate has both the digitalSignature and keyEncipherment
KeyUsages.
If we understand correctly, for such certificates using Bleichenbacher's
attack to forge a single signature once over a delegated credential,
would grant an attacker the equivalent of a man-in-the-middle certificate.
Section 3 mentions SSLv2, and this protocol indeed enabled a severe form
of Bleichenbacher's attack, but these attacks are not limited to older
protocol versions.
There have been implementations of TLS 1.2 vulnerable to Bleichenbacher's
attack, even by server operators as competent as Facebook, as discussed
e.g. in the ROBOT paper.

Also, coming back to SSLv2, one problem at the time was that the
recommended way to disable SSLv2 in OpenSSL did not in fact disable
SSLv2. Administrators who followed the guidelines falsely assumed they
had disabled the protocol, but had no way to verify it was disabled. It
would be prudent to assume this may happen again, e.g. administrators will
be unaware that they have obsolete or vulnerable cryptography enabled.

In light of the above, we would recommend one of two alternatives:
1. Change the text in Section 4.2 to say "[the certificate] has the
digitalSignature KeyUsage, and does not have the keyEncipherment KeyUsage.
Furthermore, the certificate does not share its public key with any
certificate that has the keyEncipherment KeyUsage."
- or -
2. Add text in the Security Considerations Section explaining that:
2.1. The recommended way for server operators to defend in depth against
this type of attack is to use a certificate as in alternative 1 with
delegated credentials.
2.2. Absent that, server operators should be aware of this risk.

We would be happy to continue the discussion and help in any way.

best wishes,
Juraj, Robert and Nimrod
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls