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

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

Hi Peter,

If your question is about what assumption the PQ KEM you still need to 
make in case it's not IND-CCA secure anymore and you want to fall back 
to [DOWLING] for the (EC)DH result, I think the answer is: none. 
(Beyond ensuring unambiguous encoding of KDF inputs, as the draft 
mandates through fixed-length shared secrets etc.)

You would then be treating HKDF.Extract as a random oracle (which for 
PRF-ODH security is the take-away from [ https://ia.cr/2017/517 ]), 
where the IKM input is augmented with the (possibly 
adversary-controlled) KEM shared secret. But the encoding would ensure 
that the argument wrt. ECDH would still apply.

Cheers,
Felix


PS: Sorry for the prior double posting; we were under the impression 
that Marc's first email didn't get delivered to the list.

On 2024-08-01 11:38 +0200, Peter C <[e-mail]> wrote:
> Marc and Felix,
> 
> Thank you both for your replies.
> 
> I can see how this will work for NIST P-256 and X25519 - it is
> straightforward to detect the equivalent public and adjust the
> output of the simulator accordingly - and I also agree that it is
> not a significant change to the PRF-ODH assumption.
> 
> Have you thought how this transfers across to the hybrid key
> exchange in draft-ietf-tls-hybrid-design?  Do you know what
> assumption, if any, you need to make on the PQ KEM to be
> able to reuse the argument in [DOWLING]?
> 
> Thanks,
> 
> Peter
> 
>> -----Original Message-----
>> From: Marc Fischlin <[e-mail]>
>> Sent: Monday, July 29, 2024 4:40 PM
>> To: [e-mail]
>> Subject: [TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt
>>
>> [You don't often get email from [e-mail]. Learn why
>> this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Dear all,
>>
>> Douglas and the other "TLS co-authors" discussed this briefly, but I
>> think that Douglas is offline for the next couple of days and asked me
>> if I could answer on behalf of the authors.
>>
>> It is indeed true that the PRF-ODH assumption, as stated, wouldn't be
>> comaptible with the usage of the x-coordinate. One needs to be a little
>> bit more careful in this case, disallowing the adversary to flip signs
>> of curve points. This has been done for example in a paper about the
>> security of Bluetooth which I co-authored, where the x-coordinate is
>> also used to derive keys. There we adapted the definition accordingly
>> (Section 4.1 in https://eprint.iacr.org/2021/1597.pdf of this Asiacrypt
>> 2021 paper). I don't think that this makes the assumption less
>> plausible, only more annoying to deal with in the proofs.
>>
>> We have also checked that with the modifcation above the TLS proofs goes
>> through as before, one only needs to repeat the extracted key in
>> executions which have the same x-coordinate (instead of the same DH
>> values as so far).
>>
>> Hope this helps to clarify. Let me know if you need more details.
>>
>> Marc Fischlin
>>
>> _______________________________________________
>> TLS mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]