On 13 September 2017 at 17:08, Ilari Liusvaara <ilariliusva...@welho.com> wrote: >> > Yes, if one receives a ClientHello with both Cookie and EarlyData, one >> > can reply with a fatal alert, because that is not supposed to happen. >> >> That isn't quite the scenario I was talking about. Rather your case >> (2) above in a server which is operating statelessly, i.e. the client >> has attempted to send early_data but has not provided a valid cookie >> yet. The early_data when it arrives will look like bad packets, even >> though (from the client perspective) it was valid to send them. > > If you really got some transport that uses TLS on something where > stateless operation makes sense (so not TCP) that transports the 0-RTT > TLS data in-band (so not QUIC), just throw any initial records starting > with 0x17 into trash. > > AFAIK, QUIC does not use TLS 0-RTT data, it uses 0-RTT exporters to > derive encryption keys for data, that is sent outside TLS. So in > that case, TLS would see two consequtive ClientHello messages if the > first gets rejected.
Ah! Right - yes that is a good point. I was looking at this from the perspective of the need to support QUIC. I had missed that subtlety - thanks. There is still a theoretical issue if something other than TLS/TCP or TLS/QUIC wants to do this. But given there is no actual known use case for that then I guess we can cross that bridge when we come to it. Matt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
