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

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Mon, 13 November 2017 18:42 UTC

Return-Path: <dm-list-tcpcrypt@scs.stanford.edu>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A503129B40; Mon, 13 Nov 2017 10:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9LBXXGy7Z9O; Mon, 13 Nov 2017 10:42:49 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC514129B38; Mon, 13 Nov 2017 10:42:48 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id vADIglSJ068357; Mon, 13 Nov 2017 10:42:47 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id vADIgl4M007107; Mon, 13 Nov 2017 10:42:47 -0800 (PST)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: "Black\, David" <David.Black@dell.com>, Eric Rescorla <ekr@rtfm.com>
Cc: "tcpinc\@ietf.org" <tcpinc@ietf.org>, Kyle Rose <krose@krose.org>, "tcpinc-chairs\@ietf.org" <tcpinc-chairs@ietf.org>, "Mirja Kuehlewind \(IETF\)" <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, "draft-ietf-tcpinc-tcpeno\@ietf.org" <draft-ietf-tcpinc-tcpeno@ietf.org>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FD4D450@MX307CL04.corp.emc.com>
References: <151036581280.449.10740505473540594433.idtracker@ietfa.amsl.com> <CE03DB3D7B45C245BCA0D243277949362FD495EF@MX307CL04.corp.emc.com> <CABcZeBPfk6Pi=_UPvTBaS9jQBYjExUdqkdX5Q--iUuyCv_qZtw@mail.gmail.com> <CAJU8_nWpVhm4oTT+SLyG-nk=ww7nBU-DaVe86rUU-LGGqJvHvQ@mail.gmail.com> <CABcZeBO0TD0KnpTfe6CbHUoiS=FmGiGW6r_mFMH_9bYFWKqKLA@mail.gmail.com> <CABcZeBNp=1c1cx0+nJezjWy_Q4N9-PUeQuqOU_k7A7KhRj18EQ@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD4BB57@MX307CL04.corp.emc.com> <CABcZeBPL2mVFtsL77Bdr=BUf7cb+qe_+Wxq42AtoohHmSmJaCg@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD4BDAB@MX307CL04.corp.emc.com> <877euu7hy0.fsf@ta.scs.stanford.edu> <CE03DB3D7B45C245BCA0D243277949362FD4D450@MX307CL04.corp.emc.com>
Date: Mon, 13 Nov 2017 10:42:47 -0800
Message-ID: <87vaieow9k.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/ahBCSyCDjV3_5nIOIh6QklUr-oU>
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Nov 2017 18:42:50 -0000

"Black, David" <David.Black@dell.com> writes:

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

But what about my proposed wording, which says "permit the use of"
instead of "permit the negotiation of"?

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

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

The proposed language explains the rationale.

Also, I'm not sure I agree that 128 bits are better than slightly fewer.
For example, tcpcrypt's MTI DH curve is curve25519.  If memory serves,
aren't the private keys for that something like 123 bits, because you
are supposed to fix the top bits as 01 and bottom as 000 or something?
It still seems like a perfectly fine choice of algorithm.  All else
equal, given implementation considerations, I think we might be more
likely to see mainstream 127-bit keys than 129-bit keys, and I'd rather
people choose algorithms with more scrutiny.  When you are dealing with
such small bit length differences, the constant factors and amount of
human scrutiny against a big break are more important.

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

Obviously that is not coming through to readers, but that was the intent
of the language.  E.g.:

        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.

What about:

Because TCP-ENO enables multiple different TEPs to coexist, security
could potentially be only as strong as the weakest available TEP.  In
particular, if TEPs use a weak hash function to incorporate the TCP-ENO
transcript into session IDs, then an attacker can undetectably tamper
with ENO options to force negotiation of a deprecated and vulnerable
TEP.  To avoid such problems, session IDs SHOULD be computed using
mainstream, well-studied, conservative hash functions.  That way, even
if other parts of a TEP rely on more esoteric cryptography that turns
out to be vulnerable, it is still intractable for an attacker to induce
identical session IDs at both ends after tampering with ENO contents in
SYN segments.

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

As long as "RFC required" involves a designated expert, that would be my
preference.  It's also what I think we arrived at after a bunch of
discussion with Mirja.  I don't think the choice of conservative hash
function requires more than a designated expert review, because it's not
controversial or hard to check.  So is the status quo okay on this
point?

David