IETF Logo Mail Archive

Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt

Nico Williams <nico@cryptonector.com> Fri, 04 May 2012 21:53 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3202521F84EF for <tls@ietfa.amsl.com>; Fri, 4 May 2012 14:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PH0bpYl6DURt for <tls@ietfa.amsl.com>; Fri, 4 May 2012 14:53:46 -0700 (PDT)
Received: from homiemail-a84.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id B2AAC21F84EB for <tls@ietf.org>; Fri, 4 May 2012 14:53:46 -0700 (PDT)
Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 520841DE060 for <tls@ietf.org>; Fri, 4 May 2012 14:53:46 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=f8J4mjheb04LlE+0yLrF+HotfBLwPxj7bGD9Qfw2xqNW gJmSv4QSNUqW8EU1/n/K1Rf6J0GAkA229XoDQzILDG5/PaY9GyLggdvcJX9iYtAI 3a5T+7BPMrf7F7Mgj7mb1bbmy1L0xmE86/uleoG8j8uOIJS2EbBXAG4Y2CaE2oE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Ghm03S7kkV0VvlT1x0n+Hw3ckVU=; b=af9mmDkFjV7 BaGf5+Ps5TCko4vI/bpQtp46UeeNWbcBBxvNX1PbTEkHzfiwAyA+cKoPFFCJGu1L 7hJgk5bijYs8ObIjGsMjd4RND3iUBeQPvkQhodvXYb24vOcaCuVZC5d9H/v1wWJv JKWvcATaeV+lYb8SsdiAAmRTWrnZTLsY=
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 593FF1DE070 for <tls@ietf.org>; Fri, 4 May 2012 14:53:45 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so2817838vbb.31 for <tls@ietf.org>; Fri, 04 May 2012 14:53:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.155.131 with SMTP id s3mr933913vcw.15.1336168424646; Fri, 04 May 2012 14:53:44 -0700 (PDT)
Received: by 10.220.7.65 with HTTP; Fri, 4 May 2012 14:53:44 -0700 (PDT)
In-Reply-To: <6296DC06-A0A4-4A75-9FCC-AE0B402CBD20@checkpoint.com>
References: <4FA401F7.5060003@extendedsubset.com> <6296DC06-A0A4-4A75-9FCC-AE0B402CBD20@checkpoint.com>
Date: Fri, 04 May 2012 16:53:44 -0500
Message-ID: <CAK3OfOh=iU6hqaAkq88ngJ7-Q-SkR2fP7H5BSfDu=Uz_+GAHJQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-ray-tls-encrypted-handshake-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 04 May 2012 21:53:47 -0000

On Fri, May 4, 2012 at 4:13 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> IMO this is a huge change to the TLS state machine. Much bigger than the diff between TLS 1.1 and 1.0, and bigger than the difference between 1.2 and 1.1. This should not be an extension but a new version number. You would still need an extension to carry the extra information (if we want backwards compatibility), but negotiating this capability should be done at the version level.

But the experience we've had with new versions doesn't fill one with
confidence that a new version can be deployed quickly at all.
Extensions have been much less problematic.

I think it'd be best to introduce new versions only for dramatic
changes that require downgrade protection.  (I realize that's not a
great description of the rule I have in mind.)

Nico
--

v2.23.0 | Report a Bug | By Email