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

Eric Rescorla <ekr@rtfm.com> Tue, 14 November 2017 03:08 UTC

Return-Path: <ekr@rtfm.com>
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 63DD912944C for <tcpinc@ietfa.amsl.com>; Mon, 13 Nov 2017 19:08:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 dT2nCzAR4KnJ for <tcpinc@ietfa.amsl.com>; Mon, 13 Nov 2017 19:08:15 -0800 (PST)
Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881EF128D64 for <tcpinc@ietf.org>; Mon, 13 Nov 2017 19:08:15 -0800 (PST)
Received: by mail-qt0-x235.google.com with SMTP id d9so22389809qtd.7 for <tcpinc@ietf.org>; Mon, 13 Nov 2017 19:08:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K6QSPAcAZBLLiXb5ygnrHBUs3M3v89FFqDldnKXzIWs=; b=sfCnORVuVc+aiTKmyyY1aqPe97cTZVdhR0w2RtneJv9jcp4Hjlflugb0YrwiIBe92Z ybv5V2ArGG4b/UQEBDrIfxdwNUlQHns+6Fk6LhE6396BV8s15RC3nuLzUVdAcCVmr71d xHsQ6Pvt+9j23sFRnqSoEX4A8zMJI/YlAMwa/Y4BaBJ3sNpaCmFl2GzCRTjJoGtmjlIR fVOf7EQFHkegBzc64cYUd5iGXhFzx4o0eAvH51BBEJfufOz6OItlEpgDXrCAw1sTP7F+ jSTlb5naAN9ehadLmgyJYEPoJVMucKZvtFeOeeBLWvBS4m8iWFkUtIXfTql7QV4YVWVh x0JQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K6QSPAcAZBLLiXb5ygnrHBUs3M3v89FFqDldnKXzIWs=; b=PCXxBLIj/B/Pi6bbYaPKmZvighL1H0E3XvoKlGznH6aDtLXksJP4PFG27VyR3re6Y5 UMpFqqBCUU/rwlCfEVuCy5iUOSLZVYEvBZe1WCOEV+wz8wQYk2Q7+HuM7K73ccMXWxpi a5G+K+jReJxd7CMSTGWmtfaYx9eEs+4sf2bua1UKS1DLUEcazYDBav8ipcRTtCHcoEUy v9m9P+VTt+VwO5FZPP9lMc0ZXYNWluhQOIPLh5qOFuHlvUu4fIn8EmG8Mr/AXrzdrMC4 9sXfes4+UfADYnZCcm+iUBSjUsHDz0HqEl9d/c4noV61qSTL1V1V6Gh3N2A9xdZ+xdWE r2jA==
X-Gm-Message-State: AJaThX5GhEL+YtTgEoqITgHSpyNkpgj+EBhI+L7zO3djp0ekvohRIeHn Y2ns86A3+7WG+IYUnqlF5FooZmAqsqP2KOATGgXB9w==
X-Google-Smtp-Source: AGs4zMbE2OVwI4V+4slxRLXHl4gcRPNAiR6ghxCDSjWCKkurpvUqRRocH2GFBN4jTdVy+n+hMn/uaRuEabJgva/bO9Q=
X-Received: by 10.129.172.25 with SMTP id k25mr5667444ywh.155.1510628894616; Mon, 13 Nov 2017 19:08:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Mon, 13 Nov 2017 19:07:33 -0800 (PST)
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FD4FC09@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> <87vaieow9k.fsf@ta.scs.stanford.edu> <CABcZeBPxOaK3DN5u0ohizt8rAQ+tShMuOcdpJBJ-2fmMJuQWgA@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD4FC09@MX307CL04.corp.emc.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 14 Nov 2017 11:07:33 +0800
Message-ID: <CABcZeBNazxnSaRFokk9Jk88F6L9zOYrrjcAbLwwQwKsk2WUvnQ@mail.gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>, "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>
Content-Type: multipart/alternative; boundary="94eb2c1badfca6dc62055de8b2bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/5bLB7T-idDBML1L0D590c0oC8cU>
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: Tue, 14 Nov 2017 03:08:22 -0000

On Tue, Nov 14, 2017 at 11:02 AM, Black, David <David.Black@dell.com> wrote:

> Trying to summarize …
>
>
>
> --[1]-- TEP encryption security strength
>
>
>
> > But what about my proposed wording, which says "permit the use of"
> > instead of "permit the negotiation of"?
>
> Ok, but “permit the ... of” is not needed – “TEPs MUST NOT use” is both
> direct and sufficient.
>
>
>
> […  snip …]
>
>
>
> Beyond that, I concur with this point:
>
>
>
> > 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.
>
>
>
> However, I still think that it’s a good idea to note that 128 bits is the
> preferred lower bound design target for security strength, although that
> can be done without a “SHOULD” keyword– e.g.:
>
>
>
> TEPs MUST NOT use encryption algorithms with a security strength
> [@!SP800-57part1] of less than 120 bits.
>
> TEP designs are encouraged to target a security strength of at least 128
> bits to provide some headroom
>
> above the 120 bit requirement to accommodate possible future attacks that
> remove a few  bits of security
>
> strength without compromising the fundamental security of the encryption
> algorithm.
>

This is fine.


>
>
> --[2]-- Cross-TEP security considerations for "vanity crypto"
>
>
>
> > 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.
>
>
>
> Ekr, Tero and I all appear to think that an RFC 2119 keyword is not
> appropriate here.  Try:
>
>
>
> OLD
>
> To avoid such problems, session IDs SHOULD be computed using
> mainstream, well-studied, conservative hash functions.
>
> NEW
>
> Towards avoiding such problems, security reviewers of new TEPs
>
> are expected to pay particular attention to the security strength and
>
> state of cryptanalysis (including research into possible attacks) of the
>
> session ID hash function, above and beyond checking that the hash
>
> function meets the requirements stated in Section 6.
>

This is fine, though I think "SHOULD" could replace "are expected to"


>
> This proposed text also makes it clear that the concern here is in
> addition to the Section 6 requirements on the hash function.
>
>
>
> --[3]-- IANA registry policy for TEP registry
>
>
>
> At least my suggestion of IETF Review was in part to see whether more
> strict review would be appropriate – that appears not to be the case, so …
>
>
>
> I like Amanda’s suggestion of: “Expert Review with RFC Required”   That
> should result in two security reviews of a new TEP, both of which could
> halt a weak one.  Looking at the Independent Submission track as the “path
> of least resistance” that would be the IETF Security Area (ADs and
> Directorate) as part of RFC publication plus an IANA expert review as part
> of codepoint assignment.  Thank you, Amanda.
>
>
>
> I have to admit that Ekr is right that anyone can do arbitrarily stupid
> things on their own – what we can stop is misuse of IETF’s good name and
> IANA registration in support of that sort of stupidity.
>

Well, ultimately this is a WG decision, but we actually have tried this
approach in TLS and other WGs and it doesn't work well. People grab code
points and we have to deal with that, and we also have to spend a lot of WG
time doing useless vetting when people just want a code point.

-Ekr


>
> Thanks, --David
>
>
>
> *From:* Eric Rescorla [mailto:ekr@rtfm.com]
> *Sent:* Monday, November 13, 2017 3:40 PM
> *To:* David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
> *Cc:* Black, David <david.black@emc.com>; tcpinc@ietf.org; Kyle Rose <
> krose@krose.org>; tcpinc-chairs@ietf.org; Mirja Kuehlewind (IETF) <
> ietf@kuehlewind.net>; The IESG <iesg@ietf.org>;
> draft-ietf-tcpinc-tcpeno@ietf.org
> *Subject:* Re: [tcpinc] Eric Rescorla's Discuss on
> draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
>
>
>
>
>
>
>
> On Mon, Nov 13, 2017 at 6:42 PM, David Mazieres <dm-list-tcpcrypt@scs.
> stanford.edu> wrote:
>
> "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.
>
>
>
> To be honest, I think this document is working too hard in both cases to
>
> try to legislate that people don't do things that we think are bad. The
> bottom
>
> line is that in both cases the boundaries around what we think is OK and
>
> what we think is not are kind of fuzzy (as you illustrate above with
>
> Curve25519). Rather than try to write RFC 2919 language about this,
>
> it would be better to simply describe the consequences of bad choices,
>
> and say that the function must be collision resistant, and stop.
>
>
>
> -Ekr
>
>
>
>
>
>
> > --[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
>
>
>