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

From: Spencer Dawkins <[email-masked]>
Date: Wed, 25 Oct 2017 21:24:31 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-tcpinc-tcpeno-12: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

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.

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?

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?

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?

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.

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?

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?

---

From: David Mazieres <[email-masked]>
Date: Thu, 26 Oct 2017 01:07:42 -0700

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.

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

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

>    from offering only one TEP.

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

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

> will be in practice. Could you help me understand why this isn't a specific

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.

> 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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 26 Oct 2017 13:38:04 -0500

Hi, David,

> suggestion in light of my clarifications.

This mostly looks good. Just to follow up on a couple of points (but you're
now deep in "do the right thing" territory) ...

> read that way we have a problem...

The problem may not be with your text :-)

I see that RFC 793 starts out by hyphenating "option-kind", although it
drops "option-" after two or three uses, in favor of "kind". Hyphenating as
"option-kind" would have helped me snap that "kind" wasn't just floating,
and citing RFC793 would have been really helpful (but do the right thing).

> "Manual configuration of b is *only* necessary to enable encryption with

That's probably about the right level of detail - it invites implementers
to think about whether they should be expecting simultaneous opens. without
going as far as I did in offering clues about why that might happen.

> ENOs.

Thanks for the explanation. It's helpful.

> This seems way too detailed to discuss in the RFC.

I believe you. Here's the thing.

> However, we

You have this as a SHOULD, which ought to mean that doing it matters in
most environments ("unless you make an informed decision not to"), but if B
can offer more than one TEP, and A has to be able to handle more than one
TEP, I find myself wondering how important the SHOULD (because implementers
have to accommodate that behavior).

>         identifier suboptions, which we term a _vacuous_ SYN-form ENO

Also works for me (maybe better than my suggestion).

> would be just to leave the existing wording.

So, I guess I'm wondering how future-proof this MUST is, if the definition
of "significantly less than 128-bit security" fluctuates based on the state
of attacks at any moment in time ("you just got owned, so you must have
used significantly less than 128-bit security" - "but it wasn't
significantly less than 128-bit security yesterday!").

Is there a reference that you could point to, that describes these
considerations in more detail (so that the text in this document would be
more like "MUST NOT permit the negotiation of any encryption algorithms
that don't meet [GeneralGuidance])"), and (for extra credit) a reference
that's more likely to track the state of the art on key length and
vulnerability better than text in an RFC?

But if there's not, do the right thing.

> Is there a phrasing that would have made this clearer?

You're answering a FAR smarter question than I asked ;-) ...

I couldn't parse "as implementations SHOULD provide forward secrecy some
bounded, short time", and was asking if this should have been more like "as
implementations SHOULD provide forward secrecy <for> some bounded, short
time".

I do appreciate the explanation!

Spencer