[TLS] ECH AAD for HRR

[Stephen Farrell]

(Apologies for the acronym laden subject:-)

I'm more or less at the "code complete" stage of
implementing draft-13 incl. HRR. (If anyone wants
to try interop, for now please contact me, but I
should have a server up in a few days.) I'm sure
as usual I'll have gotten some details wrong, but
I wasn't clear about one thing:

- When sending the 2nd CH following HRR, the spec
calls for omitting the "enc" field of the ECH
extension ("enc" holds the sender's public HPKE
value that's re-used from the 1st CH).
- The AAD for that ECH encryption is the outer
CH with zeros replacing where the ciphertext will
go.
- I concluded that the sender's ECH public value
(the "enc" field) ought not be present in the
AAD in that case, as well as being omitted in
the ECH value, but it wasn't entirely clear to me
from the spec (and it'd work either way).

So my question is: did I get that right or not?

Thanks in advance,
S.



OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] ECH AAD for HRR

[David Benjamin]

That's right. The AAD and actual CH should be exactly the same, apart from
the payload being zeroed in place. You don't need to reserialize the
structure as a server, or serialize ClientHelloOuter twice as a client.

On Wed, Sep 1, 2021 at 1:01 PM Stephen Farrell 
wrote:

>
> (Apologies for the acronym laden subject:-)
>
> I'm more or less at the "code complete" stage of
> implementing draft-13 incl. HRR. (If anyone wants
> to try interop, for now please contact me, but I
> should have a server up in a few days.) I'm sure
> as usual I'll have gotten some details wrong, but
> I wasn't clear about one thing:
>
> - When sending the 2nd CH following HRR, the spec
> calls for omitting the "enc" field of the ECH
> extension ("enc" holds the sender's public HPKE
> value that's re-used from the 1st CH).
> - The AAD for that ECH encryption is the outer
> CH with zeros replacing where the ciphertext will
> go.
> - I concluded that the sender's ECH public value
> (the "enc" field) ought not be present in the
> AAD in that case, as well as being omitted in
> the ECH value, but it wasn't entirely clear to me
> from the spec (and it'd work either way).
>
> So my question is: did I get that right or not?
>
> Thanks in advance,
> S.
>
> ___
> 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] ECH AAD for HRR

[Christopher Patton]

Yup, that was my interpretation as well.

On Wed, Sep 1, 2021 at 10:14 AM David Benjamin 
wrote:

> That's right. The AAD and actual CH should be exactly the same, apart from
> the payload being zeroed in place. You don't need to reserialize the
> structure as a server, or serialize ClientHelloOuter twice as a client.
>
> On Wed, Sep 1, 2021 at 1:01 PM Stephen Farrell 
> wrote:
>
>>
>> (Apologies for the acronym laden subject:-)
>>
>> I'm more or less at the "code complete" stage of
>> implementing draft-13 incl. HRR. (If anyone wants
>> to try interop, for now please contact me, but I
>> should have a server up in a few days.) I'm sure
>> as usual I'll have gotten some details wrong, but
>> I wasn't clear about one thing:
>>
>> - When sending the 2nd CH following HRR, the spec
>> calls for omitting the "enc" field of the ECH
>> extension ("enc" holds the sender's public HPKE
>> value that's re-used from the 1st CH).
>> - The AAD for that ECH encryption is the outer
>> CH with zeros replacing where the ciphertext will
>> go.
>> - I concluded that the sender's ECH public value
>> (the "enc" field) ought not be present in the
>> AAD in that case, as well as being omitted in
>> the ECH value, but it wasn't entirely clear to me
>> from the spec (and it'd work either way).
>>
>> So my question is: did I get that right or not?
>>
>> Thanks in advance,
>> S.
>>
>> ___
>> 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] ECH AAD for HRR

[Stephen Farrell]

Great, thanks both

S

On 01/09/2021 19:04, Christopher Patton wrote:

Yup, that was my interpretation as well.

On Wed, Sep 1, 2021 at 10:14 AM David Benjamin 
wrote:


That's right. The AAD and actual CH should be exactly the same, apart from
the payload being zeroed in place. You don't need to reserialize the
structure as a server, or serialize ClientHelloOuter twice as a client.

On Wed, Sep 1, 2021 at 1:01 PM Stephen Farrell 
wrote:



(Apologies for the acronym laden subject:-)

I'm more or less at the "code complete" stage of
implementing draft-13 incl. HRR. (If anyone wants
to try interop, for now please contact me, but I
should have a server up in a few days.) I'm sure
as usual I'll have gotten some details wrong, but
I wasn't clear about one thing:

- When sending the 2nd CH following HRR, the spec
calls for omitting the "enc" field of the ECH
extension ("enc" holds the sender's public HPKE
value that's re-used from the 1st CH).
- The AAD for that ECH encryption is the outer
CH with zeros replacing where the ciphertext will
go.
- I concluded that the sender's ECH public value
(the "enc" field) ought not be present in the
AAD in that case, as well as being omitted in
the ECH value, but it wasn't entirely clear to me
from the spec (and it'd work either way).

So my question is: did I get that right or not?

Thanks in advance,
S.

___
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





OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

(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(ClientHello...ServerHello) is identical.
This leads to identical values for an actual key output of the key schedule,
Client-Handshake-Traffic-Secret (if the client reuses an ECDH(E) value, or
in a
hypothetical PQ TLS, which uses a KEM and the server chooses the
encapsulated
key).

We note that the full version of the HKDF paper explicitly disclaims
security in
the presence of attacker-controlled entropy. Also, note that by definition,
a
KEM allows one party to control the secret.

# Appendix: The APOP Attack

APOP is an old challenge-response protocol used in email, relevant here
because
it demonstrates the attack well

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

[Blumenthal, Uri - 0553 - MITLL]

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

Re: [TLS] ECH AAD for HRR

[Stephen Farrell]

Earlier, I said:

On 01/09/2021 18:00, Stephen Farrell wrote:

I should have a server up in a few days


I now have an ``openssl s_server`` that thinks it speaks
draft-13 running on draft-13.esni.defo.ie on port 8413
with the relevant ECHConfig published in DNS etc.

It'll probably crash and burn if someone tries to talk
to it, but happy to see that happen:-)

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls