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

Eric Rescorla <> Mon, 13 November 2017 07:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 789331294B5 for <>; Sun, 12 Nov 2017 23:22:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] 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 U7bvM-JOALLA for <>; Sun, 12 Nov 2017 23:22:10 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 959A712948F for <>; Sun, 12 Nov 2017 23:22:07 -0800 (PST)
Received: by with SMTP id x20so5704333ywg.4 for <>; Sun, 12 Nov 2017 23:22:07 -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=JViBvtjiBiOiDLHpOdNasZz1Lb8hgBaUlWGTwKhaPk4=; b=nwi9No0VhVAwEfaE/PeUX3fShoAjIEW9L1tAh9AbCpyXAfqYMh5PfXGa/SBdUBOr6h z+B6QK5o8XlVHD6yPAVhU3KX1B16035tGenMzVf/4+midoYkMvFDvbCkFL0PW35hvEJS XYm0eAvEn5gwcoPQbFNlfIODxKxPicWULs/6/RJJ7Ffa0OoVPSw42/4r/G3eSUALRiNv 74XWlX8+YGpwFrbCYwEV1UhzO4JiE/qDHix0GPCjzCN5tekPFHgs/eTF1E284nov03UW PjHbHXg67VJg1qvwFfnDLpPor26MS1HObOiKiT1H5nNInhW/vNBE+AnfoxgSO4/ySU72 BERw==
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=JViBvtjiBiOiDLHpOdNasZz1Lb8hgBaUlWGTwKhaPk4=; b=lDAfvez0ZoxfL/Pqm2tXEEui7ChlioJBhhSXxZQEaw6bHTNaIGUQ0AavA5wydtt334 S+YlLSjj0a5xOmVmvhbN2vfaEHOCYh7vR37zt4EUi6vlig7/yzq09i49O+JW0f0QHKsi 98OSAIPLZi+Izf57VKdATcS5+SDJekV5JiNvjpxsMd5/mpNvDC1XgAkk2qvzmkzZqAVd 4xMR2k3wZyY62VEpmiZPjNAD47ploiTbi/gP77wmI4FlDk3eiowfxcbIQUT18uF+k79c np3lRvFEAVciR2J5rrP8hxr/JduiGgOqsm+CyZ2+8swEfxG69qUtEPEc1mFJefmJtZBf 6xiw==
X-Gm-Message-State: AJaThX6mbBU0EILzOOqGbk8Fm50IhLeR4AfIDsDWBPIVu3X+6o9nu7Zk /po3fc47rKd2sbPY8nU02bIGraWc1QtNyZQpGlV5+Q==
X-Google-Smtp-Source: AGs4zMYvyw+zBNbt0JGp+FVAi0EZH5DOW7BlffiWr90jyWY5c2oCYQYGeXSOEepQXtSLPwcw6UPFH/dfIXDqKyPZ27Q=
X-Received: by with SMTP id d13mr4797325ybn.397.1510557726830; Sun, 12 Nov 2017 23:22:06 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 12 Nov 2017 23:21:26 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Eric Rescorla <>
Date: Mon, 13 Nov 2017 07:21:26 +0000
Message-ID: <>
To: Kyle Rose <>
Cc: The IESG <>,,, tcpinc <>
Content-Type: multipart/alternative; boundary="089e0828e4f8b8893b055dd82069"
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, 13 Nov 2017 07:22:18 -0000

On Mon, Nov 13, 2017 at 7:00 AM, Kyle Rose <>; wrote:

> On Mon, Nov 13, 2017 at 10:09 AM, Eric Rescorla <>; wrote:
> > On Mon, Nov 13, 2017 at 9:56 AM, Kyle Rose <>; wrote:
> >> What is the situation, commonly the case for HTTP, in which different
> >>
> >> users would be using the same key for encryption?
> >
> >
> > That's not the assumption. It's a time-space tradeoff. Say you have a
> > 128-bit
> > key. The attacker computes the value:
> >
> >   Encrypt(K, "GET / HTTP/1.1") [or whatever]
> >
> > For a feasible subset of the key space (e.g., 2^80 or so). It then
> captures
> > a large fraction of the traffic on the Internet and looks for matches for
> > one
> > of these strings. If it has a match, it now immediately knows the key.
> Given
> > the amount of traffic on the Internet, this is just maybe barely feasible
> > with
> > 128-bit keys. However, with a randomized (secret) nonce, it becomes
> > infeasible.
> Interesting. I don't have a strong opinion about this one, but if
> there are no (or cheap) tradeoffs, it seems reasonable to use this
> construction.

The countermeasure that TLS uses seems pretty cheap.

>> I'm confused. The byte stream will be delivered in-order via TCP
> >> sequence semantics, so receiving frames (TLV within the TCP
> >> bytestream) out-of-order should not be possible. If a MitM reordered
> >> the frames, the receiver would either drop the frame or close the
> >> connection following a failure to authenticate upon decryption:
> >>
> >> q( In the latter case, the implementation MUST
> >>    either drop the TCP segment(s) containing the frame or abort the
> >>    connection; but if it aborts, the implementation MUST raise an error
> >>    condition distinct from the end-of-file condition. )
> >
> >
> > Maybe I'm misunderstanding tcpcrypt, so let me ask a preliminary
> > question:
> >
> > Say you have two TCP segments protected using tcpcrypt, N and N+1
> > If the receiver receives N+1 before N, how does it behave?
> Tcpcrypt lives entirely within the ordered TCP data stream. If N+1
> arrives before N, that payload will not be delivered to the tcpcrypt
> engine until after N arrives, in accordance with the in-order
> semantics of TCP payload delivery.

Right. I plead jet lag.

Now that you've reminded me of this, it's worth noting that the following
probably could use some expansion:

   When a frame is received, tcpcrypt reconstructs the associated data
   and frame nonce values (the former contains only data sent in the
   clear, and the latter is implicit in the TCP stream), and provides
   these and the ciphertext value to the the AEAD decryption operation.
   The output of this operation is either a plaintext value "P" or the
   special symbol FAIL.  In the latter case, the implementation MUST
   either drop the TCP segment(s) containing the frame or abort the
   connection; but if it aborts, the implementation MUST raise an error
   condition distinct from the end-of-file condition.

Presumably the theory here is that there is some sort of benign damage
to the packets that nevertheless passed the TCP checksum, and the retransmit
might succeed. However, in order for this to work properly, you have to
ACKs for those segments until you have verified them (or if you are using
SACK, renege on the segments once they become in-order and you determine
they are bogus). Otherwise, the sender will not retransmit, and you'll
never be
able to recover. This probably needs to be covered in this spec.

> > I don't think the issue here is tickets, but rather the lack of a nonce.
> > The point is that (say) the implementation fails to properly delete
> > ss[i] after encrypting some data. Then if an attacker can force
> > you to reuse ss[i], it can potentially recover data. This would not
> > be the case if you mixed in a nonce from both sides (the way that
> > TLS and IKE do).
> I like the idea of added defense-in-depth against faulty
> implementations, but it's not clear to me what tradeoffs this involves
> re: (e.g.) SYN data on resumption, or on number of round trips, or on
> the latency-to-first-payload-byte. I'd like Daniel to chime in here.

I suspect that latency is in fact the issue here, but there's probably
*some* way around this. Half-baked probably broken idea: what if each side
a nonce before it started encrypting and mixed that into its *sending*
keys. Then at least you would have diversity for the keys, though no