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

Eric Rescorla <ekr@rtfm.com> Fri, 02 November 2018 06:14 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D08F12D4EF for <tcpinc@ietfa.amsl.com>; Thu, 1 Nov 2018 23:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkoJbSFkkqGR for <tcpinc@ietfa.amsl.com>; Thu, 1 Nov 2018 23:14:34 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DB2129C6A for <tcpinc@ietf.org>; Thu, 1 Nov 2018 23:14:33 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id s15-v6so754908lji.3 for <tcpinc@ietf.org>; Thu, 01 Nov 2018 23:14:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; 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; d=1e100.net; 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: <20171124182842.GA80062@scs.stanford.edu> <CABcZeBORGhsgWem3P6GS=1qfkwBEZxX=CBGCOoU3R_+MsO4FrQ@mail.gmail.com> <CAJU8_nXA_1L_XVJAMGj+L4JY-so+LO79pxt_s=BTLWj_g47f_Q@mail.gmail.com> <CABcZeBNQEs6BKnxzQOuN4A4qvEDsk8kGQLt6S9Wy0OXsJ3u5cw@mail.gmail.com> <CAJU8_nWMn0_SSLUH+reS5La4J7t0uEN5u2zC8XFRXDMOffc1Qg@mail.gmail.com> <CABcZeBP2mN-Y3GFda3mqawFuFFqtzpwpsceseE5FNMH1iSpFPQ@mail.gmail.com> <CAJU8_nWk_Opuj+m4jv79qwFMUGqi5=JMk3S_3QfJLahOjL+77g@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD89888@MX307CL04.corp.emc.com> <20171128041124.GA42654@scs.stanford.edu> <CAJU8_nUx=k-nKLcrY0iVeSL7THCVARanZymWbTHaNbR+FKavPw@mail.gmail.com> <20171128223855.GE42654@scs.stanford.edu> <CAJU8_nUeTj2fwr4PAJ1T34uACHK=OnX1_OC3+UB9DomcvvcPMw@mail.gmail.com> <CABcZeBPe5_UhhmhiSBMGqYTfT7pyVhaeWXBOkw7CHRumghN57Q@mail.gmail.com> <8736skgjot.fsf@ta.scs.stanford.edu>
In-Reply-To: <8736skgjot.fsf@ta.scs.stanford.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 1 Nov 2018 23:13:54 -0700
Message-ID: <CABcZeBO6HRTCfkcNivnagjpxOhEvEvC5WeKFXOhdcHAnCc1tFw@mail.gmail.com>
To: mazieres-6psz4e73x7q53jpxuwevcx7f36@temporary-address.scs.stanford.edu
Cc: Kyle Rose <krose@krose.org>, tcpinc <tcpinc@ietf.org>, Daniel B Giffin <dbg@scs.stanford.edu>, tcpinc-chairs@ietf.org, "Black, David" <David.Black@dell.com>, IESG <iesg@ietf.org>, draft-ietf-tcpinc-tcpcrypt@ietf.org
Content-Type: multipart/alternative; boundary="000000000000da78790579a8724c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/OR6wjnIKAEtJufnSFAfhws2J-E8>
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Nov 2018 06:14:37 -0000

On Thu, Nov 1, 2018 at 9:57 PM David Mazieres <
dm-list-tcpcrypt@scs.stanford.edu>; wrote:

> Eric Rescorla <ekr@rtfm.com>; 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:

https://tools.ietf.org/rfcmarkup?doc=8446#section-7.4.2

"

   For these curves, implementations SHOULD use the approach specified
   in [RFC7748 <https://tools.ietf.org/rfcmarkup?rfc=7748>] 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]
<https://tools.ietf.org/rfcmarkup?rfc=7748#section-6>;.  If
implementors use an alternative
   implementation of these elliptic curves, they SHOULD perform the
   additional checks specified in Section 7 of [RFC7748]
<https://tools.ietf.org/rfcmarkup?rfc=7748#section-7>;.

"


> >    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:
>
>
> https://www.henrycg.com/files/academic/papers/eurocrypt18discrete.pdf
>
> 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

-Ekr


> David
>