On Tue, Nov 7, 2017 at 7:32 PM Eric Rescorla <e...@rtfm.com> 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. >
In particular, either "mode" leaves everything interoperable with everything else, modulo middlebox misbehavior. The arrangement with CCS and session_id is that the sender MAY send some random vestigial junk that the receiver MUST ignore. If you know your implementation lives in a context whether it doesn't matter (QUIC, internal networks, a happy unrealistic future where networks are made of unicorns and sunshine instead of middleboxes), you can avoid sending the useless bits. Otherwise, you probably want to send it. -Ekr > > >> My understanding is we already have ossification here and the debate >> is what to do about it. >> >> >> -- >> "Man is born free, but everywhere he is in chains". >> --Rousseau. >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
