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

"Black, David" <David.Black@dell.com> Mon, 13 November 2017 02:42 UTC

Return-Path: <David.Black@dell.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 74520126C83; Sun, 12 Nov 2017 18:42:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.719
X-Spam-Level:
X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=015z/Rul; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=EdN0dWN3
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 OY1y7lc7wHAm; Sun, 12 Nov 2017 18:41:59 -0800 (PST)
Received: from esa8.dell-outbound.iphmx.com (esa8.dell-outbound.iphmx.com [68.232.149.218]) (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 7EF1F1271DF; Sun, 12 Nov 2017 18:41:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1510540915; x=1542076915; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=ABwzcJpd44mcbjYqztIigxZAhFNWzY0XbOVNbogMwTk=; b=015z/RulmeCYSs5xosst3VnhlF8tjomKuUiiN8T/tnQ+AVrKsiY1rRe5 ijJs6sEkyzIdtzyTTA8IGuDXnpi0fQisiVwVpUl7SR7geFMFcgNCvU0nO W5ao4/TjdE6PuHltTaPc5x2TILt1y0AtbNJtlGCUv/X2I3XqsEOtBAtxP 4=;
IronPort-PHdr: 9a23:FT610xeLVzGeNaa93j0BZeOolGMj4u6mDksu8pMizoh2WeGdxc26YxWN2/xhgRfzUJnB7Loc0qyN4vCmATRIyK3CmUhKSIZLWR4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBxrwKxd+KPjrFY7OlcS30P2594HObwlSijewZbB/IA+qoQnNq8IbnZZsJqEtxxXTv3BGYf5WxWRmJVKSmxbz+MK994N9/ipTpvws6ddOXb31cKokQ7NYCi8mM30u683wqRbDVwqP6WACXWgQjxFFHhLK7BD+Xpf2ryv6qu9w0zSUMMHqUbw5Xymp4rx1QxH0ligIKz858HnWisNuiqJbvAmhrAF7z4LNfY2ZKOZycqbbcNgHR2ROQ9xRWjRBDI2icoUPE+QPM+VWr4b/plsBsRSxCBK2C+/zzjJFnGP60bE43uknDArI3BYgH9ULsHnMotn4KaMSXvqpw6nL1TnIcv1Y1i3j6IjJbx8tr+yHULV+f8XL10kvFh7Kgk+NpIzhJTyayucNvnOG4OV+UeKvj3QrpB12ojiq38ohjJTCiIwSylDB7yp5wYA1KMW5SEFlfd6kHoFctyaAN4t5RM4pXmJmuD4ix7AHupO3ZjYGxZo5yxLFdvCKc4eF7gjnWeuVOTt0mW5pdKixihuz60StxO3xWtOp3FtIoSdJitfMuW4O2hDP78WKT/hw80il1DaB0g3e6vxLLloqmafeNpIt36U/m58cvEnNHSL7mEP7h7KMeEo+4Oin8eHnb63jpp+bKoB7lBnzMr8rmsyjGeQ4NRUOX3SD9eS8yrLj+Ur5Ta1Ugf0tiKbUsYrWKtkFqa69Bw9Zy4Ej6wujDzi919QYgH8HI09bdB6djojpI1HOIPX3DPuln1uslzJry+jHPr3nHJrNMmDOnbbicLpn9UJRxhQ/wcpC659UBbwNOvb+V0vpuNzdFBA5Mgi0w+j9CNV604MTQWyBDbWHMKPTrFCE/P8iI+2Wa4AJuzbwMOUq6ODqjX89g1MSYa6p3Z4PZHCiAvtmO1mZYWbrgtoZDWcFohI+TO3siFKeSjNTZmi9X74y5j0hD4KmF4jDTJi3gLOdxCe7AoFWZmdeB1CQDXjob4SEW/EQZy6LPsBhkiYLVbm7S486zhyutRH1y6ZpLubO/S0Yr53j3sBv5+LPjREy6SB0D8OF3m6QVWF7hG0IRyMv0KB+v0N91lmD3bFkg/NEDdxT5vVJXRsjOZ7A0+N6E879WgTGftqSSVapXMmmAT8rQtI22d8ObF53G8++gRDbwyqqH7gVmqSKBJMq6aLc0GP8J8djxHba2qktlV4mQtFANT7uuqkq2hLSDMbznl6SkLyufOxI0S3X3H2fw2/It0ZdBl1eS6LACDo1YkLdrpCxykrcTrPkQeALOxVAxYioLqJBafXlgFFCAvzkPYKNMCqKh26sCEPQlfu3Z43wdjBYhX2FBQ==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2FbAAAwBglamGOa6ERbGgEBAQEBAgEBAQEIAQEBAYJEIiGBAhBuJweDd5lIgX2WUIFOQwojhRgCGoQsQBcBAQEBAQEBAQEBAhABAQEBAQgLCwYoL4I4JAENRyEFMgEBAQEBAQEBAQEBAQEBAQEBARcCPQESAQEYAQEBAQIBIwoTHxoBBAsCAQgOAwQBAQEKFgEGAwICAjAUCQgCBBMIiTZcCAEPqwyCJ4MQh3YBAQEBAQEBAQEBAQEBAQEBAQEBAQEVAwWDMASBNlGBVoFogyqFGQwfCYIiPTGCMoszjWaJEAYCh2mPLoYIiyWMaIkPAgQCBAUCGoE5IAGCKXpegmQJglIRDBmBTncBh0WBEQEBAQ
X-IPAS-Result: A2FbAAAwBglamGOa6ERbGgEBAQEBAgEBAQEIAQEBAYJEIiGBAhBuJweDd5lIgX2WUIFOQwojhRgCGoQsQBcBAQEBAQEBAQEBAhABAQEBAQgLCwYoL4I4JAENRyEFMgEBAQEBAQEBAQEBAQEBAQEBARcCPQESAQEYAQEBAQIBIwoTHxoBBAsCAQgOAwQBAQEKFgEGAwICAjAUCQgCBBMIiTZcCAEPqwyCJ4MQh3YBAQEBAQEBAQEBAQEBAQEBAQEBAQEVAwWDMASBNlGBVoFogyqFGQwfCYIiPTGCMoszjWaJEAYCh2mPLoYIiyWMaIkPAgQCBAUCGoE5IAGCKXpegmQJglIRDBmBTncBh0WBEQEBAQ
Received: from esa6.dell-outbound2.iphmx.com ([68.232.154.99]) by esa8.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2017 20:41:36 -0600
From: "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>, "Black, David" <David.Black@dell.com>
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2017 08:41:22 +0600
Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vAD2fJb2017478 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Nov 2017 21:41:21 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com vAD2fJb2017478
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1510540882; bh=3Q3Rgzb1SXAK+sc9CkvFlHi3ADo=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=EdN0dWN3z2+y0G2Od9FDw6WJrD2rqdkZEA88T3iuXsqYGy15hGZXVnBhlyhp7MtHP S9QseCxCREzXyhczxZWTnEx9srojxQ/ZskIa5bGtLxuVllmO8Hh/2Z3MQPVlE5QjDP phfi+kniYTMyTTD88qAhVe9SUg7ZuU+f77yrYlik=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com vAD2fJb2017478
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd03.lss.emc.com (RSA Interceptor); Sun, 12 Nov 2017 21:41:11 -0500
Received: from MXHUB306.corp.emc.com (MXHUB306.corp.emc.com [10.146.3.32]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vAD2fBTq030875 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sun, 12 Nov 2017 21:41:12 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB306.corp.emc.com ([10.146.3.32]) with mapi id 14.03.0352.000; Sun, 12 Nov 2017 21:41:11 -0500
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
Thread-Index: AQHTWpFI+r6/uZGf7EaERFdyZEp+YKMQLzowgABZgQCAACMUgIAAAKYAgAAE5YCAANlEoIAAWgoA//+w/FA=
Date: Mon, 13 Nov 2017 02:41:10 +0000
Message-ID: <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>
In-Reply-To: <CABcZeBPL2mVFtsL77Bdr=BUf7cb+qe_+Wxq42AtoohHmSmJaCg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.36.35.174]
Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FD4BDABMX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/kstMSPbflMvaPMAJcS1SZn50hVI>
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:42:09 -0000

> > 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>; The IESG <iesg@ietf.org>; 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<mailto: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<mailto:ekr@rtfm.com>]
Sent: Sunday, November 12, 2017 2:39 AM
To: Kyle Rose <krose@krose.org<mailto:krose@krose.org>>
Cc: Black, David <david.black@emc.com<mailto:david.black@emc.com>>; The IESG <iesg@ietf.org<mailto:iesg@ietf.org>>; draft-ietf-tcpinc-tcpeno@ietf.org<mailto:draft-ietf-tcpinc-tcpeno@ietf.org>; tcpinc-chairs@ietf.org<mailto:tcpinc-chairs@ietf.org>; tcpinc@ietf.org<mailto: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<mailto:ekr@rtfm.com>> wrote:


On Sun, Nov 12, 2017 at 7:19 AM, Kyle Rose <krose@krose.org<mailto:krose@krose.org>> wrote:
On Sun, Nov 12, 2017 at 1:13 PM, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:
> On Sun, Nov 12, 2017 at 5:08 AM, Black, David <David.Black@dell.com<mailto: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