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

Kyle Rose <> Tue, 28 November 2017 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C645129426 for <>; Tue, 28 Nov 2017 12:01:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 bEUN6-MNfA9V for <>; Tue, 28 Nov 2017 12:01:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFC40129524 for <>; Tue, 28 Nov 2017 12:00:47 -0800 (PST)
Received: by with SMTP id g10so1423294qtj.12 for <>; Tue, 28 Nov 2017 12:00:47 -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=X2XITZtBSasAjRy+mybn3zokWkrBmzZ/gmM/F+znUhU=; b=ln1c9xpfy/8wUKl81053mwUNDJ3ZOjEmjjvI0GRp3FzD5XUZJHogMLg/rPxB7SHuaB 4JySa8f1UdmGJ7416DT/eJEZjvPDwDJwel/JGZb4E6sCwhhgIM+KCwmKcJFcHUk+fui2 /bPp1qpadOGaXhTb9jmOzeFj1BVgUM5KhICQU=
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=X2XITZtBSasAjRy+mybn3zokWkrBmzZ/gmM/F+znUhU=; b=A/A00j2SRBEMOpJZEkZLVxRoAWDx/zpJXUDYT8QYEKnnOxOPiPXR58om5BiAHHdigE pm3q0of9feSOAJYrWnxuug4CuVBuQcJ7QEvtKNf/9zPwu0Weh2tqd9MaMLXZPNsbTQpx dpndfpLfH8TITS6oEza1noDghE1PuFMOB1MqjgLQGuHXsGJjh+8KsY50Qf0bkU9TV61l dX+0kXl1tmt9LVbJ0rp5UhE2XM2Zk70xgHLSxo8iHnfelZC8CiP/9wF3F1dPkFhGFQWo UaEYd+C4dJtvs6XHVhwZFWyF6mmPSoP8XjSdbaTHLN73x/+AmxXmmbuDu3Y51PpAB31U c8Fw==
X-Gm-Message-State: AJaThX6H3qeIztzSiqE7Ip54eMMZtOyi8I+E7bZ1Ma6TyuIYT+LqUBpv uiidGeB5ZbLJaHaBHLergAlcmE+QgZD26T6C7lSoaw==
X-Google-Smtp-Source: AGs4zMYkZoUm1EiACS51LsqSl6tuYEAFwVGBB1n+gaFDh26auVs29Uj8elWQEmWAbU84P8l0UluogU331XGbr4A5Y7g=
X-Received: by with SMTP id a7mr636705qtk.206.1511899246628; Tue, 28 Nov 2017 12:00:46 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 28 Nov 2017 12:00:45 -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 15:00:45 -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 20:01:05 -0000

On Mon, Nov 27, 2017 at 11:11 PM, Daniel B Giffin <> wrote:
> Whether or not we decide to go back to the WG to discuss the
> mechanics of session resumption, we could make lightweight
> changes to the current protocol in this last call that would
> facilitate any "upgrades" that appear necessary after
> deployment has begun.
> To wit, we propose:
>   - Replace the first byte of INIT1_MAGIC and INIT2_MAGIC
>     with a "version" byte.  Implementations of the current
>     protocol must send a zero version-byte, and must ignore
>     what they receive.
>   - When receiving ENO suboptions for tcpcrypt TEPs with
>     v=1, which are "resumption suboptions": if the
>     resumption identifier-half is not the expected length
>     (9 bytes), treat this suboption as a bare TEP byte with
>     v=0; that is, an invitation to fresh key-exchange with
>     that TEP.  This *almost* goes without saying; the
>     current draft doesn't say what to do in this case of
>     "malformatted" resumption identifiers.

Upon reflection, isn't this an oversight? It seems the draft should
address this regardless of how we decide to deal with misuse

> The version byte is intended to allow implementations of
> future protocol versions to identify each other (by sending
> the highest version they support), which then allows them to
> perform "advanced" resumption signaling later.

So is the idea that the format of INIT*_MAGIC would be fixed, and that
the version can only affect subsequent messages? I suppose the
alternative is that we burn a new set of TEPs whenever anything about
the protocol changes, so putting that extensibility directly into
tcpcrypt (where a much less constrained number of signaling bits are
available) makes sense for future proofing, maybe even irrespective of
this particular issue. I'm thinking of some analogy to ClientHello
extensions in TLS, where you can send stuff that the server might not
parse, and that's okay. 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?