On Thu, Sep 22, 2016 at 4:59 PM, Hugo Krawczyk <h...@ee.technion.ac.il>
wrote:

> On Thu, Sep 22, 2016 at 7:50 PM, Colm MacCárthaigh <c...@allcosts.net>
> wrote:
>
>> On Thu, Sep 22, 2016 at 4:41 PM, Hugo Krawczyk <h...@ee.technion.ac.il>
>> wrote:
>>
>>> If the problem is the use of forward secrecy then there is a simple
>>> solution, don't use it.
>>> That is, you can, as a server, have a fixed key_share for which the
>>> secret exponent becomes the private key exactly as in the RSA case. It does
>>> require some careful analysis, though.
>>>
>>
>> I think that this may be possible for TLS1.3 0-RTT data, but not for
>> other data where an ephemeral key will be generated based also on a
>> parameter that the client chooses.
>>
>
> The key_share contributed by the client is indeed ephemeral and it
> replaces the random key chosen by the client in the RSA-based scheme.
>

Yep, you're right, now I get it. I also now wonder if clients should make a
best effort of detecting duplicate parameters and rejecting them.

-- 
Colm
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to