Re: [TLS] TLS 1.3 process

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sun, 30 March 2014 23:47 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
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 624F11A08EA for <tls@ietfa.amsl.com>; Sun, 30 Mar 2014 16:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, T_RP_MATCHES_RCVD=-0.01] 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 yAM8Dx0u0woj for <tls@ietfa.amsl.com>; Sun, 30 Mar 2014 16:47:04 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE1F1A08E4 for <tls@ietf.org>; Sun, 30 Mar 2014 16:47:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1396223221; x=1427759221; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1Xxig9F7m9VuJhGz/XmOkjMYIinTxtv8RBXtNOCGElU=; b=R5vuDi0SEz58SSSnDM7O/U+ceaB3ITWv9tEoBlliTeZV98kclQvVSOhE HK4UKCxpQtwGd897Spv9cJiz+2pYggiXhF3zCYl1icjx1+DdCoTQShBH2 71/WcvCnsMcU63BxgWQ6B3sO6xRC85tMzHbTKDF2KiRw7HaMbgZyw90Na k=;
X-IronPort-AV: E=Sophos;i="4.97,761,1389697200"; d="scan'208";a="243835725"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 31 Mar 2014 12:46:58 +1300
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.111]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Mon, 31 Mar 2014 12:46:57 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] TLS 1.3 process
Thread-Index: Ac9MclYHHCcYDGdIRdywo9NEYSgKMQ==
Date: Sun, 30 Mar 2014 23:46:57 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C738A33738A@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V_iOoArEMc1aav0AQY0lIl6hLbw
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: Sun, 30 Mar 2014 23:47:06 -0000

Dan Harkins <dharkins@lounge.org> writes:

>But everyone in the WG is concerned about getting encryption to work
>correctly. We're also all concerned about getting authentication to work
>correctly. And about getting authenticated encryption to work correctly.

Some of us are more worried about making it fit for purpose than in fiddling
with crypto details.  The former requires careful thought, for the latter you
just pull a known-good mechanism off the shelf at the end of the design
process, plug it in, and you're done.  To quote Peter Fairbrother on the
crypto list:

  A similar design methodology should be used for security products (and
  software products).  Start with the purpose of the product, then the human
  and electronic interfaces, then the hardware and last of all the detailed
  crypto or code. Oh yes, you think about the crypto all the way through, but
  only in terms of what is possible and what resources it will take - worry
  about the detailed crypto (or code) last.

>I fail to see how documenting use cases will help us get encryption to work
>correctly

It'll allow us to see whether the encryption is fit for purpose.  Since I'm in
a quoting mood I'll do Bob Morris this time:

  The behaviour of a system without a specification can never be wrong, only
  surprising.

TLS has certainly shown some... surprising behaviour over its lifetime.

Peter.