[TLS] ECH-13 HRR Signal Derivation

[Dennis Jackson]

I have two questions about the transcript for the confirmation signal 
 
for HelloRetryRequests in ECH Draft 13:


1. Should ClientHelloInner1 be replaced with a message_hash message as 
in TLS?


2. Is the entire HelloRetryRequest (with overwritten placeholder value) 
included in the transcript or is the HRR only included up to the end of 
the placeholder value?


I had assumed 1. yes and 2. the entire HRR, but an off-list conversation 
left me unsure.


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

Re: [TLS] ECH-13 HRR Signal Derivation

[Christopher Wood]

On Thu, Sep 2, 2021, at 1:42 AM, Dennis Jackson wrote:
> I have two questions about the transcript for the confirmation signal 
> 
>  for HelloRetryRequests in ECH Draft 13: 
> 
> 1. Should ClientHelloInner1 be replaced with a message_hash message as in 
> TLS? 
> 
> 2. Is the entire HelloRetryRequest (with overwritten placeholder value) 
> included in the transcript or is the HRR only included up to the end of 
> the placeholder value? 
> 
> I had assumed 1. yes and 2. the entire HRR, but an off-list 
> conversation left me unsure. 

That matches my interpretation of the text, though I see why (1) is not all 
that clear. If others agree, would you mind filing an issue to help clarify?

Thanks,
Chris

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

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
>  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 a bottleneck for TLS performance.
>
> # Adding another layer to the TLS key schedule may also be problematic
>
> Another strategy for mixing secrets is to add the second secret to another
> layer
> of the TLS key schedule. This strategy is already u

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

[Dan Brown]

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 ; 
Benjamin Dowling ; Eyal Ronen 
Subject: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

 

(This note is also available on Github 

  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 a bottleneck for TLS performance.

# Adding another layer to the TLS key schedule may also be problematic

Another strategy for mixing secrets is to add the second secret to another layer
of the TLS key schedule. This strategy is already used to mix a PSK and an ECDHE
secret in TLS 1.3, as well as in AuthKEM, and it was also considered for the
Hybrid key exchange document. This strategy is vulnerable as well to collisions
in the underlying hash function, and we propose using one secure construction
for mixing secrets.

Consider a standard PSK+ECDHE TLS 1.3 handshake. Then 
handshake_secret = HKDF_Extract(IKM=ECDHE_secret, 
salt=Derive_Secret(early_secret)) 
early_secret = HKDF_Extract(IKM=PSK, salt=000) 
HKDF_Extract(IKM, salt) = HMAC(k=salt, data=IKM)

Therefore, early_secret = HMAC(k=000, data=PSK). 
Assume a non-collision-resistant hash function. Then 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.

Furthermore, 
Client_Handshake_Traffic_Secret = 
  HMAC(k=Handshake_Secret, data=Label||H(ClientHello...ServerHello)) 
If the attacker is the server, and the hash function allows for chosen-prefix
collisions, the attacker can choose two ServerHello messages such that for two
different ClientHello messages, H(C

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

[Blumenthal, Uri - 0553 - MITLL]

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

Date: Wednesday, September 1, 2021 at 15:58
To: "" 
Cc: Eylon Yogev , Ilan Komargodski , 
Benjamin Dowling , Eyal Ronen 
Subject: [TLS] Combining Secrets in Hybrid Key Exchange in TLS 1.3

 

(This note is also available on Github 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 a bottleneck for TLS performance.

# Adding another layer to the TLS key schedule may also be problematic

Another strategy for mixing secrets is to add the second secret to another layer
of the TLS key schedule. This strategy is already used to mix a PSK and an ECDHE
secret in TLS 1.3, as well as in AuthKEM, and it was also considered for the
Hybrid key exchange document. This strategy is vulnerable as well to

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

[David Benjamin]

Regarding the TLS 1.3 proof, I recall some discussion around
collision-resistance and PSK binders, with the result that we assume the
KDF is collision-resistant.

The paragraph that begins "The PSK binder value forms a binding" in
Appendix E.1:
https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1
The second paragraph in Appendix E.1.1:
https://datatracker.ietf.org/doc/html/rfc8446#appendix-E.1.1

Though I'm not as familiar with the details of all the proofs here and may
be misinterpreting this. Perhaps someone more familiar could chime in?

APOP doesn't seem relevant here because we're only concatenating
fixed-length values. (Indeed the whole construction in the draft assumes
each KEM's output size is fixed. Otherwise concatenation isn't injective.
This is a fine assumption because a KEM with variable-length output can
cause other troubles, per the Raccoon attack.) I think that means there is
no room to shift lengths around and try to target individual bytes.

Of course, that doesn't mean there aren't other attacks. But the proposed
construction is dramatically more involved than what's in the draft. If
it's the way to go, I think it should be motivated by a clear story for
what properties we assume from primitives across the protocol, rather than
a point fix to one part.

On Thu, Sep 2, 2021 at 4:32 PM Blumenthal, Uri - 0553 - MITLL <
u...@ll.mit.edu> 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
>  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

Re: [TLS] progressing draft-ietf-tls-md5-sha1-deprecate

[Sean Turner]

Just a reminder that sometime tomorrow I will ask for these PRs to be merged 
and a new version of the I-D be produced so that we can make progress.

spt

> On Aug 27, 2021, at 10:58, Sean Turner  wrote:
> 
> Hi! While address the IoT Directorate comments from IETF LC, some addition 
> comments have been received. I would like to address these new comments and 
> get the I-D in the hands of the iESG. There were three set of comments:
> 
> 1) Based on Daniels and David Benjamin’s reviews, the I-D is not as clear as 
> it could be. The end result of deprecating MD5 and SHA1 is that 
> signature_algorithms is always included; we should just say that. Chris has 
> submitted the following PR to address this:
> https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/19
> You will notice that the PR removes section 6 of the I-D; it is unclear how 
> much utility there is in updating the NOTE.
> 
> We are looking to merge this PR at the end of next week so please submit any 
> comments before then.
> 
> 2) Hannes suggested that we remove the 7525 updates text now that 7525bis is 
> underway. I submitted this issue to capture the issue:
> https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/17
> Peter Saint-Andre (one of the 7525bis authors) has filled the following issue 
> to incorporate the text from our I-D: 
> https://github.com/yaronf/I-D/issues/245
> Yaron has already merged the PR:
> https://github.com/yaronf/I-D/pull/248
> Chris has also kindly submitted this PR to remove the 7525bis-related text 
> from “our" I-D:
> https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/18
> 
> Again, we are looking to merge this PR at the end of next week so please 
> submit any comments before then.
> 
> 3) Hannes also had some editorial suggestions, that I created issues for:
> https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/16
> https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/15
> https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/issues/14
> These are addressed in this PR:
> https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/20
> 
> These ought to all be non-controversial, so we will merge them sometime next 
> week.
> 
> Cheers,
> spt (as Shepherd)

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

Re: [TLS] tls-flags: abort on malformed extension

[Sean Turner]

Seems pretty reasonable to me.

spt

> On Aug 28, 2021, at 16:36, Yoav Nir  wrote:
> 
> Hi.
> 
> To address Michael StJohns comment from 19-July, I submitted PR #12:
> 
> https://github.com/tlswg/tls-flags/pull/12
> 
> What is says is that any implementation receiving a malformed tls_flags 
> extensions should abort the handshake. The text provides a list (which I hope 
> is comprehensive) of all the ways this specific extension can be malformed. 
> 
> Please comment here or on the PR is this makes sense to everybody.
> 
> Yoav
> 
> ___
> 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] tls-flags: abort on malformed extension

[Rob Sayre]

On Sat, Aug 28, 2021 at 1:37 PM Yoav Nir  wrote:

>  The text provides a list (which I hope is comprehensive) of all the ways
> this specific extension can be malformed.
>

The text says "Such invalid tls_flags extensions include: ..."

While I don't oppose the edit, I don't understand why this WG continues to
specify this kind of thing in prose.

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