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

[Eric Rescorla <[e-mail]>]

On Mon, Nov 27, 2017 at 9:24 AM, Kyle Rose <[e-mail]> wrote:

> 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?


Yes.



> 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 don't really think it's really worth relitigating this; I'm merely
observing
that if you want high resumption rates then you want stateless resumption.
As for the question of option space, I'm not persuaded it wouldn't
be possible to have stateless resumption with the same number of
round trip times if you were willing to be a bit more careful about
how you handled failure.


>> 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.
>

I'm not sure what you think is being second guessed. Taking a step back, the
way we got here is that I observed that the specific resumption design here
is extremely brittle (and far more brittle than in other protocols that we
design)
and that the warnings about how you had to handle the keys were insufficient
to allow the users to know. This then turned into a discussion about how
to make the protocol less brittle. It's certainly within the WG's
discretion to
not address this (though I personally think you ought to) but if so, it's
imperative
that it be adequately documented what the risks are, which the current text
does not do.

With that said, it's not clear to me that the WG actually did have consensus
that this brittleness was a good tradeoff. Was this property in fact widely
understood? Speaking only for myself, it really only came into focus for me
when I did my review.

-Ekr


> Kyle
>