[TLS] Point validation in 1.3

Watson Ladd <watsonbladd@gmail.com> Tue, 15 November 2016 07:16 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD821295EF for <tls@ietfa.amsl.com>; Mon, 14 Nov 2016 23:16:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 6nvkMv8lDz0d for <tls@ietfa.amsl.com>; Mon, 14 Nov 2016 23:16:47 -0800 (PST)
Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 5ACEF12944D for <tls@ietf.org>; Mon, 14 Nov 2016 23:16:47 -0800 (PST)
Received: by mail-vk0-x230.google.com with SMTP id x186so82429264vkd.1 for <tls@ietf.org>; Mon, 14 Nov 2016 23:16:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=+bt94Q0J1mKTKsm/a8vcLXirhQvVpqI6TMPGBCu8AIg=; b=YV7GbL52wAv4qObkUTk8/QviffdDTzC7BWl6Oxfbj7gOIboPHuKZaMHTzPIcVgW5T6 AEfweP9eDh3xCC+ZS852J4YVTuOQV5RBbSa8XkUMJOzQjaTRmWPhMUitmZgsUoBo3H5v WV2YPEJAmqNWWw/qbwpxKgp60dEf9B9N+rIZqNXArQJs74ORHssvRiRcFwYoJQ3omNWE P68yCP0upbKekagmT9Jm2WIyC5pn44sD2lTYFo2tNir5ow3SDBm5ClAT2ygjd47s+QcG dmfSMyrx+jQfUgixDp/AjbAIzvqHaB4Wxk8uEFaM0zdK3fL13Wk5AmxWkK9bk/EyR7Dh Tnng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+bt94Q0J1mKTKsm/a8vcLXirhQvVpqI6TMPGBCu8AIg=; b=ZlqwfoJof8FG/Q+x2rnBtFDHVUw8jZKh/I1GDYKo/AtAyOHeUZTwiQMkwQi5g4hNEc ZlsWEMWM/AqWDbxswvXGlcmwu47AEV7UMJ/hjbKuYJgtNtVQj/g9N+0f2MvdsfYVG3Zx LxmZh0wmCWXc8XO/FwKQuyQJLP+5YGdNS8ocXfH5yuBWVZZl78FveS6dnOu4ffdXMm28 iDytp7fiPMbPGvBwulW8QlmeWKPszn42KH6VgyFd0tNQ+TUYj6tLbBaCNybxLAenQ5Fg L4GKvebY1YpAf59k0DI8QAKMQOKA6sdJeEk1wqRxxr5/euWksIbKEBEJ9E+uxivRdGfG xQaA==
X-Gm-Message-State: ABUngvc3SpUBIFoPRrjDJmNNo8tiQzHUgwgAmuF1ehAA8vUMHQM0Fr7iOZiF+rI5tqIje704zz87K8cgovoY4w==
X-Received: by 10.31.162.72 with SMTP id l69mr12680584vke.123.1479194206099; Mon, 14 Nov 2016 23:16:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.85.18 with HTTP; Mon, 14 Nov 2016 23:16:45 -0800 (PST)
From: Watson Ladd <watsonbladd@gmail.com>
Date: Mon, 14 Nov 2016 23:16:45 -0800
Message-ID: <CACsn0cnX90rOH0OQzzksrg1CYLeDugt_tT3+EKBY=tZ37oFR4w@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114368da356c57054151bda1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/X85ZrqzAWgU_rPRNEJhKRnM6G50>
Subject: [TLS] Point validation in 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Nov 2016 07:16:48 -0000

Hello,

There has been a lot of chatter on Gitub about point validation. I think
it's important to note that in TLS 1.3 the Triple Handshake variants
enabled by small subgroup attacks are no longer a threat: the issue is
reuse of ephemeral Diffie-Hellman exponents, resulting in compromise of
what is effectively a long-term key.

I would want a belt and suspenders approach: no use of ephemeral exponents,
and validation that points are on the curve. Order validation is
unnecessary as the cofactor is small: in cases where it is not the curve
probably shouldn't be used without a good reason, and I can't think of any.

I know one implementation does keep ephemeral exponents indefinitely. This
implementation also validates orders, which equals the expense of not
regenerating ephemeral exponents.

Sincerely,
Watson