Martin Thomson <[email protected]> writes: > Again, you are getting bogged down in the details. What are the > properties you would expect from a session ID? That it is unique to a > session and that it is hard to guess (with high probability). Those > are the only properties that you need to require at this level of the > design.
I would also like it to be indistinguishable from random, modulo choice of encryption spec, so that an attacker cannot correlate session IDs with recorded packet transcripts. > To up-level a little, I think that TCP-ENO is going too far in terms > of specifying extra little bits. This session ID stuff is a good > example of that. If the purpose of the draft is to enable selection > of an encryption scheme, then it has far too much machinery. It's more than that. It's trying to abstract away the details of the spec for applications, so that an application written to use TCP-ENO can work with any spec. > I have problem with specifying requirements, which is part of what > Section 4 attempts to do. But you'd be better off doing so in a > straightforward fashion. If we don't specify requirements for the session ID, then applications will have to be knowledgeable about what encryption spec they are using. That means if we get large SYN options down the line and massively optimize TCPINC, applications won't be able to take advantage of it automatically. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
