Re: [TLS] TLS process thread

Watson Ladd <watsonbladd@gmail.com> Mon, 14 April 2014 05:44 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 492301A035B for <tls@ietfa.amsl.com>; Sun, 13 Apr 2014 22:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.3
X-Spam-Level: *
X-Spam-Status: No, score=1.3 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, 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 1jzyK8nP1zIu for <tls@ietfa.amsl.com>; Sun, 13 Apr 2014 22:44:15 -0700 (PDT)
Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [IPv6:2607:f8b0:4002:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1789C1A0354 for <tls@ietf.org>; Sun, 13 Apr 2014 22:44:15 -0700 (PDT)
Received: by mail-yh0-f43.google.com with SMTP id b6so7607028yha.16 for <tls@ietf.org>; Sun, 13 Apr 2014 22:44:12 -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; bh=r4odjHTxtKXz/97xlbEYU12Z95RJIOd+cz8w+Ff9xTo=; b=1E9au42axGos5MsUXIKF+52KNCRjjRqSJEfSsn0UcjSk7iq4TANOPEkCdyBk81E3FR MV2JQSK3UGlV+WfnY3KJF+b7jEGYfwa5CRA2Y1kstI7wdHksvZ2mJnkWx23qTMi0ExEv JdZrx7ft0ay0iQq1oTG1OMwqJeBZmm6J4cFE2CmS+vbHbMGN0oe0Rtlc7oWRzzBh2Zru tYoI6pVjFzze9+hpVjYkMnMN6vetpvgTZxVafR6PQQGjjaFv3xF4XeccjW/l4jEqcci4 bjMAEwB9/et5rlCOk1oGAi8YSVf7GWFcYkKuKo8jjzMcQ4m3/hsbL5xIPeWGlU7ZoOoT H/QA==
MIME-Version: 1.0
X-Received: by 10.236.162.65 with SMTP id x41mr54144866yhk.25.1397454252685; Sun, 13 Apr 2014 22:44:12 -0700 (PDT)
Received: by 10.170.63.197 with HTTP; Sun, 13 Apr 2014 22:44:12 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738AC00E25@uxcn10-tdc06.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C738AC00E25@uxcn10-tdc06.UoA.auckland.ac.nz>
Date: Sun, 13 Apr 2014 22:44:12 -0700
Message-ID: <CACsn0cm10Mc6V6XtdVjtooLi2piekdEjXmys2RgaU9NCDGxNvA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PuckphtX1rk2Sho5J8vIAj_9Ctw
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] TLS process thread
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: Mon, 14 Apr 2014 05:44:19 -0000

On Sun, Apr 13, 2014 at 8:31 PM, Peter Gutmann
<pgut001@cs.auckland.ac.nz> wrote:
> Sean Turner <TurnerS@ieca.com> writes:
>
>>In this case, however, our charter provides a clear starting point, namely
>>RFC 5246, and a mandate to minimize the changes to that document.
>
> If the charter really does require that then it sounds like it's high time to
> update the charter...

In particular, we need to make significant changes to the handshake to
address insecure resumption, use a completely different record layer
because of Lucky13 (might as well make it AEAD, as Chacha20+Poly1305
and AES-GCM do that, and whatever fixed up AES+hash people want to use
can be shoehorned in), renegotiation is probably going to die as no
one needs it. (HTTP can use another header number to signal that you
need a certificate, a reconnection is not the worse thing in the
world, no one understands what renegotiation is supposed to do, and
client certificate sensitivity can be fixed by not putting real names
in them)

That's going to be a pretty big change from RFC 5246. Trying to keep
the textual changes minimal probably a lost cause at this point, and
will hurt, rather than help clarity. This is before we try to reduce
round-trips, eliminate unused ciphersuites, introduce the Edwards
curves (necessary for security because people do not write perfect
code, even when they should), and ensure that what we write matches
what we prove (because as I'm sure you know from my opposition to
Dragonfly, I do not support mechanisms that are not shown to be secure
from well picked assumptions)

We can't not make the first changes, and it seems like the second half
of the changes are going to happen anyway. Unless you want another
block of MTI extensions that obviate vast swaths of the RFC, the
entire protocol needs to be edited and presented as a whole. I don't
see a way to do that and adhere to "minimize changes".

Sincerely,
Watson Ladd

>
> Peter.
> _______________________________________________
> 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