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
