Re: [TLS] One approach to rollback protection

Eric Rescorla <ekr@rtfm.com> Tue, 27 September 2011 01:17 UTC

Return-Path: <ekr@rtfm.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 802F621F87FC for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.896
X-Spam-Level:
X-Spam-Status: No, score=-102.896 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 u2ugXHnb3NwB for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 18:17:04 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FDF121F86EE for <tls@ietf.org>; Mon, 26 Sep 2011 18:17:04 -0700 (PDT)
Received: by wyh21 with SMTP id 21so4888709wyh.31 for <tls@ietf.org>; Mon, 26 Sep 2011 18:19:48 -0700 (PDT)
Received: by 10.227.178.141 with SMTP id bm13mr3367184wbb.33.1317086387247; Mon, 26 Sep 2011 18:19:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.151.205 with HTTP; Mon, 26 Sep 2011 18:19:07 -0700 (PDT)
In-Reply-To: <CAL9PXLybu+RTnHKSw52Crq7Pt09sAiGcsTz_BnRJ_hxFVdjN4A@mail.gmail.com>
References: <CABcZeBNFtVBh7a=j4LE73Q0c-W8KGe4aKNBVZam1qOZr=aRaRQ@mail.gmail.com> <CAL9PXLybu+RTnHKSw52Crq7Pt09sAiGcsTz_BnRJ_hxFVdjN4A@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 26 Sep 2011 18:19:07 -0700
Message-ID: <CABcZeBMx=cmXoL9oM5RPxZPyB9OmEWqDfGxo0dDJmG+oAJgvvw@mail.gmail.com>
To: Adam Langley <agl@google.com>
Content-Type: text/plain; charset="ISO-8859-1"
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:17:05 -0000

On Mon, Sep 26, 2011 at 5:56 PM, Adam Langley <agl@google.com> wrote:
> On Mon, Sep 26, 2011 at 7:44 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> I've taken an initial crack at a draft for this:
>> http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt
>
> In Table 1 you list TLS 1.1 twice.

My bad.


>> If the SCSV value is present and is not equal to ClientHello.client_version, then the server MUST terminate the handshake with a fatal "handshake_failure" alert.
>
> 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.
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?
-Ekr