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

Eric Rescorla <> Mon, 27 November 2017 16:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFF06127337 for <>; Mon, 27 Nov 2017 08:44:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 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_LOW=-0.7] 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 UZVjguXdk3Xh for <>; Mon, 27 Nov 2017 08:44:30 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A76BA126B6D for <>; Mon, 27 Nov 2017 08:44:28 -0800 (PST)
Received: by with SMTP id p74so12101848ywe.2 for <>; Mon, 27 Nov 2017 08:44:28 -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=cQv4rDw5yYocM8RzNiU6NbyRn5QckBwx2dk4lnHpzqk=; b=t3XWz6NGItlMOqFdhWCkXelf6UVUkYPWPZ1AMW5Gk0JSfzBryhMahPSBPBMYws8DGz Vv8JQBVriTpTi4nOYRmD1r+5tTuHMEc1Ggqb0u8r4cqWXnWdCHLS2AsD3mFB5JqPDqj0 vXuUMfMg4ERKsa1TIgacJHlJ0DtcmNzcYX3ewTo9jhn9PxDr5mSm6325KYaXCvBPkuyc o+mDetZMWt4tVy5QTcRVeNwRDRaFaqYFle/5o4HtZ1U5h8vtusBQ+02/62iNYt9Qu6Iw AZwDOd1I7ZZIeeHnNzzEI/5KvAge+BWrJvBs5rFjFzDMoIWq7ktdPubTZ8aqMjnBhfMP /1hA==
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=cQv4rDw5yYocM8RzNiU6NbyRn5QckBwx2dk4lnHpzqk=; b=LMKIaGMpdP3dPjTXxejLc1pSFLY16LK0g11EK905bbOm1nCK6B4HN2Jl5hBUeBFBZf tAtE3dOLUaZU1jGqsqv4HYUu0oLKV0py/4chotWJwa09Rq83nh2FWWdRanZXVmFJbUkw 4ZJPjYb+71IYJ+TIB0PCU7V55BPuiGJO5VajoD0KINADZlGjkmFrg7ZfKINBWlUlxrMZ op63aHEGz79pi9KoNeFb63twXnW1bNcS8QTAYgk00xy2GLx3a6Hu3RPEL7SyqtE0xRd4 2zZCcrpPTemyVNgZUPJ56OzGVNVQrOaJxLcIJqI6LmJeI45fpilPQkItAjxLzFeVXGpq 8Kkw==
X-Gm-Message-State: AJaThX7BDwGmcSR9+kYLHCj53cjSXTrrEc93FTZoouWvrfTu5j4ir3Yp XktJaiiP4XU/in/p719TRku7e/Au7QvT3DajZ2ftMA==
X-Google-Smtp-Source: AGs4zMZY2UzNVEowTXmUDwBj8hsu2FUAPWqBzMRdHUNAJjDPGABr/uhZXIw3LYFiWV0vTkM28AIFZBj3vhQbZ2D7jcI=
X-Received: by with SMTP id l30mr25791503ywk.5.1511801067749; Mon, 27 Nov 2017 08:44:27 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 27 Nov 2017 08:43:47 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 27 Nov 2017 08:43:47 -0800
Message-ID: <>
To: "Black, David" <>
Cc: Kyle Rose <>, Daniel B Giffin <>, tcpinc <>, "" <>, The IESG <>, "" <>
Content-Type: multipart/alternative; boundary="f403045ea7169d585e055ef99dcc"
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 16:44:32 -0000

On Mon, Nov 27, 2017 at 8:30 AM, Black, David <> wrote:

> Inline ...
> > 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.
> [David>]  I agree with Kyle here.  In addition, a new key exchange is
> cheaper for tcpcrypt by comparison to TLS (e.g., because tcpcrypt does not
> authenticate), so if the properties of a new tcpcrypt key exchange are
> wanted, that's what should be done, IMHO.

I'm not sure why you call this the properties of a new key exchange.
Non-reuse of keys is a basic property of key establishment schemes.

> 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.
> >
> > > 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.
> [David>] Hmm - this doesn’t do much for confidentiality with stream
> ciphers like AES GCM (the single "MUST implement" cipher for tcpcrypt) , as
> if reuse happens, then the attacker XORs the two matching ciphertext
> streams yielding an XOR of the plaintext streams in which the first n bytes
> of XOR'd nonces can safely be ignored.

> If the intent was that the nonces participate in key derivation, then the
> keys would need to be re-derived after the first message following
> resumption is received

Huh? I think we're talking past each other here.

My suggestion was to send a nonce before you send any ciphertext and then
derive the traffic keys from ss[i] and the nonce. That's why this only
works properly asymmetrically.

- it's a better idea to move that key derivation into setting up the TCP
> connection for resumption.   One consequence of nonce participation in key
> derivation is that pre-calculation of resumption keying material prior to
> the TCP handshake is no longer possible.  I would hope that a one-byte
> nonce in each direction will suffice, as the goal is reuse prevention, not
> injection of significant new entropy.  If significant new entropy is
> wanted, start over with a new key exchange, IMHO.

To have strong reuse prevention you need a long enough nonce that you have
a low probability of collision.

One concern here is that an implementation might have a defect where it
improperly erases ss[i] after use, in which case an attacker might
repeatedly exercise that defect and thus get key reuse.


Here's a sketch of one way in which this could be done.  First, reduce the
> resumption identifier size to 16 bytes from the current 18, and then send 8
> bytes of resumption ID + 1 byte of nonce in each direction for resumption
> in place of the current 9 bytes of resumption ID.  Those nonces then need
> to be folded into the existing tcpcrypt CPRF key generation framework that
> takes a 1-byte value in addition to the key.   One possibility (feels like
> a bit of a hack) is to take the upper half of the current 1-byte CONST
> value space for this purpose by forcing the most significant bit of each
> nonce to 1, and then running CPRF twice to include both nonces:
>         ss_a[i] = CPRF(ss[i], nonce_a | 0x80, K_LEN)
>         ss_ab[i] = CPRF(ss_a[i], nonce_b |0x80, K_LEN)
> After this, the master keys, mk[i], are generated from ss_ab[i] instead of
> ss[i].
> The result is 7 bits of nonce in each direction, so 14 bits of reuse
> resistance.  That seems ok, since reuse is not supposed to happen in the
> first place.  OTOH, there's no useful anti-replay resistance here, as one
> would need much larger nonces for that, so it's good that anti-replay is a
> non-goal.  However, Kyle's concern about changes to the core protocol
> applies to this sort of design, even though it doesn't add a new round-trip.
> > Kyle