On Mon, Nov 27, 2017 at 10:07 AM, Eric Rescorla <e...@rtfm.com> wrote: > On Mon, Nov 27, 2017 at 5:36 AM, Kyle Rose <kr...@krose.org> wrote: >> If tcpinc were primarily about confidentiality against active >> attackers, I think I'd come down on the side of safety against bad >> implementations; but, as the primary goal of tcpinc is to prevent >> pervasive passive surveillance, I think the balance tips the other >> way: to favor performance over misuse tolerance. > > Hmm.... This seems like kind of an odd argument given that the design of > tcpcrypt explicitly eschews the kind of techniques that have been found > to be important to high resumption rates in protocols such as TLS.
Were you thinking of stateless resumption (e.g., tickets) or something else here? My recollection from a mailing list discussion on tickets was that ENO and tcpcrypt deliberately make some tradeoffs in session resumption for performance given the constraints of TCP, specifically in terms of option space: there simply isn't enough option space to encode sufficient state, and the realities of middlebox ossification probably dead-end enhancements like EDO on the public internet. Speaking personally (not as chair), I also feel like tcpinc sits in a niche in which stateless resumption adds more complexity than is justified by the probable use cases. That's probably begging the question some, as stateless resumption might alter that distribution, but it's not clear the extra round trip for repeated connections to the same machine would be tolerable for many WAN use cases in legacy protocols, where tcpinc is focused. >> I also agree with David Black that I feel like there's a lot of scope >> creep here: frankly, I'm not comfortable making substantive changes to >> the core protocol without doing another WGLC. > > I agree that you should do another WGLC if you make this change (or either > change, for that matter.) But I don't think that's a reason not to make > changes. Agreed (though I am not sure Mirja will be happy to hear that). My comment about scope creep is simply that the WG came to a consensus on this topic (resumption tradeoffs) long ago, so I'm not sure we should be second guessing that judgment at IETF LC. Kyle _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
