IETF Logo Mail Archive

Re: [TLS] One approach to rollback protection

Adam Langley <agl@google.com> Tue, 27 September 2011 00:54 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 5BADB1F0C86 for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 17:54:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.927
X-Spam-Level:
X-Spam-Status: No, score=-105.927 tagged_above=-999 required=5 tests=[AWL=0.050, 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 NFH8LhhQoSnI for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 17:54:07 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7854421F8CEC for <tls@ietf.org>; Mon, 26 Sep 2011 17:54:07 -0700 (PDT)
Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p8R0ukKU021733 for <tls@ietf.org>; Mon, 26 Sep 2011 17:56:46 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317085006; bh=SebTVZqCuHpEYWgxq1o5BOEsfNU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=TCwojykSS3CetJ0ZcNSTMBNy9SC6yV4ONComON/oIA4jbM26vr92rhcA5a5le+1db MDRaCZPbisiFLosboiTnw==
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=JVb8Q3vafUk/MSl50mX++EqzdUuYwpR3Lt8nj2tZcjHH2RLg24fUFGGF7QXF4GHm9 RKsYMiSWBopAQMyK0IIgA==
Received: from iadx2 (iadx2.prod.google.com [10.12.150.2]) by hpaq14.eem.corp.google.com with ESMTP id p8R0ueTH020640 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <tls@ietf.org>; Mon, 26 Sep 2011 17:56:44 -0700
Received: by iadx2 with SMTP id x2so6015547iad.20 for <tls@ietf.org>; Mon, 26 Sep 2011 17:56:44 -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=6qigi/sMn4evp19YQAZva32fKnzq8vF+XvUCRTxeI7w=; b=cQIU0zibWkErpeTDd0Bxctp2g9iaNMPOkn5kqZ9dcN3TflScWEo8OG+Iodl5GlxwlB 6jq9q1+qBTFQ3VK9ymnw==
Received: by 10.231.28.205 with SMTP id n13mr2861848ibc.47.1317085004674; Mon, 26 Sep 2011 17:56:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.28.205 with SMTP id n13mr2861826ibc.47.1317085003513; Mon, 26 Sep 2011 17:56:43 -0700 (PDT)
Received: by 10.231.19.137 with HTTP; Mon, 26 Sep 2011 17:56:43 -0700 (PDT)
In-Reply-To: <CABcZeBNFtVBh7a=j4LE73Q0c-W8KGe4aKNBVZam1qOZr=aRaRQ@mail.gmail.com>
References: <CABcZeBNFtVBh7a=j4LE73Q0c-W8KGe4aKNBVZam1qOZr=aRaRQ@mail.gmail.com>
Date: Mon, 26 Sep 2011 20:56:43 -0400
Message-ID: <CAL9PXLybu+RTnHKSw52Crq7Pt09sAiGcsTz_BnRJ_hxFVdjN4A@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 00:54:08 -0000

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.

It has been suggested by Yngve that the existing SSLv3, renego SCSV be
used to indicate TLS 1.0 support. That's something that I suspect we
will try.

> 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.


Cheers

AGL

v2.23.0 | Report a Bug | By Email