Re: [TLS] TLS 1.3 process

Watson Ladd <watsonbladd@gmail.com> Thu, 27 March 2014 22:56 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 25A3F1A0274 for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 15:56:31 -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 KsPo1LrQiPmd for <tls@ietfa.amsl.com>; Thu, 27 Mar 2014 15:56:28 -0700 (PDT)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4201A024E for <tls@ietf.org>; Thu, 27 Mar 2014 15:56:28 -0700 (PDT)
Received: by mail-yk0-f182.google.com with SMTP id 142so102833ykq.41 for <tls@ietf.org>; Thu, 27 Mar 2014 15:56:26 -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=O+FFPqKXVxCcjjAvA619ptG0MkmmvaFPDBuu672g36Y=; b=PUcpg35T0lOntBmF6b9PiCFxv7SF2s0RBY8JR5ySE2x8qOCftLBP57zvEFmz5m0OCI maxVxvUtmD2i66iEvHd27AvVziAsumlV6gusD8NvXJZLgo8gHPKwxqqax5mtuHElEiX/ nzTugztwykOQBm0TQZ8w9dFBOsfe6v2GIgAGWMc3rtoqHko178AZubIQKNgqR+TYTJSs +HFI/C2jX2qAdIXx5yT935YMMm/AyXUCDl6wsR9V2vDogXj+TUJKKQNq6XwMozW26lU5 tEksVBCajQZsBZPTTFeFfiqJoYQWWi0fizDN6U52BqiHEssyARyXuZuQ7pZaN8Sr8M5w WsyA==
MIME-Version: 1.0
X-Received: by 10.236.163.8 with SMTP id z8mr573043yhk.43.1395960986253; Thu, 27 Mar 2014 15:56:26 -0700 (PDT)
Received: by 10.170.80.214 with HTTP; Thu, 27 Mar 2014 15:56:26 -0700 (PDT)
In-Reply-To: <AF370E26-CA97-4CE3-9CC7-2F0939FE2B71@ieca.com>
References: <AF370E26-CA97-4CE3-9CC7-2F0939FE2B71@ieca.com>
Date: Thu, 27 Mar 2014 18:56:26 -0400
Message-ID: <CACsn0cms8=BcBA9Z91wy8kUWbrshfThhKx3YOHnjtnPWddQMaw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Sean Turner <TurnerS@ieca.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/g40g2wy6vD3InhhJSVDTk3lE92Y
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 process
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 22:56:31 -0000

On Thu, Mar 27, 2014 at 5:48 PM, Sean Turner <TurnerS@ieca.com> wrote:
> All,
>
> The TLS WG charter is pretty clear that the intention isn't to design
> a completely new protocol but rather to revise TLS, and specifically
> to "place a priority in minimizing gratuitous changes to TLS." This
> is not to say that we can't consider new cryptographic handshake flows
> -- TLS has always been open to that -- but completely replacing TLS
> with a new protocol is out of scope for this WG.
>
> With this in mind and regard to the bigger question about the
> process, here's how the chairs intend to proceed:
>
> 1. Start with the existing TLS document. As usual in IETF, this
>    doesn't mean that any particular piece of the document cannot
>    be changed if the WG wants to, but it's where we will start;
>    it also makes it a lot easier to get through the process
>    since the IESG, directorates, and WGs that depend on TLS
>    can see what changed.
> 2. If possible, remove the pieces we agree we don't need (hence the
>    recent consensus calls).
> 3. Settle on the high-level handshake flows (charter items #1 and #2)
>    in light of #2.
> 4. Reevaluate the handshake PDUs (charter item #4)
> 5. Update record protection mechanisms in the record layer
>    (charter items #3 and #5)
> 6. Iterate on the document until complete. Key to this process is
>    getting input from academic cryptographers, which is why we
>    are prioritizing the handshake flows, because they are probably
>    the piece that needs the most analysis.
> 7. Publish.

I don't think this will work out well for the following reasons.

Firstly, the TLS spec is a mess. Necessary extensions aren't included,
so if you want to use ECDHE, you need to go on a hunt for the proper
specification. Likewise, if you want secure renegotiation, that gets
incorporated by reference also. There isn't a clear model of what is
supposed to happen in conforming implementations. Fixing this will
require major editing. ECDHE encodings can't accommodate anything that
isn't a short Weierstrass curve over a prime or binary field, which is
causing trouble on curve25519. This sort of housekeeping isn't
interesting, or rewarding. It is necessary to avoid the "Oh, well,
this RFC you never heard off addresses the issue in the one you
thought would be the right one to look at" problem.

Secondly, the record layer issues are much worse than the handshake
issues in TLS 1.2. There are good handshakes like ECDHE_RSA and
ECDHE_ECDSA available today, with side-channel protected
implementations on all platforms. That cannot be said for the record
layer: AES-GCM only works on late Intel hardware without side
channels, even with the Käsper-Schwabe implementation. It would be
desirable for any fix for this issue to work on TLS 1.2 as well. There
are already drafts handling this, as well as work in UTA. Tying this
work to a version number bump would be ridiculous.

Thirdly, the handshake issues are much worse than the record layer
issues in TLS 1.2. We understand what the record layer is supposed to
do. We don't understand what the handshake is supposed to do: channel
bindings got broken because they made assumptions that the handshake
layer didn't in fact meet. In contrast we understand very well what
the record layer is supposed to do, and why the existing options fail.
I don't see people thinking about the interactions between 0-RTT,
existing resumption, and channel binding. It could be quite fun. We
still don't have anything concrete to critique or analyze here.

Given all this, I would say the best thing to do is focus on the
handshake while the committee does the record layer enhancements via
enhancements to TLS 1.2, and have TLS 1.3 focus on the handshake fixes
and enhancements that are required after that.

Sincerely,
Watson Ladd

>
> With that said, the reason for the present consensus calls should be
> clear, as they are intended to either remove pieces (#2) or resolve
> requirements for the handshake (#3).
>
> To sum up: We have a set of requirements, from the charter and
> from the consensus calls we're having now.  Our chartered goal is
> to meet those requirements with the minimum set of changes to TLS.
>
> TLS co-chairs
>
> j & e & s
>
> _______________________________________________
> 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