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

[David Mazieres <[e-mail]>]

Hi, Eric.  Thanks for your review.  Let me go through the discuss
points, but then below I have just a couple of questions about your
feedback.  Most of your points I was able to address straight-forwardly.


Eric Rescorla <[e-mail]> writes:
> ----------------------------------------------------------------------
> 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.

So to be clear, the goal here is to make a normative requirement that
prohibits something like DES or 40-bit RC4 like in the bad old days.
However, we also don't want to rule out something like AES-128 just
because some highly theoretical biclique attack shaves two bits off the
security for an attacker who happens to have 2^{80} storage (or whatever
the state of the art in AES attacks is).

The other problem is that "n-bit" security is kind of inherently
ambiguous anyway, because with circuit complexity you'd probably have a
fairly high constant factor multiple of your key space in gate count,
while with time you can just design an instruction set that does two
things at once hence shaves a factor of two off your runtime.

My hope was that this kind of phrasing would basically allow anyone to
object if a weak cipher like DES is being considered, while permitting
things like AES-128 to go through unimpeded by unanimous consent.  The
MUST is effort to hand as powerful a weapon as possible to anyone
legitimately arguing against the selection of a bad cipher.

That said, if it's simpler we could just pick some number like 112-bit
security or something.  We've discussed this point before and I think
ended up returning to the slightly informal wording being best, but
happy to entertain other suggestions.

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

The current phrasing is an attempt to walk a fine line between the
adamant demands of some working group members that TEPs fully support
urgent data and the desire to support TCP-use-TLS.  Basically the SHOULD
is intended to leave you enough leeway to argue that most applications
are known not to use urgent data so TCP-use-TLS can be on by default.
I've added a sentence to the experiments section to say one of the
things we might learn is whether we can relax the urgent data
requirements further.

I tweaked the phrasing to make it clear there may be other approaches
besides the to MAYs, so the current phrasing is:

      * TEPs MUST prevent corrupted packets from causing urgent data
        to be delivered when none has been sent.  There are several
        ways to do so.  A TEP MAY cryptographically protect the URG
        flag and urgent pointer alongside ordinary payload data.
        Alternatively, a TEP MAY disable urgent data functionality by
        clearing the URG flag on all received segments and returning
        errors in response to sender-side urgent-data API calls.
        Implementations SHOULD avoid negotiating TEPs that disable
        urgent data by default.  The exception is when applications
        and protocols are known never to send urgent data.

Does that work for you?

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

No, we definitely mean *any* ambiguity, including other unrelated RFCs.
Like if the segment contains a non-empty TFO option, for example.  This
is clarified again below, with:

* The SYN segment contains a non-empty TFO option or any other TCP
  option implying a conflicting definition of SYN data.

So does this need a clarification, or is the existing wording okay?

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

I'm confused by this comment.  Either you depend on a long-lived secret
for data confidentiality or you don't.  In your example, would
compromising the long-lived DH key also break past connections?  If so,
then you have a bad TEP.  If not, then you don't depend on a long-lived
secret for confidentiality, so your TEP is permissible.

Adding the word "solely" actually makes it more confusing to me.
Knowing my confusion, is there some other wording you would suggest?  Or
maybe leave as-is?

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

Do you want me to put a=0 in ever single SYN packet?  Since none of the
examples use the application aware bit, putting it in some segments but
not others might be confusing.  Can you say more specifically what the
possible confusion is?  Maybe one sentence saying a=0 in all examples
would help?

Thanks,
David