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

Kyle Rose <> Tue, 28 November 2017 22:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E18A91287A7 for <>; Tue, 28 Nov 2017 14:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aC_7LV7LFfSi for <>; Tue, 28 Nov 2017 14:55:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 35AED1286B1 for <>; Tue, 28 Nov 2017 14:55:17 -0800 (PST)
Received: by with SMTP id d141so2039399qkc.12 for <>; Tue, 28 Nov 2017 14:55:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tUvJC8jRsDHqFFOmnYaUUNS9TyaisVMyoGDLUuvMxSA=; b=R7MJxfPYu5oOdwWrHZWfhC+fiNkeHK+0HDncDDboD307Fel7fI/TumzJ2cNIaxTWnU pimBnwMfFRfRUQJm01CcDW08MIWqWBlU0JBjW7rOPnFjHwcvrBa8Mwll2lWAjf6WPTrd eEuP+Vu2zAn1k98HdlQzJV7DjATbFtdUgPbdA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tUvJC8jRsDHqFFOmnYaUUNS9TyaisVMyoGDLUuvMxSA=; b=C1LOUqudB1gOWcVkkRGYOA28645IapLWNHZMIkj0YKp3xp+vZE1OuCPdSEIV9npmFW QBhSF0WQLyuOM5dwBby2CxTQf4zcJcro9dwDS0fjrEZN8qW1MiEw8J+LVwHC/xaW84ON UC9MXPn9KTwWlyo/UShjzmNz0lsSvJ2GiEkkyILJ2xn+e62RoXfgR+mDj2C7hXo1L4B9 zD2l5k9W2CTmE5bIaYFZbfHmO9Fq661109Nh+Xls93801e4GdLnePaiLJ0admGJ7DDNw 6y11G3SLtL2R5+CIMM5k4Fs5M8MYIEhGXkKlPqRyeBLQk5KbdhxssIei07mSNKlW52M1 rfTQ==
X-Gm-Message-State: AJaThX5QjNXLQtpStCjI43xbWGBmm7vG5YC1EVfJKQhmqdoFzOWgT4wF iQjlkpsPAQ4ZTQ57Q9GSlw8VmZW61aI0XAMgKHFLgA==
X-Google-Smtp-Source: AGs4zMZR2kDwvE7NCZdbiQFR3BK6RkwkMbfubFGcAGVsanJYcxAFKCMWLc2dzfTOIepbJ/Tki4iJ9TvQllx23tmEHfo=
X-Received: by with SMTP id q23mr1370613qkl.9.1511909716105; Tue, 28 Nov 2017 14:55:16 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Nov 2017 14:55:15 -0800 (PST)
X-Originating-IP: [2001:4878:a000:3000:f143:6030:9417:1207]
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Kyle Rose <>
Date: Tue, 28 Nov 2017 17:55:15 -0500
Message-ID: <>
To: Daniel B Giffin <>
Cc: "Black, David" <>, Eric Rescorla <>, tcpinc <>, "" <>, The IESG <>, "" <>, David Mazieres expires 2018-01-14 PST <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and 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: Tue, 28 Nov 2017 22:55:21 -0000

On Tue, Nov 28, 2017 at 5:38 PM, Daniel B Giffin <> wrote:
> Yes.  It makes sense that whenever you send a TEP identifier
> (by itself or for resumption, even if you use some
> yet-unspecified resumption-request format), you are willing
> to do fresh key exchange with that TEP.  Thus I have added
> this to section 3.5. Session Resumption:
>    If a passive opener receives an ENO suboption with a TEP identifier
>    and "v = 1", but the suboption data does not have length 9 bytes, it
>    MUST behave as if the same TEP had been sent with "v = 0".  That is,
>    the suboption MUST be interpreted as an offer to negotiate fresh key
>    exchange with that TEP.

Right, I was just pointing out that we want to keep this change even
if we decide not to make further changes to resumption at this time.

>> Do we want an extra frame in/after the INIT
>> messages for sending version-specific data on the first flight that
>> old receiver versions will simply ignore (beyond including it in the
>> handshake transcript), to avoid an extra RTT for version negotiation?
> Because the new "version" byte would be the first byte sent
> in each direction, it can be used to negotiate any future
> protocol behavior to follow that byte.

You need both because you need to know that the INIT message you send
will be accepted by the receiver before you know which version(s) it
supports (i.e., on the first flight). That said, I had forgotten that
the protocol already has this property, as you pointed out:

> Even without the version byte, the Init1/Init2 messages
> already reserve trailing space for future uses, which
> implementations of the current protocol are instructed to
> ignore (although it is always part of the transcript).

If we decide to make use of that space in a future version, we'll need
to come up with a structure with intrinsic backward compatibility for
version fallback... but that's a conversation for another time. :-)