Re: [TLS] Fallback SCSV summary

Bodo Moeller <bmoeller@acm.org> Mon, 10 November 2014 21:02 UTC

Return-Path: <bmoeller@acm.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 692BA1ACEA6 for <tls@ietfa.amsl.com>; Mon, 10 Nov 2014 13:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.262
X-Spam-Level:
X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] 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 htmhqde6VdDe for <tls@ietfa.amsl.com>; Mon, 10 Nov 2014 13:02:48 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92941A1BEE for <tls@ietf.org>; Mon, 10 Nov 2014 13:02:47 -0800 (PST)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0LsyHC-1XzfA72o4w-012XuK; Mon, 10 Nov 2014 22:02:46 +0100
Received: by mail-ob0-f172.google.com with SMTP id wp4so6448742obc.3 for <tls@ietf.org>; Mon, 10 Nov 2014 13:02:43 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.199.1 with SMTP id jg1mr3305324obc.73.1415653363361; Mon, 10 Nov 2014 13:02:43 -0800 (PST)
Received: by 10.60.32.42 with HTTP; Mon, 10 Nov 2014 13:02:43 -0800 (PST)
In-Reply-To: <CABkgnnUq0BvoH6sGR9WEaGwq717KQ3u=Ws4vT7yKhHz7WmnrJQ@mail.gmail.com>
References: <CAOgPGoDr-UyBHpY3TMfPA8b_b3Brtpj3iYRt7a86ZNR8LunfuA@mail.gmail.com> <op.xozlpdnx3dfyax@killashandra.invalid.invalid> <CADMpkcKBB+CKUx1HK7kyEbsOxzcabWtmVe_JuYHoBamRhbg8WA@mail.gmail.com> <CABkgnnUq0BvoH6sGR9WEaGwq717KQ3u=Ws4vT7yKhHz7WmnrJQ@mail.gmail.com>
Date: Mon, 10 Nov 2014 22:02:43 +0100
Message-ID: <CADMpkcJdQ78=1g93-YPg=1e-LjdAbVWOJRVDJSwcC79AHixveQ@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="e89a8ff2512ad940070507877bcf"
X-Provags-ID: V02:K0:Q5C+p4ALmJrhgiwc1ytiEjeG8aE7mMhnoqCLM2PlAKu OOiBMMZwfqJI/hAIpMVNy4BlA37r6/B2vMSsMET2Y9+x2VrnP9 ZUuBM7PTRMoldM5erbsu1T/w8KRhzuC99wjSR81FDQeTwDgEUJ jcM+EPyUKd1+77XAMfmQw7BSShnzr+SQryZwNRdkSRM/zldTBy Zf5Svt9jZS69ToTpr/o3se/xuV8TF3KoEhD3F4/WyVTgT//nN9 EF0cj2FJfHSl1Vbx3rdzUehWg87wwNHTst9BFj9HWkr9zzrbhH ixj5jZaqVtzioRyeKjK9YKBR9HUZgg/q0/k1k3Hhuqr8Vng5BZ luAUqy7sXfELRIgLAZFzyg+L2K0N5o2FF65hCmSaiHRCRBzvvI GeVJ8djuWHQK460kQoHf0/gfy6Q1TrhODRY9AmacTplbWQxMQm OtoSb
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/02x9wZkOCqDJKsIhwf_qIpo6YcQ
Subject: Re: [TLS] Fallback SCSV summary
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: Mon, 10 Nov 2014 21:02:50 -0000

> > So ... unless I'm misunderstanding what you describe here, these servers
> > plainly don't tolerate new (= unknown, to them) cipher suites in the
> list?!
> > Interesting.
>


> There's a suggestion that some implementations only look at the second
> byte.


Oh, that. Good point. Obviously, these servers will have other problems too
(just due to collisions between deployed cipher suites in the Standards
Action range and the Specification Required space), and failing the entire
handshake if one of the cipher suites supposedly suggested by the client
seems suspect is broken too, but right, that kind of issue may explain why
more servers reject our concrete SCSV value than other potential SCSV
values.  (It's not clear that you'd even *want* to interoperate with such
servers ... keeping them around would make it harder to add new actual
cipher suites.)


>   A legacy of SSLv2, I believe.
>

Actually, SSL 2 cipher suites ("cipher kinds") had three bytes.  It's
probably simply a legacy of all SSL 3.0 cipher suites having the common
first byte 0x00.

Bodo