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

["Black, David" <[e-mail]>]

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:

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

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

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?

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/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/
> 
> 
> 
> ----------------------------------------------------------------------
> 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?
>