IETF Logo Mail Archive

Re: [TLS] SCSV versioning

Geoffrey Keating <geoffk@geoffk.org> Fri, 27 February 2015 00:26 UTC

Return-Path: <geoffk@geoffk.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 F1C1D1A0125 for <tls@ietfa.amsl.com>; Thu, 26 Feb 2015 16:26:33 -0800 (PST)
X-Quarantine-ID: <z7IrvE4390Wc>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char F0 hex): Cc: \360\237\224\223Dan Wing <dw[...]
X-Spam-Flag: NO
X-Spam-Score: 2.295
X-Spam-Level: **
X-Spam-Status: No, score=2.295 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-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 z7IrvE4390Wc for <tls@ietfa.amsl.com>; Thu, 26 Feb 2015 16:26:32 -0800 (PST)
Received: from dragaera.releasedominatrix.com (unknown [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9512D1A00D1 for <tls@ietf.org>; Thu, 26 Feb 2015 16:26:32 -0800 (PST)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id DC11233D050; Fri, 27 Feb 2015 00:26:01 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Bodo Moeller <bmoeller@acm.org>
References: <73A15C72-FC5B-4241-9AA2-9ACCC65B562D@cisco.com> <CADMpkcLz1cRKz=SPyVXXu_8JBch-dhmCn43dkdxno=d81nos_A@mail.gmail.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Thu, 26 Feb 2015 16:26:01 -0800
In-Reply-To: <CADMpkcLz1cRKz=SPyVXXu_8JBch-dhmCn43dkdxno=d81nos_A@mail.gmail.com>
Message-ID: <m2d24w19pi.fsf@localhost.localdomain>
Lines: 28
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/MQ2NG7T54LN134gP4NOxVv_uu0A>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] SCSV versioning
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: Fri, 27 Feb 2015 00:26:34 -0000

Bodo Moeller <bmoeller@acm.org> writes:

> Dan Wing <dwing@cisco.com>:
> 
> I recently became aware that Microsoft IE won't implement SCSV.  Near as I
> > can tell, this is the main concern [...]:
> >
> 
> > One of the developers pointed out that the TLS_FALLBACK_SCSV feature has
> > a significant downside-- because it doesn't convey any specific version
> > information, it becomes a general "never fall back" signal. The problem is
> > that such signals are too broad; fallbacks were only ever introduced
> > because servers often use TLS stacks with implementation bugs. Any "don't
> > fallback" signal sent by such a server will be very bad for compat.
> >
> 
> I haven't seen this particular complaint before, and also can't quite make
> sense of it.
...

I believe it's the same thing I mentioned last year, in

http://www.ietf.org/mail-archive/web/tls/current/msg11208.html

The implicit assumption made by the SCSV is that all new servers
(supporting the SCSV) will not have bugs requiring a fallback.  As
soon as that first server appears which supports SCSV but requires
fallback, this SCSV can't be used.

v2.23.0 | Report a Bug | By Email