Posting mostly to merge email threads back into one thread - IMHO, the following exchange seems to capture the state of things and subsumes the details that the other (my) thread with Ekr had gotten into:
> > 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. Thanks, --David > -----Original Message----- > From: Kyle Rose [mailto:kr...@krose.org] > Sent: Monday, November 27, 2017 12:58 PM > To: Eric Rescorla <e...@rtfm.com> > Cc: Daniel B Giffin <d...@scs.stanford.edu>; Black, David > <david.bl...@emc.com>; tcpinc <tcpinc@ietf.org>; tcpinc-cha...@ietf.org; > The IESG <i...@ietf.org>; draft-ietf-tcpinc-tcpcr...@ietf.org > Subject: Re: [tcpinc] Eric Rescorla's Discuss on > draft-ietf-tcpinc-tcpcrypt-09: > (with DISCUSS and COMMENT) > > 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
