Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3

Watson Ladd <watsonbladd@gmail.com> Thu, 27 March 2014 15:21 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFB31A06FB for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 08:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 W9_vrhPZ2ovS for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 08:21:41 -0700 (PDT)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C05061A06F3 for <tls@ietf.org>; Thu, 27 Mar 2014 08:21:41 -0700 (PDT)
Received: by mail-yh0-f42.google.com with SMTP id t59so3770953yho.1 for <tls@ietf.org>; Thu, 27 Mar 2014 08:21:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=RboWv+f29uhFZUxx8gX5Bxw+yjavFko+SflVAZWPzf4=; b=h+miTv07b65QKY9yZlRv5mx8wl8/Qy7fZtbdoL6vDsyi+khTbE4butCVkuconWgDW9 l1fVp1B4kvMHoHFLnRaAr/2/MT5b42gmvtdFp3PunNMwp0Uj/UEoLmz1huPOTHN+W+ID ixQmzyLgTH2m4wIhmEx0r70Z+GtW1rM5DRJGAauTlwL4/Jm67mlnDKDpxahDFM/MylyV cp4S0IRM87Svh32zleJwku4frAUVGO9rOZdBNOqRJ/rIs+qtD/4Dm9oh2RGU6r8iR6Ax Jk6qtQo0XmQvM/AYJb9MiIX8M4ilEMENXVwg6Ns7iUj/r1Kp4YVOTd2IHCSrTDrvOIZI kqCQ==
MIME-Version: 1.0
X-Received: by 10.236.139.70 with SMTP id b46mr3182254yhj.63.1395933699927; Thu, 27 Mar 2014 08:21:39 -0700 (PDT)
Received: by 10.170.80.214 with HTTP; Thu, 27 Mar 2014 08:21:39 -0700 (PDT)
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE390@USMBX1.msg.corp.akamai.com>
References: <AD51D38F-2CFE-4277-854D-C0E56292A336@cisco.com> <20140326211219.27D281AC7D@ld9781.wdf.sap.corp> <20140327095527.5335c7fa@hboeck.de> <20140327115551.GA24503@randombit.net> <6f43d6c5-b70f-4a80-98e6-f653011317c7@email.android.com> <2A0EFB9C05D0164E98F19BB0AF3708C711FD4AE390@USMBX1.msg.corp.akamai.com>
Date: Thu, 27 Mar 2014 11:21:39 -0400
Message-ID: <CACsn0ckN_OXcU61jOWNG_HjoxuMgNHwfPMzrad6A-tLrf0bzWA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2TDFCmy6T5pgOybvXSwOWSD_CcI
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Confirming Consensus on removing RSA key Transport from TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 27 Mar 2014 15:21:43 -0000

On Thu, Mar 27, 2014 at 10:15 AM, Salz, Rich <rsalz@akamai.com> wrote:
>> I'm wondering: why even keep DHE around at all?
>
> Don't put all your eggs in one basket.

This is a good argument for preserving DHE. However, we lose
everything when quantum computers come out. NTRU or McElise modes
would be better backups.

>
>> especially curve25519 (which we have a live draft for now
>
> I really like Curve25519, but the current draft is sub-optimal in how it specifies the encoding. If we want the curve for its performance gains, then we should encode things using its native, "most natural" format. Fixing that requires a curve registry, etc.  Hopefully the CFRG or the Security AD's will help with that.

Integers have no natural encoding: you're complaining that one
particular fast implementation encodes them a certain way.  As for the
registry etc, there are plans, but they have stalled admit rampant
fence painting. I'll resubmit the safecurves draft and see if that
gets things going again.

Sincerely,
Watson Ladd
>
>         /r$
>
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin