On Thu, Dec 28, 2017 at 10:02 AM, Matt Caswell <m...@openssl.org> wrote:
> > > On 28/12/17 17:55, Eric Rescorla wrote: > > > > On Thu, Dec 28, 2017 at 9:51 AM, Matt Caswell <m...@openssl.org > > <mailto:m...@openssl.org>> wrote: > > > > > > > > On 28/12/17 17:42, Eric Rescorla wrote: > > > > > > > > > On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell <m...@openssl.org > <mailto:m...@openssl.org> > > > <mailto:m...@openssl.org <mailto: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? > > > > Correct, although technically the wording of draft-22 (in your > > interpretation) *requires* that a server receiving a CCS first MUST > > ignore it - even though that should never happen except in the weird > > scenario above. That is why I prefer to say that a CCS arriving > first is > > always an error for the general case. > > > > > > Well, you can receive a CCS first any time you're stateless. What's > unusual > > is having to subsequently reject it if you are stateless and *then* > > negotiate > > 1.2. My point is that this doesn't seem like a very big hardship for the > > reasons > > above. > > I must be missing your point. According to the spec as it stands even > with a stateful server I MUST ignore a CCS that comes first. Since this > is a stateful server it may end up negotiating TLSv1.2 - which requires > us to abort the handshake if the CCS comes first. No sensible > implementation will ever send a CCS first in this scenario, so why am I > required by the spec to ignore it and implement the extra complexity in > TLSv1.2 handling? > > In reality I wouldn't bother to implement this which would make me > technically non-compliant. I would prefer it if the wording were fixed > to not require this. > OK, I understand your point now, I think it's fine to reject this case as long as you properly handle things in the stateless case. If you want to submit a PR, I will take a look. -Ekr > Matt > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
