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

Daniel B Giffin <dbg@scs.stanford.edu> Thu, 08 November 2018 21:19 UTC

Return-Path: <dbg@scs.stanford.edu>
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 AF46A12D7F8; Thu, 8 Nov 2018 13:19:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=scs.stanford.edu
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 ZqaJe9J2mclm; Thu, 8 Nov 2018 13:19:38 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C19A12D4E8; Thu, 8 Nov 2018 13:19:38 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.16.0.29/8.16.0.21) with ESMTP id wA8LJaTq074720; Thu, 8 Nov 2018 13:19:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1541711976; bh=0oiAAV5IhjLbzJQ0vs2tgMVxJ2rKGu0lZ0bN9o+lBcs=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: In-Reply-To; b=ftM3LkOF9lQZdk4TkUML2LverkUzPSLHrPVftClgmylqfnrlflR8/ASq+j1Hmdu6T s5d8fSB70PJ0bn0OABFStsJOrGN0AVNHKuYDGUK+pGwoMBzAf8aRkW56joW4a9bHGm INyESN61WcSHuN9iSi3jmtnYkG0S8OrsKuysXfQE=
Received: (from dbg@localhost) by market.scs.stanford.edu (8.16.0.29/8.16.0.29/Submit) id wA8LJaDd078908; Thu, 8 Nov 2018 13:19:36 -0800 (PST)
Date: Thu, 8 Nov 2018 13:19:36 -0800
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: Eric Rescorla <ekr@rtfm.com>
Cc: mazieres-nj788xtv7k4q4yq2nedg4eupms@temporary-address.scs.stanford.edu, tcpinc <tcpinc@ietf.org>, 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
Message-ID: <20181108211936.GA38291@scs.stanford.edu>
References: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABcZeBNHxqU0k+jK61zTKoUmuY2V9tcgEZM9Y=R5RkciZjnXtQ@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/IU8somFofPsn77_vkQDI9bo5krM>
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: Thu, 08 Nov 2018 21:19:40 -0000

Eric Rescorla wrote:
[..]
> 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?

The draft currently says:

   Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 use the
   functions X25519 and X448, respectively, to perform the Diffie-Helman
   protocol as described in [RFC7748].  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].  [...]

This requires, perhaps too gently, the (Montgomery ladder)
algorithm in RFC 7748.

In contrast, RFC 8446 allows other, (non-Montgomery)
algorithms to be used to compute X25519 and X448 in TLS:

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

But it is not clear exactly what "additional checks" are
required (reject all invalid keys?), and for what purpose
(ensure some "contributory behavior" property?)

It seems the only observable difference would be that other
algorithms might abort on some invalid DH inputs that the
RFC 7748 algorithm accepts.

So there are two orthogonal questions here:

- Should tcpcrypt allow implementations that behave
  differently from RFC 7748?

- Given that tcpcrypt does not depend on any "contributory
  behavior" property, is there any use in requiring DH input
  validation?

If other algorithms are allowed *and* input validation is
required, it seems we will have to explain more clearly what
validation entails.

d