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

Kyle Rose <> Mon, 13 November 2017 01:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E517012711A for <>; Sun, 12 Nov 2017 17:56:16 -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 hpawjQI0QjfQ for <>; Sun, 12 Nov 2017 17:56:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC7801273B1 for <>; Sun, 12 Nov 2017 17:56:12 -0800 (PST)
Received: by with SMTP id p19so12807488qke.2 for <>; Sun, 12 Nov 2017 17:56:12 -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=hmme+68lQe/w9Wmh+3t/vjowRer2MY3M9ZLuWZy3GI4=; b=hZk5sfVSsvqYlvsuOc8JLXLde+oP+I7rwXz6LmwFq6TOxWqvLDak4WbEGi6xYKsfeE a0L/k8qhHLZk2ow4jAltCJVtElItEGkApY0MCcDXVTTw4k6mr7hBTgCHCYrF9/RllpsG VeLhH9TPAPx2BFzKkuoksXnPuRLyrahzclDI0=
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=hmme+68lQe/w9Wmh+3t/vjowRer2MY3M9ZLuWZy3GI4=; b=RmVGlYly+uKKivrWps44WKuZay6R66FgEND1gUtqrq8rzQttS6vA0q0SeL9Ebae2RY dBvf8VEtLbbwIPitii0P7dMb+NjWBtFvoAaCvYg9+0d3gNvdAv/ZK7j6m4k2o5CxQs8C wnjZ6Mj+ea/N2F8XPqDhe38bHHqHZgaGz3u3vLgpUD4D20WaOnMRm0P7Vw9KW4uUlM5u OgvUE2Vxjs9zzHBJi+A2TNSwT3+HFM/SeyqJk9GNmlapgDUSeKzsA85fxoqFwL588YtL oFehD1sT47uaYUtZwttokMfPCekv2Uvr/EIRUgpPt/KRbthQJ+S1xTv4uMcw1a51spgm UahQ==
X-Gm-Message-State: AJaThX5+EWtDQbql/bv4HUyXQiBeUzRc6nGSo6LAItIVnkyat2XQgxHv iVrRUFzvTtj3AyFQ4DGMn/TZ/1pdPYpTVNIrrWX+uQ==
X-Google-Smtp-Source: AGs4zMb59ae5ua2H81Oqlyhsti2gCVE7PzGcab6GSn++IkF5+tFoMfLCPj1xNz6YZzlPPNh+/hx5t95hIlG66Yq7l6k=
X-Received: by with SMTP id 34mr9330857qkq.78.1510538171367; Sun, 12 Nov 2017 17:56:11 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 12 Nov 2017 17:56:10 -0800 (PST)
X-Originating-IP: [2001:67c:1232:144:3c2f:f970:9675:8f98]
In-Reply-To: <>
References: <>
From: Kyle Rose <>
Date: Mon, 13 Nov 2017 09:56:10 +0800
Message-ID: <>
To: Eric Rescorla <>
Cc: The IESG <>,,, tcpinc <>
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: Mon, 13 Nov 2017 01:56:17 -0000

On Sat, Nov 11, 2017 at 11:12 AM, Eric Rescorla <> wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
>    2^64 bytes in the underlying TCP datastream (which would cause the
>    "offset" field to wrap) before re-keying.
> In TLS and other WGs, we have adopted the practice of
> salting the nonce with a secret per-connection value to avoid
> large-scale surveillance attacks. Why did you opt to use a weaker
> construction. See:
> and

I think I need some clarification on the point here. From the relevant
passage in the TLS 1.3 draft:

q( In order to prevent mass cryptanalysis when the same plaintext is
repeatedly encrypted by different users under the same key (as is
commonly the case for HTTP), the nonce is formed by mixing the
sequence number with a secret per-connection initialization vector
derived along with the traffic keys. See [BT16] for analysis of this
construction. )

What is the situation, commonly the case for HTTP, in which different
users would be using the same key for encryption?

>    FIN flag set, it MUST immediately send a frame (with empty
>    application data if necessary) with "rekey = 1".
> I don't think that the algorithm in this section
> necessarily works properly, because you have to handle rekeys in
> sequence:
> Frame 1 [0:999]
> Frame 2 [1000:1999, rekey=1]
> Frame 3 [2000:2999, rekey=1]
> Now what happens if the frames are re-ordered so you get Frame 3 and
> then Frame 2. You will try to decrypt Frame 3 with generation 2 and
> Frame 2 with generation 3, neither of which will work (though you
> might be able to interpret the text loosely to have you try to decrypt
> Frame 2 with generation 2). Note that if you were to resequence before
> processing, this wouldn't happen.
> At minimum I think some clarification is needed here.

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. )

> Given that you are allowing P-256 and point reuse, you
> should be requiring point validation. See:
> You should probably also be requiring Curve25519 output validation.


> You still seem to need to specify an MTI symmetric algorithm.

Daniel noted this in his October 25 email, but you are right: I can't
seem to find it in the latest draft, either. Did that change get lost?

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> The design of session resumption here essentially precludes doing
> tcpcrypt resumption across servers (as one does with TLS) because you
> need extremely tight control of ss[i] or you have catastrophic
> results. Was this a deliberate choice by the WG?

The idea of doing something more ticket-like was discussed, but David
pointed out (in the thread here:
that tickets might not meet the charter mandate for forward secrecy. I
don't recall discussing the implications of mismanaging ss[i], but
I'll defer to Daniel on that point. Same goes for the following:

>    session resumption such that a given pre-session key "ss[0]" is only
>    used for either passive or active opens at the same host, not both.
> This seems like it probably needs some more emphasis, as failure to follow this
> instruction results in GCM compromise.
> It would probably be useful to explain why you opted for this design rather
> than having nonces, which would remove the need for such strict ss[i]
> management. I assume the reason is that you want to save the round trip?
>    connection; but if it aborts, the implementation MUST raise an error
>    condition distinct from the end-of-file condition.
> Note that this interacts badly with the rekey issue I raise below.

>    format", and MUST accept values encoded in "compressed",
>    "uncompressed" or "hybrid" formats.
> Why are you allowing multiple formats here? Generally, if you're going to
> encourage compressed, you want to just require it.

I'm not sure what the justification here was, so I'd be happy with
mandating compressed values if it simplifies the receiver's logic.