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 01:53 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 497F3127843; Sun, 12 Nov 2017 17:53:50 -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=lIu8zF2W; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=S49+YUuW
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 oUrRWhS93BhF; Sun, 12 Nov 2017 17:53:47 -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 94C3212785F; Sun, 12 Nov 2017 17:53:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1510538023; x=1542074023; h=from:cc:to:subject:date:message-id:references: in-reply-to:mime-version; bh=ayoc5SvGNhD3XsrB/WH3L92wf/qOmzBJCnzJDXH2Fkk=; b=lIu8zF2Wy676mA4srzJMD5Qc1e8iVzrbVUNiMDZxcRiO4rd2IhQxIP/k mDD4LaMCwpVL4QecyMB46IEZ7Op0lmlXY4C2G74P0Zx9XTVl4E9o02oo2 4YKzWHQ1F8eM/jDaHcl1eCfhPh7MTAS3hs8lETqE6+7P+kZrOn6mVcgd1 k=;
IronPort-PHdr: 9a23:+UbIvBbfH7N3u2glZ50Fjp7/LSx+4OfEezUN459isYplN5qZps26ZB7h7PlgxGXEQZ/co6odzbGH4+a4ASQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7Ovr6GpLIj8Swyuu+54Dfbx9GiTe5Yr5+Ngm6oRnMvcQKnIVuLbo8xAHUqXVSYeRWwm1oJVOXnxni48q74YBu/SdNtf8/7sBMSar1cbg2QrxeFzQmLns65Nb3uhnZTAuA/WUTX2MLmRdVGQfF7RX6XpDssivms+d2xSeXMdHqQb0yRD+v9LlgRgP2hygbNj456GDXhdJ2jKJHuxKquhhzz5fJbI2JKPZye6XQds4YS2VcRMZcTyxPDJ2hYYsTAeQPPuhYoIv8p1QSohSzHhOjCP/rxzJSmnP6wa833uI8Gg/GxgwgGNcOvWzaoNjoMKcdS/y6zKrQwT7eYf1Zwyn96InVfRwvvPqBWrx+ftDPyUkuCgzJlEidqYj/MDyJ1eQAqHWU4PRkVeKrkWIotwZxoj22y8oql4LHiIUVylXe+iV4xoY4Pdy4R1BnYd6qCpdQsDuaN4RwT8g/QG9ooD43x7wFtJKhYiQHxoorywTCZ/GHfIWE+BbuWeKJLTtlmH5pYryyiheo/UWuyuDwTNS43VRFoyZdnNnDqHMA2wDW58WCSfZw8UOs2TiK2g3T9+5LO144mK/GJ5I82bE9k5UevErAEyL2nkj9kbWYeV8++uey7uTqerDmppiBOIBqkgz+KaEumtCnAeQ/LwgOQ3CX+eSi273n+k30WKtFjuYsnaTYqpzVONoUpqq9AwNM1YYj9gq/ACyh0NQFm3kIMUxJdAiGj4jxO1HOJf/5Ae2jjFSrlTdn3/HGPrv/DZXRNnXOkbTscaxj50NS1gY/181T6pJbB70bJP/+Xlf9tNnCAR84Nwy0zfznCNJ41o4GV2yAGLGZMKLPvlOS++8vJ/ODa5MWuDvmNvcq+frujXsjlVABeqmp2IMbaGqkEfR+P0WZfX3sj88dEWgWpgo+Terqh0GZXD5SeXmyQ6w86is8CIK8AofJXpqtj6CZ3CenAp1WYXhLCkyQHnfwdoWEXesDZDuOLc9hiDMEVKKhS5Q62BGvqgD617RnIvDT+i0CupLpzMJ16PHLlREu6Tx0CNyQ3HyXT25ukGMIWyY63KFhrkxhxFePyLR4jOBAFdxS4fNGTh42NYLAwOxiFd/yXAXBc8yISFm4XtWmDys9TtUrw98Be0x9Acmtjgjf3yq2BL8Yj72LC4Iv8qLTxHXxJthyy2rI1KU7iFkmWMRPZiWagftS7QnYT7TEiE6ejaKjPfAR3zTl7nuNyCyFu0QOFEZTQKHIFUoYfUae+dfj4VjPZ7y0Dq8qdAxbxpjRBLFNb4ijp1FPT/SncPjXfWO90S/kKR+Wx7/KRo7jcGY10CjZDA4PlAVFriXODhQ3Gir0+zGWNzdpD1+6Jhq0qeQ=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2ETAAB7+ghamGOa6ERbGgEBAQEBAgEBAQEIAQEBAYJEIoEjEG4nB4N3ih+PKYF9llCBTkMKI4UYAhqELD8YAQEBAQEBAQEBAQIQAQEBAQEICwsGKC+COCQBDUchBTIBAQEBAQEBAQEBAQEBAQEBAQEXAj0BEgIYAQEBBCMKEx8aAQ8CAQgOAwQBAQEKFgcDAgICMBQJCAIEARIIiTZkAQ+rBYIngxCHdgEBAQEBAQEBAQEBAQEBAQEBAQEBARUDBYMwBIE2UYFWgWiDKoUZDB8Jgl8xgjKLM41miRAGAodpjy6GCIsljGiJDwIEAgQFAhqBOR+CK3pegmQJglIRDBmBTncBin6BEQEBAQ
X-IPAS-Result: A2ETAAB7+ghamGOa6ERbGgEBAQEBAgEBAQEIAQEBAYJEIoEjEG4nB4N3ih+PKYF9llCBTkMKI4UYAhqELD8YAQEBAQEBAQEBAQIQAQEBAQEICwsGKC+COCQBDUchBTIBAQEBAQEBAQEBAQEBAQEBAQEXAj0BEgIYAQEBBCMKEx8aAQ8CAQgOAwQBAQEKFgcDAgICMBQJCAIEARIIiTZkAQ+rBYIngxCHdgEBAQEBAQEBAQEBAQEBAQEBAQEBARUDBYMwBIE2UYFWgWiDKoUZDB8Jgl8xgjKLM41miRAGAodpjy6GCIsljGiJDwIEAgQFAhqBOR+CK3pegmQJglIRDBmBTncBin6BEQEBAQ
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 19:53:42 -0600
From: "Black, David" <David.Black@dell.com>
Cc: 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 07:53:39 +0600
Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vAD1rbjq003826 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Nov 2017 20:53:38 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com vAD1rbjq003826
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1510538019; bh=l2qKDxcdeWlFpHcJleS02ijnB+M=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=S49+YUuWNY9o4k+IZLs81nBrYavIvuXjJFCoUg25WKtrpy20S+mu5kUVeVdLfY53q R4BbEXSNctr/NEZ2t4uVJs2nJTjsyyJ6AANszzHPMDNz+Kyir85tghTR5xDM6NBSir myW4mRBGe6rt623rOLBNYA1D5IHsycUeR/MdKnWE=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com vAD1rbjq003826
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd02.lss.emc.com (RSA Interceptor); Sun, 12 Nov 2017 20:53:20 -0500
Received: from MXHUB320.corp.emc.com (MXHUB320.corp.emc.com [10.146.3.98]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vAD1rO7d000893 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 12 Nov 2017 20:53:24 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB320.corp.emc.com ([10.146.3.98]) with mapi id 14.03.0352.000; Sun, 12 Nov 2017 20:53:23 -0500
To: Eric Rescorla <ekr@rtfm.com>, Kyle Rose <krose@krose.org>
Thread-Topic: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
Thread-Index: AQHTWpFI+r6/uZGf7EaERFdyZEp+YKMQLzowgABZgQCAACMUgIAAAKYAgAAE5YCAANlEoA==
Date: Mon, 13 Nov 2017 01:53:23 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362FD4BB57@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>
In-Reply-To: <CABcZeBNp=1c1cx0+nJezjWy_Q4N9-PUeQuqOU_k7A7KhRj18EQ@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_CE03DB3D7B45C245BCA0D243277949362FD4BB57MX307CL04corpem_"
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/3L4VEuAFZ5XHjvUEBslHoNXbrIY>
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 01:53:50 -0000

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)”

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.

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.

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>; 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)

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