On Mon, Nov 27, 2017 at 12:36 PM, Eric Rescorla <e...@rtfm.com> wrote:
> On Mon, Nov 27, 2017 at 9:24 AM, Kyle Rose <kr...@krose.org> wrote:
> 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.

For a server pool, I completely agree.

> 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 would be interested in an (OOB) conversation on your thoughts here.

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

I was referring specifically to the resumption tradeoffs (rate vs.
performance). That said, all I can find is this:

https://www.ietf.org/mail-archive/web/tcpinc/current/msg00919.html

which doesn't actually talk about that tradeoff, but rather about the
charter's requirement for forward secrecy.

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

No, I think you're right that this wasn't widely understood, or at
least not discussed. That wasn't what I was referring to, however: I
do think the brittleness is worth at least discussing on the list
(check) and seeing if there's consensus to make a change to the
protocol or to add a crystal clear warning to the draft explaining the
critical importance of not reusing SIDs.

Kyle

_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc

Reply via email to