On Thu, Sep 22, 2016 at 4:59 PM, Hugo Krawczyk <h...@ee.technion.ac.il>
> On Thu, Sep 22, 2016 at 7:50 PM, Colm MacCárthaigh <c...@allcosts.net>
>> On Thu, Sep 22, 2016 at 4:41 PM, Hugo Krawczyk <h...@ee.technion.ac.il>
>>> 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.
TLS mailing list