Return-Path: 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 ; 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 ; 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 ; Thu, 1 Nov 2018 23:14:33 -0700 (PDT) Received: by mail-lj1-x236.google.com 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; 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> <20171128041124.GA42654@scs.stanford.edu> <20171128223855.GE42654@scs.stanford.edu> <8736skgjot.fsf@ta.scs.stanford.edu> In-Reply-To: <8736skgjot.fsf@ta.scs.stanford.edu> From: Eric Rescorla Date: Thu, 1 Nov 2018 23:13:54 -0700 Message-ID: To: mazieres-6psz4e73x7q53jpxuwevcx7f36@temporary-address.scs.stanford.edu Cc: Kyle Rose , tcpinc , Daniel B Giffin , tcpinc-chairs@ietf.org, "Black, David" , IESG , draft-ietf-tcpinc-tcpcrypt@ietf.org 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-BeenThere: tcpinc@ietf.org 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 --000000000000da78790579a8724c Content-Type: text/plain; charset="UTF-8" On Thu, Nov 1, 2018 at 9:57 PM David Mazieres < dm-list-tcpcrypt@scs.stanford.edu> 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: https://tools.ietf.org/rfcmarkup?doc=8446#section-7.4.2 " 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: > > > 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 > --000000000000da78790579a8724c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 1, 2018 at 9:57 PM David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> wrote:
Eri= c Rescorla <ekr@rtfm.c= om> writes:

>=C2=A0 =C2=A0 When a frame is received, tcpcrypt reconstructs the assoc= iated data
>=C2=A0 =C2=A0 and frame ID values (the former contains only data sent i= n the clear,
>=C2=A0 =C2=A0 and the latter is implicit in the TCP stream), computes t= he nonce "N"
>=C2=A0 =C2=A0 as above, and provides these and the ciphertext value to = the AEAD
>=C2=A0 =C2=A0 decryption operation.=C2=A0 The output of this operation = is either a
>=C2=A0 =C2=A0 plaintext value "P" or the special symbol FAIL.= =C2=A0 In the latter case,
>=C2=A0 =C2=A0 the implementation SHOULD abort the connection and raise = an error
>=C2=A0 =C2=A0 condition distinct from the end-of-file condition.=C2=A0 = But if none of
>=C2=A0 =C2=A0 the TCP segment(s) containing the frame have been acknowl= edged and
>=C2=A0 =C2=A0 retransmission could potentially result in a valid frame,= an
>=C2=A0 =C2=A0 implementation MAY instead drop these segments (and "= ;renege" if they
>=C2=A0 =C2=A0 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= 9;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<= br> group decided that for middlebox robustness, tcpcrypt should not protect the integrity of the TCP header (including ACK bits).=C2=A0 As it is, nothi= ng
requires TCP segments to align with tcpcrypt frames.=C2=A0 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.=C2=A0 Since that's a rather frin= ge
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 instea= d
> 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.=C2=A0 There does exist a protocol that does better--namely the<= br> 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.
<= br>
=C2=A0
> 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.=C2=A0 Do you have some language to suggest?=C2= =A0 Maybe
we could cut and paste out of another RFC with already approved
language?

It's a lot probability ev= ent 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=3D8446#section-7.4.2

"
   For these c=
urves, 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
   Sectio=
n=C2=A06 of [RFC7748].  If implementors use an alternative
   implementation of these elliptic curves, they SHOULD perform the
   additional checks specified in Section=C2=A07 of [RFC7748].

"


>=C2=A0 =C2=A0 the number of past connections that are vulnerable.=C2=A0= Of course,
>=C2=A0 =C2=A0 placing private keys in persistent storage introduces sev= ere risks
>=C2=A0 =C2=A0 that they will not be destroyed reliably and in a timely = fashion, and
>=C2=A0 =C2=A0 SHOULD be avoided at all costs.
>
> This seems a bit over the top. Either it's this serious and you ne= ed
> a MUST, or it's not this serious, and you should tone it down.

It is serious, especially with SSDs.=C2=A0 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.=C2=A0 That could still be ok= ay
if, say, the swap partition is encrypted with an ephemeral key.

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


>=C2=A0 =C2=A0 To meet that ideal, it might appear natural to also manda= te ECDHE
>=C2=A0 =C2=A0 using P-256, as this scheme is well-studied, widely imple= mented, and
>=C2=A0 =C2=A0 sufficiently different from the Curve25519-based scheme t= hat it is
>=C2=A0 =C2=A0 unlikely they will both suffer from a single (non-quantum= )
>=C2=A0 =C2=A0 cryptanalytic advance.
>
> I'm not sure how persuasive this argument is. Wouldn't an effi= cient
> discrete log algorithm in generic groups affect both of these function= s.
> 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:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 htt= ps://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 t= ext. Other WGs have just mandated one group without justification
=

-Ekr


David
--000000000000da78790579a8724c--