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

Daniel B Giffin <> Fri, 17 November 2017 08:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 168D51270AB; Fri, 17 Nov 2017 00:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i-TKQD1McDI7; Fri, 17 Nov 2017 00:56:56 -0800 (PST)
Received: from ( [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D1FB7126CF6; Fri, 17 Nov 2017 00:56:56 -0800 (PST)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id vAH8utWf072037; Fri, 17 Nov 2017 00:56:55 -0800 (PST)
Received: (from dbg@localhost) by (8.15.2/8.15.2/Submit) id vAH8uttG009464; Fri, 17 Nov 2017 00:56:55 -0800 (PST)
Date: Fri, 17 Nov 2017 00:56:55 -0800
From: Daniel B Giffin <>
To: Spencer Dawkins <>
Cc: The IESG <>,, Kyle Rose <>,,
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [tcpinc] Spencer Dawkins' Yes on draft-ietf-tcpinc-tcpcrypt-08: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Nov 2017 08:56:58 -0000

Hi Spencer, I just noticed I didn't address some of these
points you made on a previous draft ...

Spencer Dawkins wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I really like this draft, and I can understand it fairly well. I do have some
> questions to go along with my Yes ballot.
>   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?

Thanks, others have said something similar, and I've made
the requirements more strict.

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

Yes, I realize this is mysterious but not sure it is useful
to explain.  It is a tradeoff between getting a low
probability of resumption-identifier collision, and getting
a low probability of wasted TCP option bytes.

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

You're right.  How about:

   In a particular SYN segment, a host SHOULD NOT send more than one
   resumption suboption (because this consumes TCP option space and is
   unlikely to be a useful practice), and MUST NOT send more than one
   resumption suboption with the same TEP identifier.  But in addition

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

You're right, I don't think there is any reason to allow it.
I've changed to MUST.

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

The intention is to not burden every implementor with the
requirement to implement algorithms (the NIST ones) that can
be difficult to handle correctly; and otherwise to let
implementors and administrators make their own decisions.

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

(David Black has addressed this.)

Thanks for your review!