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