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

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

Hi David,

Separating and labelling topics ...

--[1]-- TEP encryption security strength

> First, I'm not sure I understand your criticism about permit
> the negotiation, as we would expect most TEPs to engage in some sort of
> cipher suite negotiation.  

This is entirely editorial about word choice - "permit the negotiation" sounds like a runtime requirement to me, whereas this section is entirely design requirements.  Using "support" instead of "permit the negotiation of" is among the ways to make this clearer, IMHO.

> Second, why make this more complicated with the SHOULD 128?  Can we just have a 120-bit requirement?

I think this is a "show your work" situation.  I'd expect a 120-bit requirement by itself to induce a fair amount of "where did that number of bits come from?" head scratching, starting from the inability to find a 120 bit security strength in SP 800-57.  Independent of wording and keyword choices, there appear to be two things going on:
	a) We want TEPs designed to at least 128 bits of strength.
	b) We're willing to accept a few bits less if necessary, but not many bits less.
I think both need to be stated for clarity, although I'm not attached to the precise words used, e.g., lower case "should" instead of "SHOULD" seems reasonable for the 128 bit design requirement.  One advantage of using a "SHOULD" for the 128 bits of strength is that it invokes RFC 2119's requirement that "the full implications must be understood and carefully weighed before choosing a different course."

--[2]-- Cross-TEP security considerations for "vanity crypto"

> The security considerations paragraph is trying to make a different
> point from the one in section 5.1.  Section 5.1 says you MUST provide
> all this stuff as an input to your hash function.  Section 10 says that
> hash function MUST not be weird "vanity crypto."  In other words, it may
> be reasonable to use vanity crypto for key negotiation or session data
> encryption, because that only affects the security of one TEP.  However,
> the session ID hash function potentially affects *all* TEPs because if
> it's broken, it will permit negotiation rollback attacks to deprecated
> TEPs--even when both sides prefer a more secure TEP.

I would write what is meant/wanted here as opposed to assuming that the rationale behind the MUST will be clear to all future reviewers.

> I want to make clear that the session ID hash function choice
> needs extra scrutiny to prevent this point from being lost on future
> generations of IETF & IESG reviewers.  I don't have to make it a MUST if
> that seems really problematic.  But I also don't just want to reiterate
> the same point as section 5.1, which is I think what your proposed
> language does.

Text along those lines would be clearer, including stating that reviewers are an intended target audience.   Writing that text would be better than discussing the text that I wrote.  Guidance to security reviewers is a fine thing to put in Security Considerations.

--[3]-- IANA registry policy for TEP registry

> Final point:  I only have a tcpcrypt review from Barry Leiba.  Should I
> apply his suggestion of "IETF review" instead of "RFC Required"?  I
> originally wanted "Specification Required" because I thought the
> designated expert review it implied would be sufficient.  Mirja talked
> me up to "RFC Required," which I thought was more strict.  However, does
> the RFC Required not in fact demand any kind of expert review?  (Looking
> at RFC8126, it doesn't seem to.)  I would be perfectly happy with an
> IRTF or Independent Submission stream RFC so long as a designated expert
> agrees the document is not a waste of a code point.

This is somewhat in tension with the previous topic - how much review is sufficient to ensure that a weak TEP doesn't impact the security of all others?  The degree of review increases from Specification Required to RFC Required to IETF Review - if the need to ban potentially flawed vanity crypto hashes in TEPs is serious, then IETF Review seems justified, even though it imposes process costs on getting new TEPs approved.  In all cases, IANA will have a designated expert to advise on the registration, "RFC Required" adds the IESG taking a look, and IETF Review adds a lot more attention from the IETF security community.   More eyes tend to find more things ...

Thanks, --David

> -----Original Message-----
> From: Tcpinc [mailto:[e-mail]] On Behalf Of David Mazieres
> Sent: Monday, November 13, 2017 2:32 AM
> To: Black, David <[e-mail]>; Eric Rescorla <[e-mail]>
> Cc: [e-mail]; Kyle Rose <[e-mail]>; [e-mail];
> Black, David <[e-mail]>; Mirja Kuehlewind (IETF)
> <[e-mail]>; The IESG <[e-mail]>; draft-ietf-tcpinc-
> [e-mail]
> Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13:
> (with DISCUSS and COMMENT)
> 
> "Black, David" <[e-mail]> writes:
> 
> > 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.
> 
> Hi, David.  Thanks for this general approach.  However, I have a couple
> of points.  First, I'm not sure I understand your criticism about permit
> the negotiation, as we would expect most TEPs to engage in some sort of
> cipher suite negotiation.  Second, why make this more complicated with
> the SHOULD 128?  Can we just have a 120-bit requirement?  What about
> the following?
> 
>    o  TEPs MUST NOT permit the use of encryption algorithms with a
>       security strength [SP800-57part1] of less than 120 bits.  The
>       intent of this requirement is to allow the use of algorithms such
>       as AES-128 [AES] that are designed for 128-bit security and still
>       widely considered secure even after losing a few bits of security
>       to highly theoretical attacks.
> 
> If you accept that, then I think the only remaining issues are this from
> your other email:
> 
> > 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.
> 
> The security considerations paragraph is trying to make a different
> point from the one in section 5.1.  Section 5.1 says you MUST provide
> all this stuff as an input to your hash function.  Section 10 says that
> hash function MUST not be weird "vanity crypto."  In other words, it may
> be reasonable to use vanity crypto for key negotiation or session data
> encryption, because that only affects the security of one TEP.  However,
> the session ID hash function potentially affects *all* TEPs because if
> it's broken, it will permit negotiation rollback attacks to deprecated
> TEPs--even when both sides prefer a more secure TEP.
> 
> I want to make clear clear that the session ID hash function choice
> needs extra scrutiny to prevent this point from being lost on future
> generations of IETF & IESG reviewers.  I don't have to make it a MUST if
> that seems really problematic.  But I also don't just want to reiterate
> the same point as section 5.1, which is I think what your proposed
> language does.
> 
> Final point:  I only have a tcpcrypt review from Barry Leiba.  Should I
> apply his suggestion of "IETF review" instead of "RFC Required"?  I
> originally wanted "Specification Required" because I thought the
> designated expert review it implied would be sufficient.  Mirja talked
> me up to "RFC Required," which I thought was more strict.  However, does
> the RFC Required not in fact demand any kind of expert review?  (Looking
> at RFC8126, it doesn't seem to.)  I would be perfectly happy with an
> IRTF or Independent Submission stream RFC so long as a designated expert
> agrees the document is not a waste of a code point.
> 
> Thanks,
> David
> 
> _______________________________________________
> Tcpinc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpinc