[Cfrg] Switching the zero-check from MUST to MAY in the curves draft.
Adam Langley <agl@imperialviolet.org> Mon, 16 November 2015 23:03 UTC
Return-Path: <alangley@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 816601A8A23 for <cfrg@ietfa.amsl.com>; Mon, 16 Nov 2015 15:03:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 PWYivmUwY5-5 for <cfrg@ietfa.amsl.com>; Mon, 16 Nov 2015 15:03:03 -0800 (PST)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 1C9F61A8A1E for <cfrg@irtf.org>; Mon, 16 Nov 2015 15:03:02 -0800 (PST)
Received: by qkfo3 with SMTP id o3so124462090qkf.1 for <cfrg@irtf.org>; Mon, 16 Nov 2015 15:03:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=YksFIW60QPbJfejeT5kS27bkwPqyWj4JrwCybQhrmSI=; b=DO3IKT+h0WcinG5jTV/N8eCjN7ETXV3Kf3MN5tDHp4fjKyaHDHpWRX/po6dxsWcDxI i9xUos7LtvHwVA7T2ANDKxqR3Qczfzwm5zbneu+NU0+0G8jmoVt2GQuTCWMA+2+2TycT UBmofvWFiz1IxcOfWBsUUu2cUxGMRm66bVLDrxkemtp+1o+v8qJdk/WNY+1BFM9Mes95 n5kiJ3yx3TGykbTDqxO6TwQYPloYfBJnN87vEhCZqk0uNhKCNQm9ZHcG+/Fco2OCu8rG seAhcYWXPz4Pd1mP/LWc3hIOMj3hoUhasGAJhgfWqUTr9Brvw+LmH8Rg761GZYmMHphy 4nFA==
MIME-Version: 1.0
X-Received: by 10.55.71.203 with SMTP id u194mr37348043qka.14.1447714981937; Mon, 16 Nov 2015 15:03:01 -0800 (PST)
Sender: alangley@gmail.com
Received: by 10.140.97.66 with HTTP; Mon, 16 Nov 2015 15:03:01 -0800 (PST)
Date: Mon, 16 Nov 2015 15:03:01 -0800
X-Google-Sender-Auth: BLBsigYYnpjYxGycrEGGXcD5Wv4
Message-ID: <CAMfhd9XgxrFyRxEqd=4NSX29t=ymQeyq3pT6VjpezUgrm6TyBg@mail.gmail.com>
From: Adam Langley <agl@imperialviolet.org>
To: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/khKjcRgkgHGMtyXUWmQJ62Be-nE>
Subject: [Cfrg] Switching the zero-check from MUST to MAY in the curves draft.
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2015 23:03:04 -0000
At the moment, the curves draft says that implementations MUST check for the all-zero output and abort if it's found, at least in Diffie-Hellman. The all-zero output results when the input point has small order and this sort of thing has, in the past, broken at least Tor and TLS channel bindings. While reactions on the list were ambivalent to the suggestion, I had hoped that implementations would take this requirement as a simple defence-in-depth measure in keeping with the general robustness theme of this work. I was mistaken. It's since become clear that some disagree sufficiently strongly about this that we aren't going to see a realignment of implementations around this behaviour. While I still think that it's a sensible requirement, RFCs that are prescriptive rather than descriptive are terrible and so I currently hope to switch from MUST to MAY once the draft has completed the editor's queue. Instead, some wording would be added to the Security Considerations section. This change contains the accumulation of tweaks that I currently have saved up, including this one: https://github.com/agl/cfrgcurve/commit/c7749d4bb5ceabdb30f211d4aaa6df2b68d7c5e1 This email is notice that I currently plan on making this change. Note that the question here isn't whether the zero check is a good idea or not. Rather it's that, given that a non-trivial number of implementations aren't going to implement it, what's the best thing to write? Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
- [Cfrg] Switching the zero-check from MUST to MAY … Adam Langley
- Re: [Cfrg] Switching the zero-check from MUST to … Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] Switching the zero-check from MUST to … Deirdre Connolly
- Re: [Cfrg] Switching the zero-check from MUST to … Phillip Hallam-Baker
- Re: [Cfrg] Switching the zero-check from MUST to … Mike Hamburg
- Re: [Cfrg] Switching the zero-check from MUST to … Taylor R Campbell
- Re: [Cfrg] Switching the zero-check from MUST to … Watson Ladd
- Re: [Cfrg] Switching the zero-check from MUST to … Phillip Hallam-Baker
- Re: [Cfrg] Switching the zero-check from MUST to … Adam Langley
- Re: [Cfrg] Switching the zero-check from MUST to … Deirdre Connolly
- Re: [Cfrg] Switching the zero-check from MUST to … Rene Struik
- Re: [Cfrg] Switching the zero-check from MUST to … Rene Struik
- Re: [Cfrg] Switching the zero-check from MUST to … Greg Hudson
- Re: [Cfrg] Switching the zero-check from MUST to … Watson Ladd
- Re: [Cfrg] Switching the zero-check from MUST to … Rene Struik
- Re: [Cfrg] Switching the zero-check from MUST to … Watson Ladd