On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell <m...@openssl.org> wrote:
> > > On 28/12/17 12:28, Eric Rescorla wrote: > > I think it would be helpful > > to be more explicit in the text if that is the case, i.e. identify > the > > first point in the handshake and the last point in the handshake > where > > CCS is valid. There probably should also be some words about how > servers > > implementing older TLS versions should handle a CCS that comes first. > > > > > > I could add those. > > > > > > However, I'm concerned about the added complexity of interpreting > things > > that way. Suddenly a CCS arriving is no longer handled by just > dropping > > it and forgetting it - you now have to store state about that and > > remember it later on in the process in other TLS versions. The CCS > > workaround was supposed to be a simple no-op to implement and it no > > longer appears that way in this interpretation. > > > > > > Well, it seems like the issue here is you want the client to send CH1, > > CCS, CH2 > > so we need the server to accept that. Am I missing something? > > The point is a stateless server will not know about CH1 at the point > that it receives CCS. Well, sort of. Specifically, there are three valid things that a server (whether stateless or stateful) can receive: - CH1 [I.e. a CH without a cookie] - CH2 [i.e., a CH with a cookie] - CCS It should respond to any other message with an alert and abort the handshake. A stateful server should also tear down the transport connection, so that subsequent messages are considered an error. This obviously isn't an option for a stateless server, so, yes, a stateless server might in principle receive arbitrary amounts of junk before CH1 or between CH1 and CH2, and it would still survive, albeit by sending alerts. > Actually, as Ilari points out, there could be any > junk (including partial records) arriving between CH1 and CH2. So this > feels more like a special case for stateless servers. > > In other words I would prefer to say that a CCS that arrives first is > not allowed. That simplifies the general case and requires no special > coding for servers implementing older versions of TLS. This issue only seems to arise for people who are both doing TLS 1.3 and TLS 1.2 *and* doing stateless implementations, which is kind of an odd configuration because a number of the conditions in TLS 1.3 that involve HRR (and thus can be stateless). It doesn't arise for QUIC (because no TLS 1.2) and mostly doesn't arise for DTLS (if you reject all kinds of junk). Or am I wrong? However, we add > additional words around what stateless servers do with "junk" they > receive that doesn't look like a ClientHello (i.e. they ditch it). That > "junk" would include a CCS. That seems like a much cleaner solution. > I'm not enthusiastic about this, as it entails not alerting in cases of clear protocol error. -Ekr > Matt > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
