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

Eric Rescorla <> Mon, 27 November 2017 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65DA61270FC for <>; Mon, 27 Nov 2017 07:08:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id clwsF8k_lHWF for <>; Mon, 27 Nov 2017 07:08:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 964F912711D for <>; Mon, 27 Nov 2017 07:08:31 -0800 (PST)
Received: by with SMTP id x72so10664833ybg.11 for <>; Mon, 27 Nov 2017 07:08:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qD22iBYQZFI1TAfl/Nv3y6/woiVG9SomNi38Ui5XFh0=; b=khy2obOMXclzYPI1/CQFkd9nmQ5F3OdnHKGHDAXfXo023X732fPzYX8YFith16XbBV WTklKKbmmvY31eUfq12AiBnYXpJDWHUF691FRFP+LQsBBRmOFEfSly1f1Xz9JjcuAgpq fkfUKZXgeLWaI+3BKDOPkUZjXtfiaERgmNMqAWio8ZOdCax5t+9XhNp0jnsp4+xp+vJ6 MVcD9yQ3/7v2O3WRfjULPJEKNa/KviF+eVnAoLEWqdWtCYua5cPMp2UIOudEJoY2/vwB kh1XH2A9/qEb98kowBLuSFdR/uLg5t2KJqIRbt/z+3ueLP2Zauk4wcfikM++hdaS6toI IUrw==
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=qD22iBYQZFI1TAfl/Nv3y6/woiVG9SomNi38Ui5XFh0=; b=fhxU2KyI8zZvCulCa+d9kyYx+pIgTWT9NvvQQ1LZfTXHYCQDgWUByP08j2iRcweOY8 m/PfQxBiwbFg3QXsh8Xjb+fj+QTY2S/Aoe2sVUwWOymLD24e/4+IFT6GuD3F38xTRAva k7s/PAOsNrqKru8/zUO9uzY95NH1RQ38ZVEMcUSBvTAsDKlelA5Qv4QrYJLk4q+m9f0D ddrgdQ/9NLc7Esb4GJ32E8ZrOfxmAuE19aEsB8V/i3kz3L0WVyTd4iUgbmhDzClWrr+5 7Ir6OrMnl/5YXrSu8yqdMKWASrY1O1s2j0TDvgbqIWXH4Q8c76Hapbd9WddWfR4yIFdd uaBQ==
X-Gm-Message-State: AJaThX5phrEzkJDQXA79IdyXY6AToB/oXg3x5BpbF6b+1UXPO7uT0U5T wxCqklKXn8O5lS2VPSWcn2XsHyPs23upwUuE9iL09A==
X-Google-Smtp-Source: AGs4zMY84U5o+Gf05t6GoPKYritm0iOd//L/E5XiO+KMmBjaRuw61ruSj8t7EqgofIQ5bcWIangObVswsBsDgeIfuA8=
X-Received: by with SMTP id 128mr4029911ybq.474.1511795310697; Mon, 27 Nov 2017 07:08:30 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 27 Nov 2017 07:07:49 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 27 Nov 2017 07:07:49 -0800
Message-ID: <>
To: Kyle Rose <>
Cc: Daniel B Giffin <>, "Black, David" <>, tcpinc <>, "" <>, The IESG <>, "" <>
Content-Type: multipart/alternative; boundary="001a11c0125a77b2bc055ef846cf"
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: Mon, 27 Nov 2017 15:08:35 -0000

On Mon, Nov 27, 2017 at 5:36 AM, Kyle Rose <> wrote:

> On Fri, Nov 24, 2017 at 1:33 PM, Eric Rescorla <> wrote:
> > Well, there are (at least) two other options:
> >
> > 1. You could simply accept the extra round trip and send nonces in both
> > directions, as you do for the non-resumption handshake. That would be
> > the most straighforward approach, and arguably the best one.
> Whether this is acceptable to mandate or not really depends on the
> goals of session resumption. If the goal is simply to save compute
> resources for key exchange, then this seems like a reasonable change
> to make; but if the goal is to drive down time-to-first-byte-delivered
> to no more than a normal TCP connection, then this will negate that
> advantage, significant especially for lengthy paths.
> If tcpinc were primarily about confidentiality against active
> attackers, I think I'd come down on the side of safety against bad
> implementations; but, as the primary goal of tcpinc is to prevent
> pervasive passive surveillance, I think the balance tips the other
> way: to favor performance over misuse tolerance.

Hmm.... This seems like kind of an odd argument given that the design of
tcpcrypt explicitly eschews the kind of techniques that have been found
to be important to high resumption rates in protocols such as TLS.

> I also agree with David Black that I feel like there's a lot of scope
> creep here: frankly, I'm not comfortable making substantive changes to
> the core protocol without doing another WGLC.

I agree that you should do another WGLC if you make this change (or either
change, for that matter.) But I don't think that's a reason not to make


> 2. As I mentioned in my original note, you could have implementations
> > send a nonce in their sending direction before the first byte of
> ciphertext.
> > This isn't as good because you don't get anti-replay, but I *believe*
> > that it would provide strong defense against keying material reuse,
> > which seems like the most immediate threat.
> This may be the best compromise: it provides a measure of misuse
> tolerance within the existing performance constraints.
> Kyle