Hi, David,
On Thu, Oct 26, 2017 at 3:07 AM, David Mazieres <
dm-list-tcpcr...@scs.stanford.edu> wrote:
> Spencer Dawkins <spencerdawkins.i...@gmail.com> 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.
>
This mostly looks good. Just to follow up on a couple of points (but you're
now deep in "do the right thing" territory) ...
>
> > 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...
>
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).
> > 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."?
>
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.
> > 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.
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
> want to leave implementers a little bit of wiggle room in case early
> parsing of ENO segments turns into a huge pain point.
>
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).
> 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.
>
Also works for me (maybe better than my suggestion).
> 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.
>
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.
> > 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?
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
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
