On Wed, Nov 8, 2017 at 5:54 AM, Benjamin Kaduk <bka...@akamai.com> wrote:
> On 11/08/2017 07:34 AM, Eric Rescorla wrote: > > > > On Wed, Nov 8, 2017 at 1:12 AM, Nikos Mavrogiannopoulos <n...@redhat.com> > wrote: > >> On Tue, 2017-11-07 at 16:32 -0800, Eric Rescorla wrote: >> > >> > >> > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd <watsonbl...@gmail.com> >> > wrote: >> > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar <j...@google.com> >> > > wrote: >> > > > FWIW: In my experience middleboxes don't ossify based on what the >> > > spec says, >> > > > they ossify based on what they see on the wire. So, if common >> > > > implementations send CCS in a particular way, that's what will >> > > get --- and, >> > > > I'll argue, what has gotten --- ossified. I also agree with David >> > > and Eric >> > > > that compatibility mode shouldn't be required because QUIC >> > > doesn't need it. >> > > >> > > What does compatibility mode mean here? >> > >> > It means: >> > >> > 1. Send the fake session_id >> > 2. Send a bunch of spurious CCS values. >> > >> > >> > > If we end up with having two >> > > slightly different versions of TLS 1.3, one that looks more like >> > > TLS >> > > 1.2 and the other that does not, that doesn't seem like a good >> > > thing >> > > to me. >> > >> > Well, the idea is that this is a purely local decision by one side. >> >> Which increases the cost of TLS1.3 implementation and testing by >> introducing different handshake state machines. > > > It doesn't introduce different handshake state machines, because you just > ignore the CCS. > > > I am leery of things that we flat-out *ignore*, as that sort of thing has > a history of coming back to bite us. > Well, I suppose that's possible, but given that this is in the plaintext stream, it seems less concerning. > Why not negotiate that >> CCS addition with an extension and have it defined outside the TLS 1.3 >> spec? > > > That actually does introduce different state machines. > > > True, but perhaps still worth thinking about. > In some sense, we might not even need an extension; we could take Martin's > idea and run with it -- server MUST send CCS if the client sends a > sessionID, and server MUST NOT send CCS if the client does not send a > sessionID. This would still make the state machine bigger, but avoids a > fork that depends only on "what message do I receive here". On the other > hand, it also places all the burden of deciding when to use the compat > scheme on the client, when people are making the case that some servers, at > least, have some sense of when they're behind a relevant middlebox. But > I'm not entirely sure how convincing those arguments have been, so far. > Well, at some level the client has to make the initial decision because it has to decide what to put in CH. If you replace your MUST NOT with a MAY, then the server can decide for itself whether to send the CCS, and this works well with "ignore" -Ekr > -Ben > > -Ekr > > I understand the concerns of the browser "community" on being >> 100% backwards compatible with middle boxes, but the TLS1.3 standard is >> more than just browsers. If 100% compatibility is required, there is a >> very simple solution, use TLS 1.2. >> >> regards, >> Nikos >> >> > > > _______________________________________________ > TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
