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? 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). 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. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
