IETF Logo Mail Archive

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

Ralf Skyper Kaiser <skyper@thc.org> Sat, 07 December 2013 15:14 UTC

Return-Path: <skyper@thc.org>
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 8D9951AE371 for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 07:14:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-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 l4kGFZjvKlFz for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 07:14:20 -0800 (PST)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 11FFC1ADF7A for <tls@ietf.org>; Sat, 7 Dec 2013 07:14:19 -0800 (PST)
Received: by mail-ie0-f175.google.com with SMTP id x13so3395154ief.20 for <tls@ietf.org>; Sat, 07 Dec 2013 07:14:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KdRBx4n4ETH74PJW/477s/kBpPVvBZB9PvjlejVfzfs=; b=PVPL9UEJ/gDxIh6zDE2D+0QY7xN3WyIAaTrHtb4zDd/6szQZGYmqDflR4wtV+t+gUn OuagFFi6F4x3TGUcJzjnC8ztEO/lMcaeM25DFON/09hhPhMjZpKAIRhDnHcThGL3G4M3 +zgp3061zDsGhIu7Rc81XFJLpNIlix2K0U4xU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KdRBx4n4ETH74PJW/477s/kBpPVvBZB9PvjlejVfzfs=; b=EMWQMtuyyI7JhpQFD+YZhr6w9dnhXCg//TMT2LlzXe5A5Xyg/f2qzhJ2DCXN6x5jZd 4LUtxRa9m/5zb0wOGlPm6enn37rkOYspbXuKQFHt5oU5x3ojUpxetf2eOGPZ1erNQUd0 fADgIUhq+5RDYrqokTCmnynR0jnc8ufDMCa8iFmxfXvgRZ7lWbwcelLRoCEZ9xubWYqy 17xLh2cdPDwbbD2Tyk70/TG7p6sbWXTCe+8/A7+UZK7UlRt+8LXcgOgxgGWhGh+Im4/8 PqAcYnqFB0h1JvwekJWG5dezP+TB9uUSdti1rFduRikeUh4LmkOdjI/MER3OzJxoYa86 rDgA==
X-Gm-Message-State: ALoCoQmxTOwZwbEyb2CaFucEIMUnovcdJ8dsCENs8roORlyAdT9M8BNGGvqB88ja2tXiF7lIKnvH
MIME-Version: 1.0
X-Received: by 10.50.136.201 with SMTP id qc9mr7069059igb.11.1386429255926; Sat, 07 Dec 2013 07:14:15 -0800 (PST)
Received: by 10.64.9.41 with HTTP; Sat, 7 Dec 2013 07:14:15 -0800 (PST)
X-Originating-IP: [203.118.14.76]
In-Reply-To: <52A33888.80307@gmail.com>
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>
Date: Sat, 07 Dec 2013 15:14:15 +0000
Message-ID: <CA+BZK2oH4S1rJcOosWC+hQL_8AeJ8mXwQdA5_TjGn1ncydTMsg@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="089e01229ed84e5cbb04ecf337bc"
Cc: "tls@ietf.org" <tls@ietf.org>
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:14:21 -0000

Hi


On Sat, Dec 7, 2013 at 3:02 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Hi Ralf,
>
> 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.
>

This feature could be optional and a server admin could decide to use this
feature (e.g. to advertise TLS Version pinning and CIpher-suite pinning).

A server-cluster can opt-out to use the feature.

I'm not yet giving up hope to also find a solution that makes this feature
available to server-clusters. It could be a technical solution or a
management/process solution.


>
> Re: cipher-suites, if I'm using ECDHE it doesn't mean that I want future
> DHE connections to fail. It is absolutely legitimate to change t
> setting he server's software for some reason, and to thereby also change
> the list of supported ciphersuites. I don't think we can ever reach
> consensus on weak vs. strong cipher-suites on this mailing list, and such
> consensus would be needed to standardize such a solution.
>

Sadly can we not make up our mind which ciphers are strong or weak and we
always shift this responsibility to the server-admin. We have done so in
the past and solving this now would be out-of-scope for the proposed
TLS-version/Cipher-suite pinning discussion.


>
> Thanks,
>         Yaron
>
>
regards,

ralf

v2.23.0 | Report a Bug | By Email