On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara < ilari.liusva...@elisanet.fi> wrote:
> On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote: > > On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson < > martin.thom...@gmail.com> > > wrote: > > > > > On 21 July 2015 at 04:12, Eric Rescorla <e...@rtfm.com> wrote: > > > > > > > > Yes, that's an issue. Not entirely sure what to do about other than > > > > have the server provide its negotiation preferences out of band > > > > in that case. > > > > > > I think that we could handle that at the point we define an > > > out-of-band configuration priming mechanism. I don't think we need a > > > full negotiation model for the server. A simple option would list the > > > server's preference order for suites and so forth in its configuration > > > advertisement; the client would then pick from that. > > > > > Yeah, or it could just have the semantics "this is my most preferred > > configuration and if you send me anything compatible with it, I will > > pick it" > > What cipher this is about? The cipher used for protecting 0RTT/Early > handshake data? The cipher used for protecting main connection? > The former. For main connection, the server can pick from ciphersuites advertized > by client (assuming client gives ciphers that are acceptable and > are usable with configurations, i.e. GDHE_CERT-type things). > Agreed. > 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) 2. I'm trying to avoid questions about the security of the negotiation for the 0-RTT data, and we already have negotiated parameters. 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. Thanks, -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
