On Tue, Jul 21, 2015 at 02:55:33PM +0200, Eric Rescorla wrote: > On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara < > ilari.liusva...@elisanet.fi> wrote: > > > For 0-RTT/Early handshake data you want cipher that the server > > supports and accepts. If it is about this, there could be multiple > > allowed ciphers. > > > > In principle this is true. However, there are two complications, ISTM: > > 1. The client has no way of knowing which ciphers the server would support > other than the one it negotiated with the client previously (assuming > in-band)
Well, if it is about supported ciphers, there could be multiple, and the proposal has slot for only one. > 2. I'm trying to avoid questions about the security of the negotiation for > the 0-RTT data, and we already have negotiated parameters. Can you give some examples of such questions? > I haven't done any analysis of what happens if the server doesn't check > that it would negotiate the parameters that the client provides. That might > be fine, but I'm trying to be conservative. I think it would either work fine (client picks something server supports/ accepts) or it would not work at all (client picks some unknown cipher). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
