Re: [tcpinc] TCP's treatment of data in SYN packets

[Kyle Rose <[e-mail]>]

On Sun, Aug 7, 2016 at 1:43 PM, Joe Touch <[e-mail]> wrote:

> > * Implementations SHOULD provide forward secrecy.  The important point
> >   is that the TEPs MUST be amenable to forward secrecy.
> That MUST turns the SHOULD into a MUST too.
> >   We didn't say
> >   MUST for the implementation because that may not always be
> >   possible--e.g., implementation considerations may someday require
> >   keying material to be shared across servers or with a load-balancer or
> >   something.  We don't want to say you can't implement TCP-ENO under
> >   such circumstances, but we want people to think long and hard about
> >   the implications for confidentiality.
> That consideration is too vague to weaken a MUST into a SHOULD, IMO.
>
> Why not "MUST provide forward secrecy" and indicate that any future
> sharing is viable only when it preserves forward secrecy?
>

I'm not sure we should constrain the protocol on the grounds of preference.
The charter says:

q( encryption and integrity protection with forward secrecy with a
per-connection granularity, )

which tcpcrypt is going to provide. I don't think this implies a
requirement that the protocol used to fulfill the WG charter not be able to
negotiate non-FS security. How do others feel about this? I'm happy to flag
this as a point for security area review, to decide whether forward secrecy
is a MUST for this or even for all future protocols.

> * Applications SHOULD authenticate endpoints, SHOULD treat session IDs
> >   monolithically, SHOULD use the application aware bit.  Again, these
> >   are all obviously very good things.  But there are so many different
> >   things an application can do, and so many constraints applications can
> >   be subject to, that it seems inappropriate for a transport-layer
> >   document to use MUST in regards to applications.  Anyway, we can't
> >   enforce what applications will do.
> If you say SHOULD, you need to indicate the conditions under which apps
> would do otherwise.
>
> Simply saying "we don't know what they want" isn't enough - you're
> providing a framework and app choices have implications in the
> capabilities provided.


Agreed. I don't think this language belongs in the draft. Authenticating
endpoints is good security practice because it eliminates certain classes
of attacks, but given that the WG's charter is to provide unauthenticated
encryption to foil ubiquitous passive surveillance, I'm not sure that
guidance belongs here.

Kyle