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

[Eric Rescorla <[e-mail]>]

On Mon, Nov 13, 2017 at 10:37 AM, David Mazieres <dm-list-tcpcrypt@scs.
stanford.edu> wrote:

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

See David Black's email.


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

This still seems to suggest that these are exclusive. Perhaps a
"For instance" before "A TEP MAY"


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

Sorry, I meant to replace "When the SYN TEP does not govern the
connection", not the point about ambiguity,.



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

Well, as Cas Cremers keeps pointing out, if you also had a weak PRNG,
then you would in fact be depending on the static DH key. I think my problem
is the word "depend" which seems imprecise.

It' s clumsy but perhaps
"TEPs MUST NOT be designed so that compromise of a long-lived secret
compromises confidentiality"





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


Why am I supposed to infer that it is 0 here when the other is 1.


  Maybe one sentence saying a=0 in all examples
> would help?


I would deal with this by a note here saying that you explicitly show a=0
here for clarify, but I could live with you having the sentence you suggest
both in the first example and then a reminder here.

-Ekr