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

Eric Rescorla <> Fri, 02 November 2018 06:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D08F12D4EF for <>; Thu, 1 Nov 2018 23:14:37 -0700 (PDT)
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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DkoJbSFkkqGR for <>; Thu, 1 Nov 2018 23:14:34 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0DB2129C6A for <>; Thu, 1 Nov 2018 23:14:33 -0700 (PDT)
Received: by with SMTP id s15-v6so754908lji.3 for <>; Thu, 01 Nov 2018 23:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2z0f0HDfF89HR4saFFOS+zXKqjK/ZTLPri8FVKr4yuU=; b=CTb2grv8e3Z+XWnfk/ZArmO2HS0PqcbNWeSPIRO35uZBwzSu844KW8KODGatEELfxD QB1jFjYV2P0eqHvl5m5PJ9sdh7VuqLWnheARtoHzJ+kkqHDpSvC64hgw3rQTs74ippsw TLFIN9G9AbluZ3Yte4WfATR+fpOHHZaUkhSsosTxobaZECVg6gu6xGafPIYabOYOlQcE xKgwVq2JJg5rX/ZPDoIIX1KuzaPSWoNaSW1H9G7Cc+g+rEwJemuM3VzpB14AbcfMcAiM c8uXbx69DjSAj1KZ8SrKwXlqivhCxSphFL7wJvY+3oKoN+8rozvHBWKiU4fj+M6991IL MeIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2z0f0HDfF89HR4saFFOS+zXKqjK/ZTLPri8FVKr4yuU=; b=NdpjoV003INLqabIYhZAzL9mx66m4mxPDdooFSrUjnIP5+MMWYOR3hseaccy4Cbcwg M7s6uhmrthZgPvALHLOfGfx2oUGeQ2aHG5aIM5G7GUW7bOME0Noejn3E5/bmAOxWXgOn 312E9YauRCW/6n/EHYg+aOyhxPJ+0aX3D9ULvIsCkXUmLtOB4fIWfOI9OVECI2sgfoz+ AmgHz8sKWCUO0KAb8ZmQ37fi9Dv4ARp92r64gIL3zVQQpeWJhZZsGOii+uU3fRteM/wl ZPJYlau7FtW6sbPr6lnbrY0UEf+gsLM3IfEZBdYm7RDWgtF7AERTatEWLooWsDTG5Mj2 wS/w==
X-Gm-Message-State: AGRZ1gJdrESlCgxIN5f/lmgTVcWtt9tOlUhsZr26SrnSRsp9JEFa66dX EczmQKLYoV6/z6hRvYEsaAXv2oIHssU4gP6EQOd6o5giV1+9uA==
X-Google-Smtp-Source: AJdET5ecBEbAq2aR1meuVWE+Dg2gyEQ1xDFC1xuymo9pfEygbqjx9UGO4fSXuNPZn7HxDdZxL57gZ0PLljhWiN4YU5E=
X-Received: by 2002:a2e:91d1:: with SMTP id u17-v6mr6719555ljg.160.1541139271935; Thu, 01 Nov 2018 23:14:31 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Thu, 01 Nov 2018 23:13:54 -0700
Message-ID: <>
Cc: Kyle Rose <>, tcpinc <>, Daniel B Giffin <>,, "Black, David" <>, IESG <>,
Content-Type: multipart/alternative; boundary="000000000000da78790579a8724c"
Archived-At: <>
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
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: Fri, 02 Nov 2018 06:14:37 -0000

On Thu, Nov 1, 2018 at 9:57 PM David Mazieres <> wrote:

> Eric Rescorla <> writes:
> >    When a frame is received, tcpcrypt reconstructs the associated data
> >    and frame ID values (the former contains only data sent in the clear,
> >    and the latter is implicit in the TCP stream), computes the nonce "N"
> >    as above, and provides these and the ciphertext value to 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 SHOULD abort the connection and raise an error
> >    condition distinct from the end-of-file condition.  But if none of
> >    the TCP segment(s) containing the frame have been acknowledged and
> >    retransmission could potentially result in a valid frame, an
> >    implementation MAY instead drop these segments (and "renege" if they
> >    have been SACKed, according to [RFC2018] Section 8).
> >
> > Looking through this again, why is this the right guidance? It seems
> > like:
> >
> > 1. You shouldn't ACK data that you can't verify, because it's confusing
> > to the other side. This seems like one of the arguments for tcpcrypt
> > rather than protocols that run over top of TCP.
> This obviously isn't how the original tcpcrypt worked, but the working
> group decided that for middlebox robustness, tcpcrypt should not protect
> the integrity of the TCP header (including ACK bits).  As it is, nothing
> requires TCP segments to align with tcpcrypt frames.  If the recipient
> lucks out and hasn't ACKed any of the corrupt data, then maybe hope a
> retransmission is better, although middleboxes might prevent sequence
> numbers from being overwritten anyway.  Since that's a rather fringe
> case, if you only do one thing it needs to be aborting the connection.
> > 2. You would get better resistance to connection failure if you instead
> > decrypted packets and then ACKed.
> Not especially, because tcpcrypt doesn't protect the header, so an
> active attacker can just inject bad packets and desynchronize the TCP
> connection.  There does exist a protocol that does better--namely the
> original version of tcpcrypt, but for various reasons the working group
> ultimately rejected this design (over my objections), and it's too late
> to revisit the decision at this point.
> > Is the situation that sometimes you have to ACK? I haven't thought
> > this through. Perhaps you should recommend against ACKing if you
> > don't have to.
> The ACKing is effectively dictated by RFC793 (+SACK).

OK, I'm persuaded I'm wrong about this.

> > I also notice you don't require checking that the result of the
> > X25519 function is nonzero. We hve been requiring this in other
> > IETF protocols.
> Seems like a vanishingly low-probability event, but I see no problem to
> adding such a requirement.  Do you have some language to suggest?  Maybe
> we could cut and paste out of another RFC with already approved
> language?

It's a lot probability event with a correctly-behaving counterparty, but
it's easy for
the other side to force the output to 0. Here is some text:


   For these curves, implementations SHOULD use the approach specified
   in [RFC7748 <>] to
calculate the Diffie-Hellman shared secret.
   Implementations MUST check whether the computed Diffie-Hellman shared
   secret is the all-zero value and abort if so, as described in
   Section 6 of [RFC7748]
<>.  If
implementors use an alternative
   implementation of these elliptic curves, they SHOULD perform the
   additional checks specified in Section 7 of [RFC7748]


> >    the number of past connections that are vulnerable.  Of course,
> >    placing private keys in persistent storage introduces severe risks
> >    that they will not be destroyed reliably and in a timely fashion, and
> >    SHOULD be avoided at all costs.
> >
> > This seems a bit over the top. Either it's this serious and you need
> > a MUST, or it's not this serious, and you should tone it down.
> It is serious, especially with SSDs.  The reason not to make it a MUST
> is that some implementations may be unable to avoid it--like a virtual
> machine that gets transparently paged to disk.  That could still be okay
> if, say, the swap partition is encrypted with an ephemeral key.

Well, then the text should say this. But "SHOULD at all costs" is silly.

> >    To meet that ideal, it might appear natural to also mandate ECDHE
> >    using P-256, as this scheme is well-studied, widely implemented, and
> >    sufficiently different from the Curve25519-based scheme that it is
> >    unlikely they will both suffer from a single (non-quantum)
> >    cryptanalytic advance.
> >
> > I'm not sure how persuasive this argument is. Wouldn't an efficient
> > discrete log algorithm in generic groups affect both of these functions.
> > As far as I know, it's not known that no such algorithm exists.
> In fact, there are lower bounds on generic-group discrete-log attacks.
> See, for example, this recent Eurocrypt paper:
> But it sounds like you actually agree with us that we don't need to
> mandate P-256, so I'm not sure what you are suggesting here.

I'm suggesting you remove the justificatory text. Other WGs have just
mandated one group without justification


> David