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

[Eric Rescorla <[e-mail]>]

This seems fine to me. 124, 120, whatever it takes.

-Ekr


On Mon, Nov 13, 2017 at 10:41 AM, Black, David <[e-mail]> wrote:

> > > 1) Encryption: Ekr and I need to talk about how to express “no weaker
> than current strength of AES-128 (i.e., based on attacks known in 2017)”
> >>
>
> > Yep. Happy to do this at a mutually convenient time.
>
>
>
> I found something useful, as it turns out that I’ve seen this before in
> dealing w/another draft …
>
>    o  TEPs MUST NOT permit the negotiation of any encryption algorithms
>       with significantly less than 128-bit security.
>
> To begin with, “permit the negotiation” is somewhat off, as this is a
> design-time requirement for TEP security strength.  Fortunately, NIST SP
> 800-57 part 1 covers the notion of “security strength” in significant
> detail, so citing that should provide clarity on that concept.  That leaves
> the concern about how not to lose AES-128 if an attack is discovered that
> knocks a few bits off of its security strength.  Here’s a suggestion with
> the full rationale:
>
> o  TEP encryption SHOULD have a security strength [SP800-57part1] of at
> least 128 bits and MUST have a
>    security strength of at least 120 bits.  The intent of this requirement
> is to allow use of encryption
>    algorithms designed for 128 bit security strength if attacks should be
> discovered that weaken their
>    security strength by a few bits.
>
> I suggested 120 bits here as being halfway between 128 bits (clearly
> acceptable) and 112 bits (clearly unacceptable) – that could be some other
> number of bits, e.g., 124 bits.
>
>
>
> Thanks, --David
>
>
>
> *From:* Eric Rescorla [mailto:[e-mail]]
> *Sent:* Sunday, November 12, 2017 8:59 PM
> *To:* Black, David <[e-mail]>
> *Cc:* Kyle Rose <[e-mail]>; The IESG <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail]
>
> *Subject:* Re: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13:
> (with DISCUSS and COMMENT)
>
>
>
>
>
>
>
> On Mon, Nov 13, 2017 at 9:53 AM, Black, David <[e-mail]>
> wrote:
>
> Keeping this all on one thread, I think the situation on the three Discus
> points is:
>
>
>
> 1) Encryption: Ekr and I need to talk about how to express “no weaker than
> current strength of AES-128 (i.e., based on attacks known in 2017)”
>
>
>
>
>
> Yep. Happy to do this at a mutually convenient time.
>
>
>
>
>
> 2) The resolution for URG processing is clear – state that the list of two
> techniques is not exhaustive, although the text would be improved by
> describing the two techniques as examples of what could be done and not
> using the “MAY” keyword.
>
>
>
> LGTM.
>
>
>
>
>
>
>
> 3) On further reading, it looks like the one-way hash function concern is
> caused by a little bit of weak text in the Security Considerations section,
> as the body of the draft gets this topic right in Section 6:
>
>
>
>    o  The session ID MUST depend in a collision-resistant way on all of
>
>       the following (meaning it is computationally infeasible to produce
>
>       collisions of the session ID derivation function unless all of the
>
>       following quantities are identical):
>
>
>
>       *  Fresh data contributed by both sides of the connection,
>
>
>
>       *  Any public keys, public Diffie-Hellman parameters, or other
>
>          public asymmetric cryptographic parameters that are employed by
>
>          the TEP and have corresponding private data that is known by
>
>          only one side of the connection, and
>
>
>
>       *  The negotiation transcript specified in Section 4.8
> <https://tools.ietf.org/html/draft-ietf-tcpinc-tcpeno-13#section-4.8>.
>
>
>
> The complete Security Considerations paragraph that is the focus of this
> Discuss point is:
>
>
>
>    Because TCP-ENO enables multiple different TEPs to coexist, security
>
>    could potentially be only as strong as the weakest available TEP.  In
>
>    particular, if session IDs do not depend on the TCP-ENO transcript in
>
>    a strong way, an attacker can undetectably tamper with ENO options to
>
>    force negotiation of a deprecated and vulnerable TEP.  To avoid such
>
>    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
>
>    identical session IDs at both ends after tampering with ENO contents
>
>    in SYN segments.
>
>
>
> That paragraph looks like a reasonable description of the security risk
> and countermeasure, except for the one sentence that Ekr pointed out.
> Here’s a suggested fix:
>
>
>
> OLD
>
>    To avoid such
>
>    problems, TEPs MUST compute session IDs using only well-studied and
>    conservative hash functions.
>
> NEW
>
>    To avoid such problems, TEPs are required to compute session IDs in a
>
>    collision-resistant way based on the TCP-ENO transcript and other
>
>    parameters, as specified in Section 6.
>
>
>
> This also reflects Mirja’s observation that IETF & IESG review will be the
> means of ensuring that this happens, so a “MUST” is not needed here beyond
> the “MUST” in Section 6.  In support of that observation, please be sure to
> make Barry Leiba’s suggested IANA registry policy changes from RFC Required
> to IETF Review.
>
>
>
> LGTM.
>
>
>
> -Ekr
>
>
>
>
>
> Thanks, --David
>
>
>
> *From:* Eric Rescorla [mailto:[e-mail]]
> *Sent:* Sunday, November 12, 2017 2:39 AM
> *To:* Kyle Rose <[e-mail]>
> *Cc:* Black, David <[e-mail]>; The IESG <[e-mail]>;
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* Re: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13:
> (with DISCUSS and COMMENT)
>
>
>
> Sorry, "not an unreasonable desire"
>
>
>
> On Sun, Nov 12, 2017 at 7:21 AM, Eric Rescorla <[e-mail]> wrote:
>
>
>
>
>
> On Sun, Nov 12, 2017 at 7:19 AM, Kyle Rose <[e-mail]> wrote:
>
> On Sun, Nov 12, 2017 at 1:13 PM, Eric Rescorla <[e-mail]> wrote:
> > On Sun, Nov 12, 2017 at 5:08 AM, Black, David <[e-mail]>
> wrote:
> >> - 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.
>
> I think this is actually the issue driving the vagueness of the
> requirement: e.g., if some hypothetical attack against AES-128 reduced
> security by a few bits. The intent, as David suggests, is to prohibit
> the use of something like DES, not to prohibit a 128-bit cipher with
> only (say) 125 bits of security.
>
>
>
> That's not a reasonable desire, but this is an RFC 2119 requirement, so it
>
> really does need to be unambiguous.
>
>
>
> -Ekr
>
>
>
>
>
>
>