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

Eric Rescorla <ekr@rtfm.com> Mon, 13 November 2017 02:43 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 B84171287A5 for <tcpinc@ietfa.amsl.com>; Sun, 12 Nov 2017 18:43:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 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_LOW=-0.7, URIBL_BLOCKED=0.001] 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 XOQYTEJIKhps for <tcpinc@ietfa.amsl.com>; Sun, 12 Nov 2017 18:43:29 -0800 (PST)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 4E49E1288B8 for <tcpinc@ietf.org>; Sun, 12 Nov 2017 18:43:14 -0800 (PST)
Received: by mail-yw0-x231.google.com with SMTP id y75so12351638ywg.0 for <tcpinc@ietf.org>; Sun, 12 Nov 2017 18:43:14 -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=Gwd8DOAZSPEzvAmqGh7dVe8G3+sBuz9B1J3D6fvRX2g=; b=soW9IxAQKASZjXRDi8sDHE3/bF9gShKfkQe6Tw7XCVaV9hZwF1nGk6dN21aOwdIldq G3SgvGZiNp3BgAu25JRfvd840ePzhPSdqwL8KMO0L95PEZvYg7uxiKwNEXfB7oJhRMMC dgU6vAqzQxUt9fY+Ne7+I6+mSwAW5yZTZk4IFLCGCq5aShDR0zD/edgtpwcZVVyeKhBM Or7uNIHcvy93nzfIlU2swsx4DjVucN+JvKn3PpBg2e0hHlo36WOTlO+7Fi2l7iMdczcj k9zzbt3xReYd1cJfCmYKGPqCxKef/1tKna40SWLI9zBnspH47iYqTYJ+arffaK9ofkR9 oVdw==
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=Gwd8DOAZSPEzvAmqGh7dVe8G3+sBuz9B1J3D6fvRX2g=; b=G0+LDUo/1Td2NYJg/tDwlB6PC9U4RtZIKsZpHCqWe1KOvUtpzZrwzgV3e8hxB2GxXZ ZiyGq4Ujraqmxb4DUFks5wFuu1IoxGYD5nTG5PkodwrSAUvASWVUW7XjK0sessGP6LnU qOcb0wP/auSj6dcdBqRIwjcX1UlZ1pk+DfSCjev7X7J7tTot0+3d4lNCU12IhssFGZDp ttA3Zeud+TLC+xiqWSK3Mf/t9m4PKKB1ckIEBgubeTe+KfhZrIuIYIjjO7FOmySZ6IdV UTByJN25tXf2oq3BBT4/MpVOa13drk3HL4SU30dHKnrLeFRN2ygDRtZSUf+hszI9nYTA 9E/g==
X-Gm-Message-State: AJaThX4JFWv3co1E2aN/EQJifEBCHeU4rrueioYG7or0FIue0bTKse7m HToalE1RUp80xsBEsZibjmnijU6vgZPK5zVb7t2Vrw==
X-Google-Smtp-Source: AGs4zMavotw/jY/1IgR9jJSW28S9hm/mI1oVmSEUsaHBZSdw/xpga/eOl78WL/T3bPUQPVWn3b7tFM1mkRE4ZmQlC/s=
X-Received: by 10.37.197.209 with SMTP id v200mr1896077ybe.348.1510540993541; Sun, 12 Nov 2017 18:43:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.61.12 with HTTP; Sun, 12 Nov 2017 18:42:32 -0800 (PST)
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FD4BDAB@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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 13 Nov 2017 10:42:32 +0800
Message-ID: <CABcZeBOTWugx7LwN8nZawgG9VCzWAPAn1-y=GB0D5sg5JsybLg@mail.gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: Kyle Rose <krose@krose.org>, The IESG <iesg@ietf.org>, "draft-ietf-tcpinc-tcpeno@ietf.org" <draft-ietf-tcpinc-tcpeno@ietf.org>, "tcpinc-chairs@ietf.org" <tcpinc-chairs@ietf.org>, "tcpinc@ietf.org" <tcpinc@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c146f625706e0055dd43b59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/7rmMKC-4hqPmdDuNsKJcGODmvKU>
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 02:43:32 -0000

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

-Ekr


On Mon, Nov 13, 2017 at 10:41 AM, Black, David <David.Black@dell.com> 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:ekr@rtfm.com]
> *Sent:* Sunday, November 12, 2017 8:59 PM
> *To:* Black, David <david.black@emc.com>
> *Cc:* Kyle Rose <krose@krose.org>rg>; The IESG <iesg@ietf.org>rg>;
> draft-ietf-tcpinc-tcpeno@ietf.org; tcpinc-chairs@ietf.org; tcpinc@ietf.org
>
> *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 <David.Black@dell.com>
> 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:ekr@rtfm.com]
> *Sent:* Sunday, November 12, 2017 2:39 AM
> *To:* Kyle Rose <krose@krose.org>
> *Cc:* Black, David <david.black@emc.com>om>; The IESG <iesg@ietf.org>rg>;
> draft-ietf-tcpinc-tcpeno@ietf.org; tcpinc-chairs@ietf.org; tcpinc@ietf.org
> *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 <ekr@rtfm.com> wrote:
>
>
>
>
>
> On Sun, Nov 12, 2017 at 7:19 AM, Kyle Rose <krose@krose.org> wrote:
>
> On Sun, Nov 12, 2017 at 1:13 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> > On Sun, Nov 12, 2017 at 5:08 AM, Black, David <David.Black@dell.com>
> 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
>
>
>
>
>
>
>