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

"Black, David" <David.Black@dell.com> Sun, 12 November 2017 05:08 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 B1A3D127599; Sat, 11 Nov 2017 21:08:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=YHMAvkHk; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=RS0+NbG5
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 IRl_Cs1XlFqk; Sat, 11 Nov 2017 21:08:33 -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 914F7126C0F; Sat, 11 Nov 2017 21:08:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1510463313; x=1541999313; h=from:cc:to:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TWRYqeUb4v1twzpZCH7tcQRJMp0FGwtsYEuhWVT4Ofw=; b=YHMAvkHk3ir1P9ATKwpyPmJZNEBS91Qk1yHyeVHtZkxIr9zsWGz1zZOM WX+Ip/J/TcjuR1lLpnH4DbBeFUe8IrpZUuQTFyh0IwDS5dnUBqUKdYmpI Fr59lXOvuivnO6VKMTKweezXvw8ZmKp/3kXz/c3QiTXb6kM9PiocnRbF5 s=;
IronPort-PHdr: =?us-ascii?q?9a23=3AjF8IrhTTLAUmEn50zHQ2HE+CTtpsv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa67ZB2At8tkgFKBZ4jH8fUM07OQ6PGwHzRYqb+681k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRo?= =?us-ascii?q?LerpBIHSk9631+ev8JHPfglEnjSwbLdxIRmssQndqtQdjJd/JKo21hbHuGZDdf?= =?us-ascii?q?5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXM?= =?us-ascii?q?TRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlD?= =?us-ascii?q?kIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWGhPUdtLVyFZAo2y?= =?us-ascii?q?cZYBD/YPM+hboYnypVoOogexCwajH+7v1iRHi3vq0aEmz+gsEwfL1xEgEdIUt3?= =?us-ascii?q?TUqc34OKkPXOCx1qbH0TbDY+tL0jnz8ofIbBEhruyCUbltdsffx1MgFx3EjlqN?= =?us-ascii?q?s4DoIjeV2f4RvGiY9OdvSPygi2ojqw1rvjevwcIsh5DPi4kIxF7E8iB5z5w0Jd?= =?us-ascii?q?2+UEN7YMCrEIdety2AMIt2WMwiTmd1syg50r0LoZ+2cSsQxJg5yRPTdeaLf5WI?= =?us-ascii?q?7x/sTuqcJTN1iGp4dL6jnRq//0mtxvfzW8WqylpHrS5InsHCtn8T1BHf9s2KR/?= =?us-ascii?q?5+80qu3TuP2QXe5+FZLk8ui6bWLoMtzqMrmZcWvknOECz7lUXwgaSLbEsr4PKo?= =?us-ascii?q?5P7iYrj+o5+cMJJ7hR/mP6Q1n8y/Hfw4Mg8TX2iH4ei81KPs/Un+QLhSkPI2ib?= =?us-ascii?q?PWvZHAKcsGuKG5BwtV3p8k6xaiEzepy9MYnWQBLF1YZh6LlYnpO0nOIPD9Avaz?= =?us-ascii?q?mUijkDBux/zeP73hBIvCLmTbnbrgfrtx8VBQxQQtwdxF+p5ZCr4MLOj3V0L1rN?= =?us-ascii?q?DYCwU2Mw2ww+bpEtV90YYeVHqBDKCDLqPSsEKH6vgyLumIfoAapDX9JuM46PHw?= =?us-ascii?q?iX85nUURcrWu3ZsScHy4BOhpI12FYXrwhdcMCXsKsRYmTOzrjl2NTSVeZ3esUK?= =?us-ascii?q?Ig6DE3EoWmDZ3MRoq1mryOwD+7HoFKZmBBEl2MDWvnd52FW/cKdC2eO9Nukjwe?= =?us-ascii?q?WrigUY8hzgqjtA7kxLp7IOrY4CoYtYjs1NJt/e3ciQky9SBoD8Say2yCUnt0kX?= =?us-ascii?q?kGRz8qxax/oFJyykuN0aRhn/xXCcRT5/JPUggmLJLc0/B1C8jsVQLHedeEU1em?= =?us-ascii?q?Tcu6ATE/VN4xxMUOY0llEdW4kh/DxzaqA6MSl7GTBZw77Lnc33fqKsZ81XnGyK?= =?us-ascii?q?chg0MhQstVOm31zpJ4oiXJBoWBqUiCnKGwca1UiCPO7k+Z0WSL+kpfVVg0GZnF?= =?us-ascii?q?UDg+S3D55YD461jNZ76jFbphNRFOn52sMKxPP5fDiVxNR7OrFN3AYm770zOcDA?= =?us-ascii?q?iJyvWmaIPheE0R0SHZTkMDllZArj69KQEiC3L58CrlBzt0GAeqOhu0/A=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HkAABS1gdah2Oa6ERbHAEBAQQBAQoBA?= =?us-ascii?q?YJmgTNuJweDd5tFllAQgT5DCiOFGAIahCxAFwEBAQEBAQEBAQECEAEBAQoLCQg?= =?us-ascii?q?oL4I4JAENRyEFBgEBAQEBASYBAQEBAQEBAQEBAQEBAQEBAQEXAj0BEgIYAQEBA?= =?us-ascii?q?wEjBA0MHxoBBAcEAgEIDgMEAQEDAgYdAwICAjAUAQgIAgQBEgiKEggBD6pZgW0?= =?us-ascii?q?6gxCHdgEBAQEBAQEBAQEBAQEBAQEBAQEBARUDBYEPgiEEgQ4oMCGBVoFogyqEZ?= =?us-ascii?q?AESASGDEzGCMooyl3cGAodpjy6GCIQEhyGMaIkPAgQCBAUCGoE5IAGBOlYZel6?= =?us-ascii?q?CZIJbEQwZgU53AYg9gSSBEQEBAQ?=
X-IPAS-Result: =?us-ascii?q?A2HkAABS1gdah2Oa6ERbHAEBAQQBAQoBAYJmgTNuJweDd5t?= =?us-ascii?q?FllAQgT5DCiOFGAIahCxAFwEBAQEBAQEBAQECEAEBAQoLCQgoL4I4JAENRyEFB?= =?us-ascii?q?gEBAQEBASYBAQEBAQEBAQEBAQEBAQEBAQEXAj0BEgIYAQEBAwEjBA0MHxoBBAc?= =?us-ascii?q?EAgEIDgMEAQEDAgYdAwICAjAUAQgIAgQBEgiKEggBD6pZgW06gxCHdgEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARUDBYEPgiEEgQ4oMCGBVoFogyqEZAESASGDEzGCMoo?= =?us-ascii?q?yl3cGAodpjy6GCIQEhyGMaIkPAgQCBAUCGoE5IAGBOlYZel6CZIJbEQwZgU53A?= =?us-ascii?q?Yg9gSSBEQEBAQ?=
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; 11 Nov 2017 23:08:32 -0600
From: "Black, David" <David.Black@dell.com>
Cc: "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; 12 Nov 2017 11:08:31 +0600
Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vAC58U6U022758 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 12 Nov 2017 00:08:30 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com vAC58U6U022758
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1510463310; bh=DY7eMZ0nugQogEFGzsc24jOWu7o=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=RS0+NbG5A7MYMueqMQkdB++3buzvGA7r047piG/rI+2hMPnl+s9iL0ULc3WLS+dVH lQZkpClYad2YeVhoaSjdUDDJ9kg7HU6YWWSvD5VwGgbEjeolRK2d7WenwggCzzSswP 9+desNlCDRvyAHORQ/6hd0hPZCoOnL9k/1LbSaqs=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com vAC58U6U022758
Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd04.lss.emc.com (RSA Interceptor); Sun, 12 Nov 2017 00:08:24 -0500
Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vAC58P5G018187 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Sun, 12 Nov 2017 00:08:25 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0352.000; Sun, 12 Nov 2017 00:08:24 -0500
To: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>
Thread-Topic: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
Thread-Index: AQHTWpFI+r6/uZGf7EaERFdyZEp+YKMQLzow
Date: Sun, 12 Nov 2017 05:08:23 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362FD495EF@MX307CL04.corp.emc.com>
References: <151036581280.449.10740505473540594433.idtracker@ietfa.amsl.com>
In-Reply-To: <151036581280.449.10740505473540594433.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.36.42.89]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/5gg9yuWs89_jHpqzVXDgK3BOhbc>
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: Sun, 12 Nov 2017 05:08:36 -0000

Hi Ekr,
[writing as draft shepherd]

Let's see if the two of us can find some time in Singapore to talk about the two crypto algorithm Discuss points (encryption and secure hash), as (IMHO) the authors' intentions are good:

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

- Secure Hash: The intent is - don't use vanity crypto.  Does the Security Area have some text that could just be copied to say that?

On URG handling, the Discuss point is:

> IMPORTANT: This actually seems to be a bit confusing about how to
> handle URG. Consider TCP-use-TLS, you would just process URG in the
> normal way and then generate errors if URG causes reordering at the
> TLS layer. This seems like a reasonable procedure but is at least
> arguably prohibited by this text.

I'm confused, as the only "MUST" requirement on URG handling is:

   o  TEPs MUST prevent corrupted packets from causing urgent data to be
      delivered when none has been sent.

Surely TCP-use-TLS meets that requirement ;-).   Beyond that, the list of implementation techniques that follows uses "MAY" twice, and is not intended to be comprehensive.  Would stating that the list of implementation techniques is not comprehensive suffice, or is something else causing heartburn here?

Thanks, --David

> -----Original Message-----
> From: Eric Rescorla [mailto:ekr@rtfm.com]
> Sent: Friday, November 10, 2017 9:04 PM
> To: The IESG <iesg@ietf.org>;
> Cc: draft-ietf-tcpinc-tcpeno@ietf.org; Black, David <david.black@emc.com>;;
> tcpinc-chairs@ietf.org; Black, David <david.black@emc.com>;; tcpinc@ietf.org
> Subject: Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS
> and COMMENT)
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-tcpinc-tcpeno-13: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
>    o  TEPs MUST NOT permit the negotiation of any encryption algorithms
>       with significantly less than 128-bit security.
> IMPORTANT: I don't know what "significantly means". I wouldn't be
> making a point of this, but it's phrased as a normative requirement,
> so I don't know what conformance means.
> 
> 
> IMPORTANT: This actually seems to be a bit confusing about how to
> handle URG. Consider TCP-use-TLS, you would just process URG in the
> normal way and then generate errors if URG causes reordering at the
> TLS layer. This seems like a reasonable procedure but is at least
> arguably prohibited by this text.
> 
> 
>    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
> 
> IMPORTANT: this also does not seem to be unambiguous.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 
>    4.  Provide a standard negotiation transcript through which TEPs can
>        defend against tampering with TCP-ENO.
> 
> This was unclear to me when I first read this. Maybe
> "Export a standard negotiation transcript to TEPs which they can use to
> defend
> against"
> 
>    opportunistically.  It uses a new TCP option kind to negotiate one
>    among multiple possible TCP encryption protocols or TEPs.  The
>    negotiation involves hosts exchanging sets of supported TEPs, where
> Nit: I would say "one TEP out of multiple"
> 
> Also, "TCP encryption protocols or TEPs." is confusing. If you feel the need to
> redefine, do "TCP encryption protocols (TEPs)"
> 
>    variable-length data.  When "v = 0", the byte itself constitutes the
>    entirety of the suboption.  The 7-bit value "glt" expresses one of:
> I would say "the remaining 7-bit value, called "glt", may take on various
> meanings, as defined below"
> 
>    "b = 0" plays the "A" role.  The host that sent "b = 1" plays the "B"
>    role.
> This would be clearer if it (a) explained the reasoning and (b) appeared before
> the packet formats. Perhaps something like
> 
> "Because the passive opener MUST set b=1 and the active opener by default
> sets
> b=0, the normal cases is that the active opener is A and the passive opener is
> B. Applications which depend on simultaneous open and have some other
> way of
> breaking the tie can set one side to b=1 (even though it is the active opener)
> and thus arrange for correct role assignment. Otherwise, simultaneous opens
> will fail"
> 
>    If both sides of a connection set "b = 1" (which can happen if the
>    active opener misconfigures "b" before calling "connect"), or both
>    sides set "b = 0" (which can happen with simultaneous open), then
> Why is this "misconfigures"? You allow them to do so.
> 
>    initial suboption byte (see Figure 4).  By default, suboption data
>    extends to the end of the TCP option.  Hence, if only one suboption
>    requires data, the most compact way to encode it is to place it last
> Why is this "by default"? It just seems like another setting of glt.
> 
>    connection or when there is any ambiguity over the meaning of the SYN
>    data.  This requirement applies to hosts that implement ENO even when
>    ENO has been disabled by configuration.  However, note that
> I think you may mean to say "when the last SYN TEP is not eventually
> negotiated"
> 
>    o  TEPs MUST NOT depend on long-lived secrets for data
>       confidentiality, as implementations SHOULD provide forward secrecy
>       some bounded, short time after the close of a TCP connection.
> Maybe "depend solely" because one might want to use a DH mode where a
> static DH
> key is mixed in with an ephemeral.
> 
>       probability detect a FIN flag that was set or cleared in transit
>       and does not match the sender's intent.  A TEP MAY discard a
>       segment with such a corrupted FIN bit, or may abort the connection
> What is "high probability"
> 
>       that disable urgent data by default.  The exception is when
>       applications and protocols are known never to send urgent data.
> 
>              (4) B -> A:  SYN-ACK  ENO<b=1,X,Y,Z>
>              [rest of connection encrypted according to TEP Y]
> Can you show a=0 in line 1?
>