[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

[Felix Günther <[e-mail]>]

Hi Peter,

We discussed this among the [DOWLING] authors; Douglas asked me to chime 
in here as he's offline the next couple of days.

It is indeed true that the PRF-ODH assumption, as stated in [DOWLING] 
and https://ia.cr/2017/517, wouldn't be compatible when using the 
x-coordinate only, or with clamping. One needs to be a little bit more 
careful in these cases, disallowing the PRF-ODH adversary to make 
queries on trivially colliding points (e.g., by flipping signs, or 
adding small-order points).

This has been done for example in a paper about the security of 
Bluetooth by Fischlin (co-author of [DOWLING]) and Sanina [ 
https://ia.cr/2021/1597 ], where the x-coordinate is also used to derive 
keys. There, they adapted the PRF-ODH definition accordingly (Section 
4.1). We don't think that this makes the assumption less plausible, only 
a bit more tedious to define and deal with in the proofs.

Concretely for TLS 1.3, the reduction to sn-PRF-ODH for Theorem 5.2 in 
Game B.2 would perform the relevant collision checks upon a modified 
g^v' received by the partner session, and use the same uniform random 
string as in the test session for such collisions. (The session hash in 
later key derivation steps still ensures they'll derive independent keys.)
This matches the PRF-ODH assumption with the restricted modifications as 
mentioned above; the TLS proof then goes through as before.


As for the PQ3 protocol also brought up in this, from a
quick glance similar arguments seem to apply: the PRF-ODH reductions
already check whether "the same V" is received, hence the collision
check can be added there, too.


Hope this helps to clarify.  We plan to update the eprint version 
https://ia.cr/2020/1044 of [DOWLING] accordingly.  Let us know if you 
need more details.

Best,
Felix  (with Ben, Douglas, Marc)


On 2024-07-26 00:19 +0200, Peter C 
<Peter.C=[e-mail]> wrote:
> Douglas,
> 
>>> It's not exactly due to the point formats, at least for X25519.  The RFC 7748
>>> security considerations highlight that "for each public key, there are several
>>> publicly computable public keys that are equivalent to it, i.e., they produce
>>> the same shared secrets".  Assuming the early secret doesn't change, this
>>> means equivalent public keys will produce the same handshake secrets and
>>> the same master secrets.  The transcript hash does give you different
>>> handshake traffic secrets and application traffic secrets, but I think that's too
>>> late in the key schedule for [DOWLING].
> 
>> The proof in [DOWLING] only aims to prove that the handshake traffic secrets
>> and application traffic secrets are secure, not that the handshake secrets and
>> master secrets are secure, so for that purpose it should be okay that the
>> transcript hash is incorporated a little later in the key schedule.
> 
> Sorry, I only meant that in Theorem 5.2 the dual-snPRF-ODH assumption is used
> in Game B.2 to replace the handshake secret with a uniformly random value which
> then allows the handshake traffic secrets to be replaced with uniformly random
> values in Game B.3 using the PRF assumption on HKDF.Expand and the fact that
> the labels are distinct.  Equivalent public keys mean that the handshake secret
> is not indistinguishable from random and the proof fails at Game B.2.  The distinct
> labels in Game B.3 only imply that the handshake traffic secrets will be different,
> not that they are indistinguishable.
> 
> Peter
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]