Re: [TLS] One approach to rollback protection
Matt McCutchen <matt@mattmccutchen.net> Tue, 27 September 2011 15:48 UTC
Return-Path: <matt@mattmccutchen.net>
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 7BD5321F8DC8 for <tls@ietfa.amsl.com>; Tue, 27 Sep 2011 08:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 KGdCMU9MnN63 for <tls@ietfa.amsl.com>; Tue, 27 Sep 2011 08:48:20 -0700 (PDT)
Received: from homiemail-a4.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id D2E4D21F8D97 for <tls@ietf.org>; Tue, 27 Sep 2011 08:48:20 -0700 (PDT)
Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 8CF9F51C063 for <tls@ietf.org>; Tue, 27 Sep 2011 08:51:06 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; q=dns; s= mattmccutchen.net; b=fsi6tmeUAf4ItOJxeLnOnuy408djgyrAsdjztxD37c2 3p1Cb2Dpm7ORHob74Q7ykimxu2h4DDfdVuZra3MTjRPG1YkIBBpQ8jfrjXiV+Jmm +g+X1x+55+gO7teqSHFvLVB14lDP31Hc9GtuS8ANLoQeROHJfMTmAPysw0M+RpVM =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:date:in-reply-to:references:content-type :content-transfer-encoding:message-id:mime-version; s= mattmccutchen.net; bh=DJij+Gm5DFMCsSj72IeA+7KkqGk=; b=QhBkM+dWTQ kaDCs4rYOkPvhtEWTacVu/I/5dr9CYiBWIBP7e47KNXFgKs7XJ/zmBFGXNxVENOi 6iJKTbXt06izP0TSBVnpoAzp0F7J7tAterpTdsqFILeqyhqdqZe0MWbXRPGhjirt 79Qfe09f6bzI++r6kpYarY1a/Hg6TGjss=
Received: from [IPv6:::1] (c-98-248-34-40.hsd1.ca.comcast.net [98.248.34.40]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPSA id 69D4F51C073 for <tls@ietf.org>; Tue, 27 Sep 2011 08:51:06 -0700 (PDT)
From: Matt McCutchen <matt@mattmccutchen.net>
To: tls@ietf.org
Date: Tue, 27 Sep 2011 08:51:06 -0700
In-Reply-To: <CABcZeBMx=cmXoL9oM5RPxZPyB9OmEWqDfGxo0dDJmG+oAJgvvw@mail.gmail.com>
References: <CABcZeBNFtVBh7a=j4LE73Q0c-W8KGe4aKNBVZam1qOZr=aRaRQ@mail.gmail.com> <CAL9PXLybu+RTnHKSw52Crq7Pt09sAiGcsTz_BnRJ_hxFVdjN4A@mail.gmail.com> <CABcZeBMx=cmXoL9oM5RPxZPyB9OmEWqDfGxo0dDJmG+oAJgvvw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.0.3
Content-Transfer-Encoding: 7bit
Message-ID: <1317138667.2975.4.camel@localhost>
Mime-Version: 1.0
Subject: Re: [TLS] One approach to rollback protection
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: Tue, 27 Sep 2011 15:48:21 -0000
On Mon, 2011-09-26 at 18:19 -0700, Eric Rescorla wrote: > On Mon, Sep 26, 2011 at 5:56 PM, Adam Langley <agl@google.com> wrote: > > This doesn't really make the deployment of new TLS versions that much > > easier. The client would still have to try 1.2, 1.1, 1.0 etc. What > > would be helpful is if the server, seeing a TLS 1.2 SCSV, treated the > > client as if it has advertised 1.2. > > That's certainly a possibility, but now we're actually substituting > the negotiation > mechanism with one based on smuggling it in ciphersuites, which is pretty gross. You've already indicated your willingness to take hacks for better functionality. > Moreover, unless I'm missing something, this leaves the client unable to offer > extensions (since they often cause breakage as well) unless it has fallback, > at which point why not use fallback for version logic as well? > > I see your point about trying sequentially, but I don't think the > situation is that > dire. It's probably reasonable to offer TLS 1.1 or 1.2 and assume that > TLS 1.1/1.2 > stacks do TLS version negotiation properly. If that fails, fall back > aggressively > to SSLv3 or TLS 1.0 with nothing offensive like extensions. > > Or am I missing something? To clarify Adam's response: there are servers that tolerate TLS 1.0 + extensions but not TLS 1.2, and clients would like to use TLS 1.0 against such servers. They can achieve this on a first connection with TLS 1.0 version + extensions + TLS 1.2 SCSV. Without Adam's proposed behavior, clients would need two stages of fallback in order to both use TLS 1.0 with "semitolerant" servers and successfully connect to completely intolerant servers. -- Matt
- [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Nico Williams
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Adam Langley
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Eric Rescorla
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Adam Langley
- Re: [TLS] One approach to rollback protection Marsh Ray
- Re: [TLS] One approach to rollback protection Juho Vähä-Herttua
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Yoav Nir
- Re: [TLS] One approach to rollback protection Dan Winship
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Badra
- Re: [TLS] One approach to rollback protection Matt McCutchen
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Yngve N. Pettersen
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Martin Rex
- Re: [TLS] One approach to rollback protection Nikos Mavrogiannopoulos
- Re: [TLS] One approach to rollback protection Martin Rex