Re: [tcpinc] Spencer Dawkins' Yes on draft-ietf-tcpinc-tcpeno-12: (with COMMENT)

[David Mazieres <[e-mail]>]

Spencer Dawkins <[e-mail]> writes:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> This draft was fairly easy for me to follow. I do have some questions, of
> course, but I'm a Yes.

Thanks for the vote and the comments.  Most of these points look like
they can be addressed with small edits to the draft.  I'll answer them
here in case you disagree with anything or want to make a more concrete
suggestion in light of my clarifications.

> In Section 3, Terminology, most of the terms were originally defined
> in RFC 793 (pretty much all, except for the last three, about TEP). I
> don't object to this document saying "this is how we are using these
> terms from RFC 793", but I do think it's worth providing an explicit
> pointer to the more detailed descriptions in RFC 793, which is already
> a normative reference but is only referenced for the description of
> TCP header options in Section 4.1.

Yes, referencing RFC793 here is a great idea.

> I'm having a little trouble figuring out what "kind" means in this text.
>
>    It uses a new TCP option kind to negotiate one
>    among multiple possible TCP encryption protocols or TEPs.
>
> Is this a term of art I haven't seen?

The term is intended to be used in the sense of RFC793.  If that wasn't
clear to an IETF area directory, then there's something wrong with the
sentence.  Would it help to cite RFC793 after the word kind?

We certainly did *not* intend some other colloquial meaning of kind, as
in "a new kind of option that, instead of going in the TCP header as
RFC793 specifies, goes at the end of the segment."  If the language is
read that way we have a problem...

> I understand every word in this text,
>
>   b
>       The passive role bit MUST be 1 for all passive openers.  For
>       active openers, it MUST default to 0, but implementations MUST
>       provide an API through which an application can explicitly set "b
>       = 1" before initiating an active open.  (Manual configuration of
>       "b" is necessary to enable encryption with a simultaneous open.)
>
> but am not sure what you're telling implementers - is the point that a
> client application using a traditional client-server application
> protocol doesn't need to set "b = 1" for an active open, because
> servers won't also be attempting an active open simultaneously, but
> applications using peer-to-peer application protocols should?

That's exactly what we meant.  Would it have been clearer if we'd said
"Manual configuration of b is *only* necessary to enable encryption with
a simultaneous open."?

> Could you give an example of the kind of "implementation considerations" that
>
>   A passive opener (which is always host B) sees the remote host's SYN
>    segment before constructing its own SYN-ACK segment.  Hence, a
>    passive opener SHOULD include only one TEP identifier in SYN-ACK
>    segments and SHOULD ensure this TEP identifier is valid.  However,
>    simultaneous open or implementation considerations can prevent host B
>    from offering only one TEP.
>
> is envisioning?

The implementation consideration is that SYN-ACK segments may be
generated at softirq level in the kernel (or maybe someday in hardware),
while parsing of ENO options may happen in kernel process context or
even at user level.  Hence, passive openers may need to pre-compute ENO
option contents for SYN-ACK segments before examining specific incoming
ENOs.  This seems way too detailed to discuss in the RFC.  However, we
want to leave implementers a little bit of wiggle room in case early
parsing of ENO segments turns into a huge pain point.

Any further suggestions in light of this context would be welcome...

> Perhaps
>
>   A host MAY send a _vacuous_ SYN-form ENO option containing zero TEP
>    identifier suboptions.
>
> would be an appropriate entry in the terminology section? I had to keep reading
> to understand what _vacuous_ meant in this sentence.

A little rewording might be sufficient here.  How about:

        A host MAY send a SYN-form ENO option containing zero TEP
        identifier suboptions, which we term a _vacuous_ SYN-form ENO
        option.

> I wonder what the understanding of "significantly less" in
>
>   o  TEPs MUST NOT permit the negotiation of any encryption algorithms
>       with significantly less than 128-bit security.
>
> will be in practice. Could you help me understand why this isn't a specific
> number?

It's not a specific number because we don't want to rule out AES-128,
which on account of a theoretical biclique attack has only about 126-bit
security.  If we hard-coded 126, at some point a better attack could
bring it down to 125 bits, or maybe there's some other desirable cipher
with 125-bit security.  Hence, whether or not a particular cipher has
"about 128-bit security" seems like a question best left to the common
sense of the security ADs or other designated expert.  For that reason,
unless you still object or have a better suggestion, my inclination
would be just to leave the existing wording.

> I couldn't parse "provide forward secrecy some bounded, short time" in
>
>   o  TEPs MUST NOT depend on long-lived secrets for data
>       confidentiality, as implementations SHOULD provide forward secrecy
>       some bounded, short time after the close of a TCP connection.
>
> without guessing. Perhaps one or more words is missing?

The idea is that a TEP should have a bound after which a closed
connection will enjoy forward secrecy.  For example, say someone
develops a TEP that uses ephemeral RSA keys.  It's too expensive to
re-generate an RSA key for every connection, so the keys are re-used
across connections.  Nonetheless, there MUST be a bound after which a
closed connection enjoys forward secrecy.  To comply with this
requirement, the TEP could specify that an ephemeral RSA private key
MUST be erased within 5 minutes of its first use.  Does that make sense?
Is there a phrasing that would have made this clearer?

Thanks,
David