IETF Logo Mail Archive

Re: [TLS] One approach to rollback protection

Adam Langley <agl@google.com> Tue, 27 September 2011 01:35 UTC

Return-Path: <agl@google.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 953B921F8EB1 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level:
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 OnJUwfi69Lvc for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:35:43 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id C1DE421F8EB0 for <tls@ietf.org>; Mon, 26 Sep 2011 18:35:42 -0700 (PDT)
Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p8R1cMcZ008309 for <tls@ietf.org>; Mon, 26 Sep 2011 18:38:22 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317087502; bh=uuKIuxluaz58nQO9Tr5IEvfKGWY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Z3bKNEn+x/WVJnYgebqy6F7Xjwp2+CPjRuNRpTLXQa2V5FTW9Z8oZo1kG1fpFks3j tIurFvvH4ZqYtEuGrDf6A==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=pv55IhvfaXA8nKS9AniY8vM6c/DMEKGrVE4jfnFey5heOA/L5LwVRt5r+15WkVkRT BfPun79yFjgVpl7wVfW+Q==
Received: from iagf6 (iagf6.prod.google.com [10.12.208.6]) by hpaq1.eem.corp.google.com with ESMTP id p8R1bsPb016175 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <tls@ietf.org>; Mon, 26 Sep 2011 18:38:20 -0700
Received: by iagf6 with SMTP id f6so7816177iag.18 for <tls@ietf.org>; Mon, 26 Sep 2011 18:38:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2cV1nLYfYIaEW7FCmKFrSlebkiTwSndVN3dupIXuSO4=; b=rnj/XztECvOs79DS+oHwNMSVfWzhPQoTUVGXQfh2zFMV3T85VeV57QCCXPI1YrWrjP 5rS0vUfcsEo0zouvsjng==
Received: by 10.231.28.205 with SMTP id n13mr2911023ibc.47.1317087500485; Mon, 26 Sep 2011 18:38:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.28.205 with SMTP id n13mr2911018ibc.47.1317087500316; Mon, 26 Sep 2011 18:38:20 -0700 (PDT)
Received: by 10.231.19.137 with HTTP; Mon, 26 Sep 2011 18:38:20 -0700 (PDT)
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>
Date: Mon, 26 Sep 2011 21:38:20 -0400
Message-ID: <CAL9PXLzxtQt+pgiAipCky7d3qLF7x-z6h_FG+JZe+EjDhof14w@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset="UTF-8"
X-System-Of-Record: true
Cc: tls@ietf.org
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 01:35:43 -0000

On Mon, Sep 26, 2011 at 9:19 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 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.
> 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?

What we want is the version negotiation that we're supposed to have.
But it broke :(

Let's say that NSS does TLS 1.2. We are probably only going to have
one level to fallback: to SSLv3, no compression. So servers which
currently do 1.0 or 1.1, but which are intolerant to a 1.2 client are
going to get SSLv3 instead. The last numbers that I saw from Yngve
were that these are ~2% of the Internet.

Not the end of the world, but we can avoid it if we advertise 1.0 in
the version and 1.2 with SCSV. Depends if the WG can stomach it :)


Cheers

AGL

v2.23.0 | Report a Bug | By Email