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

[Eric Rescorla <[e-mail]>]

On Mon, Nov 13, 2017 at 6:12 AM, David Mazieres expires 2018-02-10 PST <
[e-mail]>
wrote:

> Eric Rescorla <[e-mail]> writes:
>
> >> So in the first paragraph of the section, we define SYN TEP as follows:
> >>
> >>         The meaning of data in a SYN segment with an ENO option (a
> >>         SYN+ENO segment) is determined by the last TEP identifier in the
> >>         ENO option, which we term the segment's _SYN TEP_.
> >>
> >> So I think the problem here may be that the term SYN TEP is confusing,
> >> or that the definition does not stand out enough.
> >
> >
> > The problem is that "govern" is not very clear. It's clearer to link the
> > requirement
> > here to the specific feature of the packet.
>
> Okay, let me futz with the language a bit and try to get rid of or
> clearly define the term govern.
>

Thanks


>> If you still think there's a problem with the current language, can you
> >> supply a more concrete example?  It sounds like you have a specific kind
> >> of protocol in mind that you think should be legal but isn't under the
> >> current draft.
> >
> >
> > Sure. OPTLS for example. This has PFS but also is robust against
> compromise
> > of the ephemeral key.
>
> Got it, thanks.  How about the following?
>
>         TEPs MUST guarantee the confidentiality of TCP streams without
>         assuming the security of any long-lived secrets.
>

SGTM.

Thanks
-Ekr


> David
>