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

Eric Rescorla <ekr@rtfm.com> Wed, 21 November 2018 21:56 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 E5785130DC6 for <tcpinc@ietfa.amsl.com>; Wed, 21 Nov 2018 13:56:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Level:
X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 okQnfDKFXGoL for <tcpinc@ietfa.amsl.com>; Wed, 21 Nov 2018 13:56:30 -0800 (PST)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 EA2EB12D7F8 for <tcpinc@ietf.org>; Wed, 21 Nov 2018 13:56:29 -0800 (PST)
Received: by mail-lf1-x132.google.com with SMTP id l10so5100026lfh.9 for <tcpinc@ietf.org>; Wed, 21 Nov 2018 13:56:29 -0800 (PST)
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=dgDA9QzARquLv1nQsCNA2PMjgGUbMtWmwUpRUngcwEU=; b=rAvB0ybHdWsB2jBcAnxwy1iAf9FGLhAMA8dlQK3u6CIPGsjbxNrL9gQ8MfA6ghszFv pPGgWexqZaDzyjDMWtrYLtU9RJo4bmSkjHFleWMKHjfvQxhECnPwsWR7EY8M0QFUJrhA +pi6X/bEM9rpwVb0sibSrJnyj0I1iP2dvol28qnayeqXDNDzMhNtrObRhqlBMEDljWeB l5yiB3N1j/Yqwn6Okz7VObj36A6KEZjSC6qwgR6QVtxraIL/V6Z5K/xBwqMEcUomvEOz m8n5mP4wok3wD49PAyh9q+qoc3I4+KXzFy3roHCWiZmfaSGNPFv3qqRHYpDdUSpQbf/2 b9dg==
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=dgDA9QzARquLv1nQsCNA2PMjgGUbMtWmwUpRUngcwEU=; b=cNSQJkmJzagO0j+iIXVgxSP89UyFdq1Da0nPvOkiTGv0JSUvFuwMwRU1QHzom4BcG8 LFSV7bpbYcKw1DBnj2XYz4+iayXGn2Qwql5xW/dUs9xpA7uQNv+YkpLUs/rtHO7DkyAB +oTKdiOHDv2w0hvQsCbxiZSav7SvLppxozGNq89+tm5YvVA/YKcCHfDQaeZiX9PeBYtJ r5/EaNRIUfQNnhatJMf5LC5eHfLi79D9kMLXFYrrrP5M16foz4BfUJGUrpswLlLRrUn3 aP6IHdV3XuyWO5zB4DAxi2b1aIoIi8PZBvkeTxBpwjA3HRatzx7ARuCIKCC+UUgB8q/r QscA==
X-Gm-Message-State: AGRZ1gLzNUSRmV8sMEoRLrZLVLdgLrG8Lz/1dkQpr6vvrLDt12OtEVT+ kXGHugnkTUI9whT/zZo+TA6s+K1fW1/WSVNHnF6Vvw==
X-Google-Smtp-Source: AJdET5cTgG9CdRLBMec57E2vI05NW+/u66gPD24wLgDcrMGacPGegUZAVitYAUAbqgEcPHbkwRmT46LhPyPAgCe+bTw=
X-Received: by 2002:a19:5a05:: with SMTP id o5mr5204814lfb.140.1542837388096; Wed, 21 Nov 2018 13:56:28 -0800 (PST)
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> <CABcZeBO6HRTCfkcNivnagjpxOhEvEvC5WeKFXOhdcHAnCc1tFw@mail.gmail.com> <87a7mp9din.fsf@ta.scs.stanford.edu> <CABcZeBNHxqU0k+jK61zTKoUmuY2V9tcgEZM9Y=R5RkciZjnXtQ@mail.gmail.com> <87efbz1v2m.fsf@ta.scs.stanford.edu>
In-Reply-To: <87efbz1v2m.fsf@ta.scs.stanford.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 21 Nov 2018 13:55:50 -0800
Message-ID: <CABcZeBOZwRGP8=KyC7Rvpg8o4GwaQvM3ybBb6sEAr02fecHabg@mail.gmail.com>
To: mazieres-kx7qrxyxxj6yvhuta3dps7wf5n@temporary-address.scs.stanford.edu
Cc: tcpinc <tcpinc@ietf.org>, Daniel B Giffin <dbg@scs.stanford.edu>, Kyle Rose <krose@krose.org>, 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="00000000000076cf67057b33d216"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/M4dQbT3GqqSqG5BhJLvaQLP7xMw>
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: Wed, 21 Nov 2018 21:56:33 -0000

On Mon, Nov 5, 2018 at 6:02 AM David Mazieres <
dm-list-tcpcrypt@scs.stanford.edu>; wrote:

> Eric Rescorla <ekr@rtfm.com>; writes:
>
> > On Sun, Nov 4, 2018 at 5:29 AM David Mazieres <
> > dm-list-tcpcrypt@scs.stanford.edu>; wrote:
> >
> >> I've posted a new draft in the usual place:
> >>
> >>         https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/
> >>
> >> Please let us know if the diffs satisfy your concerns:
> >>
> >>
> >>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-tcpinc-tcpcrypt-13&url2=draft-ietf-tcpinc-tcpcrypt-14&difftype=--html
> >
> >
> > I am not an EC expert, but my impression based on the discussion in TLS
> was
> > that checking for the zero value for X25519 was not sufficient defense
> > against malicious peers if you didn't use the 7748 computations, hence
> the
> > language in 8446. Do you believe otherwise?
>
> I don't understand what you are asking for here.  Section 7 of RFC7748
> is mostly advice applicable to tcpcrypt's authors, which we are
> following--for instance by including the entire transcript with nonces
> in the session key computation so as not to depend on "contributory
> behavior" of the Diffie-Hellman parameters.  What is it that you want us
> to specify in our RFC for tcpcrypt implementers?
>

I provided the text I recommend in my note of November 1.

"   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].
"

I agree that this isn't maximally clear in 7748, but it does involve
checking that you
are on-curve.



> The only think tcpcrypt cares about for malicious peers is preventing
> session ID reuse, which the design indeed appropriately prevents.
>

Generally, we've decided to adopt a belt and suspenders approach here,
namely:

1. Trying to ensure that the DH function can't be forced into a small set
of values
by one side.
2. Merging in the transcript so even if the DH function isn't contributive,
you can't
force the output keys into a small range.

I agree that tcpcrypt does (2). What I am looking for is also (1).

-Ekr


Otherwise, if a malicious peer causes a connection to be aborted or
> leaks the session key--well, that's something they could have done
> anyway.
>
> Can you be more concrete about what you are worried about and what you
> want us to do about it?-
>
> David
>