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

[Eric Rescorla <[e-mail]>]

On Sun, Nov 12, 2017 at 5:08 AM, Black, David <[e-mail]> wrote:

> Hi Ekr,
> [writing as draft shepherd]
>
> Let's see if the two of us can find some time in Singapore to talk about
> the two crypto algorithm Discuss points (encryption and secure hash), as
> (IMHO) the authors' intentions are good:
>

Yep.


- Encryption: The intent is - don't use anything weaker than AES-128, e.g.,
> don't even think about using 3DES.  The concern is how to write that
> requirement in a way that would survive hypothetical discovery of a
> catastrophic cryptanalytic attack on AES-128.
>

Or even a small one. I mean, what does this say about Curve25519 or 4Q.



- Secure Hash: The intent is - don't use vanity crypto.  Does the Security
> Area have some text that could just be copied to say that?
>

Not to my knowledge. I'm not sure this is really useful to say.



> On URG handling, the Discuss point is:
>
> > IMPORTANT: This actually seems to be a bit confusing about how to
> > handle URG. Consider TCP-use-TLS, you would just process URG in the
> > normal way and then generate errors if URG causes reordering at the
> > TLS layer. This seems like a reasonable procedure but is at least
> > arguably prohibited by this text.
>
> I'm confused, as the only "MUST" requirement on URG handling is:
>
>    o  TEPs MUST prevent corrupted packets from causing urgent data to be
>       delivered when none has been sent.
>
> Surely TCP-use-TLS meets that requirement ;-).   Beyond that, the list of
> implementation techniques that follows uses "MAY" twice, and is not
> intended to be comprehensive.  Would stating that the list of
> implementation techniques is not comprehensive suffice, or is something
> else causing heartburn here?
>

Yep, that would be fine. I read those MAYs as exhaustive.

-Ekr


>
> Thanks, --David
>
> > -----Original Message-----
> > From: Eric Rescorla [mailto:[e-mail]]
> > Sent: Friday, November 10, 2017 9:04 PM
> > To: The IESG <[e-mail]>
> > Cc: [e-mail]; Black, David <[e-mail]
> >;
> > [e-mail]; Black, David <[e-mail]>;
> [e-mail]
> > Subject: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with
> DISCUSS
> > and COMMENT)
> >
> > Eric Rescorla has entered the following ballot position for
> > draft-ietf-tcpinc-tcpeno-13: Discuss
> >
> > 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/stat
> ement/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/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> >    o  TEPs MUST NOT permit the negotiation of any encryption algorithms
> >       with significantly less than 128-bit security.
> > IMPORTANT: I don't know what "significantly means". I wouldn't be
> > making a point of this, but it's phrased as a normative requirement,
> > so I don't know what conformance means.
> >
> >
> > IMPORTANT: This actually seems to be a bit confusing about how to
> > handle URG. Consider TCP-use-TLS, you would just process URG in the
> > normal way and then generate errors if URG causes reordering at the
> > TLS layer. This seems like a reasonable procedure but is at least
> > arguably prohibited by this text.
> >
> >
> >    problems, TEPs MUST compute session IDs using only well-studied and
> >    conservative hash functions.  That way, even if other parts of a TEP
> >    are vulnerable, it is still intractable for an attacker to induce
> >
> > IMPORTANT: this also does not seem to be unambiguous.
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> >
> >
> >    4.  Provide a standard negotiation transcript through which TEPs can
> >        defend against tampering with TCP-ENO.
> >
> > This was unclear to me when I first read this. Maybe
> > "Export a standard negotiation transcript to TEPs which they can use to
> > defend
> > against"
> >
> >    opportunistically.  It uses a new TCP option kind to negotiate one
> >    among multiple possible TCP encryption protocols or TEPs.  The
> >    negotiation involves hosts exchanging sets of supported TEPs, where
> > Nit: I would say "one TEP out of multiple"
> >
> > Also, "TCP encryption protocols or TEPs." is confusing. If you feel the
> need to
> > redefine, do "TCP encryption protocols (TEPs)"
> >
> >    variable-length data.  When "v = 0", the byte itself constitutes the
> >    entirety of the suboption.  The 7-bit value "glt" expresses one of:
> > I would say "the remaining 7-bit value, called "glt", may take on various
> > meanings, as defined below"
> >
> >    "b = 0" plays the "A" role.  The host that sent "b = 1" plays the "B"
> >    role.
> > This would be clearer if it (a) explained the reasoning and (b) appeared
> before
> > the packet formats. Perhaps something like
> >
> > "Because the passive opener MUST set b=1 and the active opener by default
> > sets
> > b=0, the normal cases is that the active opener is A and the passive
> opener is
> > B. Applications which depend on simultaneous open and have some other
> > way of
> > breaking the tie can set one side to b=1 (even though it is the active
> opener)
> > and thus arrange for correct role assignment. Otherwise, simultaneous
> opens
> > will fail"
> >
> >    If both sides of a connection set "b = 1" (which can happen if the
> >    active opener misconfigures "b" before calling "connect"), or both
> >    sides set "b = 0" (which can happen with simultaneous open), then
> > Why is this "misconfigures"? You allow them to do so.
> >
> >    initial suboption byte (see Figure 4).  By default, suboption data
> >    extends to the end of the TCP option.  Hence, if only one suboption
> >    requires data, the most compact way to encode it is to place it last
> > Why is this "by default"? It just seems like another setting of glt.
> >
> >    connection or when there is any ambiguity over the meaning of the SYN
> >    data.  This requirement applies to hosts that implement ENO even when
> >    ENO has been disabled by configuration.  However, note that
> > I think you may mean to say "when the last SYN TEP is not eventually
> > negotiated"
> >
> >    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.
> > Maybe "depend solely" because one might want to use a DH mode where a
> > static DH
> > key is mixed in with an ephemeral.
> >
> >       probability detect a FIN flag that was set or cleared in transit
> >       and does not match the sender's intent.  A TEP MAY discard a
> >       segment with such a corrupted FIN bit, or may abort the connection
> > What is "high probability"
> >
> >       that disable urgent data by default.  The exception is when
> >       applications and protocols are known never to send urgent data.
> >
> >              (4) B -> A:  SYN-ACK  ENO<b=1,X,Y,Z>
> >              [rest of connection encrypted according to TEP Y]
> > Can you show a=0 in line 1?
> >
>
>