IETF Logo Mail Archive

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

Daniel B Giffin <dbg@scs.stanford.edu> Thu, 29 November 2018 18:41 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 E795A130E58; Thu, 29 Nov 2018 10:41:25 -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 YA1V8QAzP64C; Thu, 29 Nov 2018 10:41:24 -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 9A69B130E5C; Thu, 29 Nov 2018 10:41:24 -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 wATIfN7r020703; Thu, 29 Nov 2018 10:41:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scs.stanford.edu; s=scs; t=1543516883; bh=0Xn9tAIfim/rdWuozUH594eSj0qAUeRw3TkKpCFyEE8=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: In-Reply-To; b=S8UX3AFP4HlKpQNr2Qvlb5BDc67xeNszDrNpDa1wkSi/JK2KmQHxyVdo66HN1pm4X 280jkeYxYTBTLVuHTa/ahGz3eNADWZGaNv68ph/H4RIZm6nc8g5EV7bW5wS3I3sahe ZZedfhJl9V4mf9w7VinAF4Zev8lPRFe5V4GGLbIk=
Received: (from dbg@localhost) by market.scs.stanford.edu (8.16.0.29/8.16.0.29/Submit) id wATIfMwG086409; Thu, 29 Nov 2018 10:41:22 -0800 (PST)
Date: Thu, 29 Nov 2018 10:41:22 -0800
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: Eric Rescorla <ekr@rtfm.com>
Cc: tcpinc <tcpinc@ietf.org>, Kyle Rose <krose@krose.org>, tcpinc-chairs@ietf.org, mazieres-nj788xtv7k4q4yq2nedg4eupms@temporary-address.scs.stanford.edu, "Black, David" <David.Black@dell.com>, IESG <iesg@ietf.org>, draft-ietf-tcpinc-tcpcrypt@ietf.org
Message-ID: <20181129184122.GA26520@scs.stanford.edu>
References: <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> <20181108211936.GA38291@scs.stanford.edu> <CABcZeBP_x91zXJv-F07ptxSduwWq-7va=_hpwW8J1sgDKMh5pA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBP_x91zXJv-F07ptxSduwWq-7va=_hpwW8J1sgDKMh5pA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/7VNoqgrf8rU0scHZxqgXjbTtwvs>
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, 29 Nov 2018 18:41:26 -0000

Okay, how about this language that harmonizes with the SSL
approach:

  Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448
  perform the Diffie-Helman protocol using the functions
  X25519 and X448, respectively.  Implementations SHOULD
  compute these functions using the algorithms described in
  RFC7748.  When they do so, 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.  Alternative implementations of these
  functions SHOULD abort when either input would force the
  output to one of a small set of values, as discussed in
  Section 7 of RFC7748.

That last sentence is explicit (or as explicit as practical
in the scope of this document) because I really can't find
any *instruction* in Section 7 about input checking.

d

v2.23.0 | Report a Bug | By Email