Re: [TLS] Simplify, simplify, simplify

Fabrice <fabrice.gautier@gmail.com> Thu, 15 May 2014 06:07 UTC

Return-Path: <fabrice.gautier@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 2FEE51A03DD for <tls@ietfa.amsl.com>; Wed, 14 May 2014 23:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=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 b5PN3e5rlt8X for <tls@ietfa.amsl.com>; Wed, 14 May 2014 23:07:20 -0700 (PDT)
Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7811A03D9 for <tls@ietf.org>; Wed, 14 May 2014 23:07:20 -0700 (PDT)
Received: by mail-pb0-f43.google.com with SMTP id up15so646889pbc.16 for <tls@ietf.org>; Wed, 14 May 2014 23:07:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PlY+bToet4JhNIUGtzCJQ5/WoAZWc07dceRpTuZEvDo=; b=VUuagBODa9fDyoNCA8tNAEpTeWK6cy1+uPAAye52xj1cJSBSOmgV1zsr3SnpRUcj/D wbRQIOyox+odiGCxTrInhhzQq9+LHKSnD+dMeGN3iXrap/aZXkGk7ah2rC9Y2Yxxxljs KPFzKAhdjaAmiYEbyG3tsLSl8URfYnI6PgXs1KPlhK+J3xGryEkcQtuXXGcVrppuNmx+ Cr72sSU+Y8lKlZEuhsQVIUiB/mkfhkFumQkEMv32jI5I4mWAh0cDVemyXX4f+rHjQc4F gZtC0sQkIjbUdkBiCKbRpRiuKP9NDd+HSD0qX6FrS3jfgxFNxRCHklWvxFGql7MB4rFe h3Vw==
X-Received: by 10.66.102.74 with SMTP id fm10mr10164855pab.86.1400134033710; Wed, 14 May 2014 23:07:13 -0700 (PDT)
Received: from [10.0.1.4] (c-67-188-142-21.hsd1.ca.comcast.net. [67.188.142.21]) by mx.google.com with ESMTPSA id rw4sm16756451pab.47.2014.05.14.23.07.11 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 May 2014 23:07:11 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Fabrice <fabrice.gautier@gmail.com>
X-Mailer: iPhone Mail (11D167)
In-Reply-To: <53745355.2010708@pobox.com>
Date: Wed, 14 May 2014 23:07:10 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <C731C9B3-B2C3-4AB9-B725-D098703076FB@gmail.com>
References: <CACsn0c=q_cMnkRo6aaThG4aXNQwQUJSs3B4-o2oKvar0YVBotw@mail.gmail.com> <53745355.2010708@pobox.com>
To: Michael D'Errico <mike-list@pobox.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KwGZLGJ0r9cf9neC49_Z11LLw80
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Simplify, simplify, simplify
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, 15 May 2014 06:07:25 -0000

> On May 14, 2014, at 22:40, Michael D'Errico <mike-list@pobox.com> wrote:
> 
> How do you get around the way version negotiation works?  If a client
> asks for TLS 1.3, and the server doesn't support it so it replies with
> TLS 1.2, the client has to know how to speak 1.2.

No, at that point the client can refuse to speak TLS 1.2 and abort the connection,

... then restart a new connection using it's legacy TLS 1.0 implementation. 

>  There's no way for
> the client to say it supports TLS 1.0 and 1.3, but not 1.1 or 1.2

You could also have out of band indications of what the servers support, so that you avoid the reconnection in most cases. 

I don't see a simple and efficient way though, so I guess you have a point...

> 
> Mike
> 
> 
> 
> Watson Ladd wrote:
>> Dear all,
>> As we are about to embark on a meeting to produce a protocol, let me
>> bring forwards what a veteran IETF participant believes about
>> protocols:
>> https://www.w3.org/2014/strint/papers/34.pdf
>> If TLS 1.3 is easier to deploy then TLS 1.2 it will be deployed.
>> Otherwise it will not be. Some of the specific recommendations are for
>> other WGs (in particular DANE, DNSSEC, and whoever is in charge of the
>> mess that is PKIX), but I think that the bottom-line message is worth
>> listening to: simplicity is the single most important criterion for a
>> security protocol.
>> Sincerely,
>> Watson Ladd
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls