Re: [tcpinc] Spencer Dawkins' Yes on draft-ietf-tcpinc-tcpcrypt-08: (with COMMENT)

"Black, David" <David.Black@dell.com> Wed, 25 October 2017 20:52 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 61B5D137C4A; Wed, 25 Oct 2017 13:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.221
X-Spam-Level:
X-Spam-Status: No, score=-2.221 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, RCVD_IN_SORBS_SPAM=0.5, 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=zZ7qYgXC; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=GU9uthAJ
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 29AMWqgycs-c; Wed, 25 Oct 2017 13:52:53 -0700 (PDT)
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 56416139A33; Wed, 25 Oct 2017 13:52:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1508964773; x=1540500773; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=E0UbSyX9uFRC3MCXf/OkLc8WS41A+JbfD46ORshthwg=; b=zZ7qYgXCsQOX9vr6/Z/Ryc4+uVi4b2x5H/DIzVzsOmuU307e2Huf8Lm9 TLxA4ddcLIapoblCOXNvrbt+VIcvSq+8vETS1ZcZP1o7pEK8BayFOCdVU jzu5Ti2Zi+7bZHgtOO8GLHfZIGXQOgsI84bAXmIBxbWCIuL3eTz7S0UI2 E=;
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; 25 Oct 2017 15:52:49 -0500
From: "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; 26 Oct 2017 02:52:48 +0600
Received: from maildlpprd03.lss.emc.com (maildlpprd03.lss.emc.com [10.253.24.35]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v9PKqlEM027424 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Oct 2017 16:52:47 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v9PKqlEM027424
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1508964768; bh=r0ZmNFnEwMpchT/wkuwq+DDwYnk=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=GU9uthAJ5Ga0Xv1Tx/sVJjk/c1pXOIdNCuAHGXTgrXvkMXZrcR9BuFgqf3Gf916t6 bUQRlqbQYgfMcZtB+RQAillE/6MJ4GfLI4ydg5gm8LLN8dqn5rJHq+2rXZuG56rtYq iHvnCOWt7Bw2c1YBFj6IBwyMTQUTVy1hXZI0eN5w=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com v9PKqlEM027424
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd03.lss.emc.com (RSA Interceptor); Wed, 25 Oct 2017 16:50:48 -0400
Received: from MXHUB318.corp.emc.com (MXHUB318.corp.emc.com [10.146.3.96]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v9PKqSxA007753 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 25 Oct 2017 16:52:28 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB318.corp.emc.com ([10.146.3.96]) with mapi id 14.03.0352.000; Wed, 25 Oct 2017 16:52:28 -0400
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-tcpinc-tcpcrypt@ietf.org" <draft-ietf-tcpinc-tcpcrypt@ietf.org>, Kyle Rose <krose@krose.org>, "tcpinc-chairs@ietf.org" <tcpinc-chairs@ietf.org>, "krose@krose.org" <krose@krose.org>, "tcpinc@ietf.org" <tcpinc@ietf.org>
Thread-Topic: Spencer Dawkins' Yes on draft-ietf-tcpinc-tcpcrypt-08: (with COMMENT)
Thread-Index: AQHTTcr7bO+K3tE2M0mDQ+ODa8mu2qL1CSgQ
Date: Wed, 25 Oct 2017 20:52:27 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362FD0DC20@MX307CL04.corp.emc.com>
References: <150896122698.4705.6610152257692277567.idtracker@ietfa.amsl.com>
In-Reply-To: <150896122698.4705.6610152257692277567.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.138]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/bA3JV2UCvtTUtbqGUUG2uAtg6Z4>
Subject: Re: [tcpinc] Spencer Dawkins' Yes on draft-ietf-tcpinc-tcpcrypt-08: (with 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: Wed, 25 Oct 2017 20:52:55 -0000

Hi Spencer,

> Also for my benefit, but somewhat more worrying - is the working group fairly
> confident that a specifying second MTI key management scheme will be possible
> at some point, that does not trip over the problems described in [nist-ecc] and
> can be implemented in kernels, or is conforming to the guidance in [RFC7696]
> going to be problematic? I see Mirja mentioned SEC discussions about only one
> MTI key management mechanism being chosen now, but my question is a little
> different - I'm asking if the situation is likely to improve anytime soon.

Short answer: Yes.

Longer answer: See https://www.ietf.org/mail-archive/web/tcpinc/current/msg01363.html

The draft will be revised to reflect the contents of that message, including a "SHOULD" requirement for a second key exchange mechanism that is not based on a NIST curve.  This approach has been checked with the Security ADs, and they're OK with it.

Thanks, --David


> -----Original Message-----
> From: Spencer Dawkins [mailto:spencerdawkins.ietf@gmail.com]
> Sent: Wednesday, October 25, 2017 3:54 PM
> To: The IESG <iesg@ietf.org>
> Cc: draft-ietf-tcpinc-tcpcrypt@ietf.org; Kyle Rose <krose@krose.org>rg>; tcpinc-
> chairs@ietf.org; krose@krose.org; tcpinc@ietf.org
> Subject: Spencer Dawkins' Yes on draft-ietf-tcpinc-tcpcrypt-08: (with
> COMMENT)
> 
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-tcpinc-tcpcrypt-08: Yes
> 
> 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-tcpcrypt/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I really like this draft, and I can understand it fairly well. I do have some
> questions to go along with my Yes ballot.
> 
> This SHOULD NOT
> 
>   o  "PK_A", "PK_B": ephemeral public keys for hosts A and B,
>       respectively.  These, as well as their corresponding private keys,
>       are short-lived values that SHOULD be refreshed periodically.  The
>       private keys SHOULD NOT ever be written to persistent storage.
> 
> is just begging for some justification as to why this is important enough to be
> a SHOULD NOT, and not important enough to be a MUST NOT. Could you give
> an
> example of a reason why this would be a good idea?
> 
> It's likely that everyone but me knows why
> 
>                 resume[i] = CPRF(ss[i], CONST_RESUME, 18)
> 
> is "18" and not some other integer, but there's no explanation or reference
> that I could find explaining why.
> 
> It would be helpful to explain why
> 
>   In a particular SYN segment, a host SHOULD NOT send more than one
>    resumption suboption,
> 
> is a SHOULD NOT, since it's allowed, so doing so must have some purpose.
> 
> This
> 
>   A host SHOULD NOT initiate more than one concurrent re-key operation
>    if it has no data to send; that is, it should not initiate re-keying
>    with an empty encryption frame more than once while its record of the
>    remote generation number is less than its own.
> 
> is allowed - could you explain why a host would need to violate that SHOULD
> NOT?
> 
> Just for my benefit - Section 8.3 explains why ECDHE using Curve25519 has
> been
> chosen as MTI, but also explains why ECDHE using P-256 has not been chosen
> as a
> second MTI. Is the intention to discourage use of ECDHE using P-256 at all,
> based on the concerns expressed about making it MTI?
> 
> Also for my benefit, but somewhat more worrying - is the working group
> fairly
> confident that a specifying second MTI key management scheme will be
> possible
> at some point, that does not trip over the problems described in [nist-ecc]
> and
> can be implemented in kernels, or is conforming to the guidance in [RFC7696]
> going to be problematic? I see Mirja mentioned SEC discussions about only
> one
> MTI key management mechanism being chosen now, but my question is a
> little
> different - I'm asking if the situation is likely to improve anytime soon.
>