Re: [TLS] An SCSV to stop TLS fallback.

Manuel Pégourié-Gonnard <mpg@elzevir.fr> Sat, 07 December 2013 15:33 UTC

Return-Path: <mpg@elzevir.fr>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB05A1AE37D for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 07:33:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.251
X-Spam-Level:
X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z48ALpyEYre2 for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 07:33:45 -0800 (PST)
Received: from mordell.elzevir.fr (mordell.elzevir.fr [92.243.3.74]) by ietfa.amsl.com (Postfix) with ESMTP id 560EB1AE37A for <tls@ietf.org>; Sat, 7 Dec 2013 07:33:45 -0800 (PST)
Received: from thue.elzevir.fr (thue.elzevir.fr [88.165.216.11]) by mordell.elzevir.fr (Postfix) with ESMTPS id 9953516182 for <tls@ietf.org>; Sat, 7 Dec 2013 16:33:38 +0100 (CET)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 454942982E for <tls@ietf.org>; Sat, 7 Dec 2013 16:33:37 +0100 (CET)
Message-ID: <52A33FD0.7040708@elzevir.fr>
Date: Sat, 07 Dec 2013 16:33:36 +0100
From: Manuel Pégourié-Gonnard <mpg@elzevir.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.0
MIME-Version: 1.0
To: tls@ietf.org
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <CAFewVt42cSELgfiDa2M7OWwBcpEgcqNzHL4oAEjJ_3GJ8TEPrg@mail.gmail.com> <CA+BZK2rbjcx+sT9BU5sjKsuH81N+02xdLD3CmreaGzjRn-ibdA@mail.gmail.com> <52A2FB32.30004@gmail.com> <CA+BZK2qm75eqW9ZmvEozM_9R2xYJMmov8dyn4qz=ppJ84grrZw@mail.gmail.com> <52A33888.80307@gmail.com>
In-Reply-To: <52A33888.80307@gmail.com>
X-Enigmail-Version: 1.6
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 07 Dec 2013 15:33:48 -0000

Hi,

On 07/12/2013 16:02, Yaron Sheffer wrote:
> No, AFAIU the problem does not exist for cert pinning, because there is 
> protocol involved. Specifically, the server sends out HTTP headers to 
> indicate the pinning and its lifetime. So (for example) you can start by 
> changing the certs on all cluster members and only afterwards enable 
> pinning on all of them.
> 
Maybe I'm missing something obvious, but it seems to me the problem with version
pinning could be solved by explicitly stating the minimum TLS version in the
HTTP headers, then. That way, cluster admins could upgrade some servers to say
1.3 while keeping the pinning on 1.2, and then update the pinning to 1.3 only
when all the servers in the cluster are upgraded to 1.3.

Manuel.