Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)

[Kyle Rose <[e-mail]>]

On Mon, Nov 27, 2017 at 10:07 AM, Eric Rescorla <[e-mail]> wrote:
> On Mon, Nov 27, 2017 at 5:36 AM, Kyle Rose <[e-mail]> 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