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

Adam Langley <agl@google.com> Tue, 26 November 2013 17:33 UTC

Return-Path: <agl@google.com>
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 24B551ADF71 for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 09:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level:
X-Spam-Status: No, score=-1.38 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, RP_MATCHES_RCVD=-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 YoNsLtwoQcot for <tls@ietfa.amsl.com>; Tue, 26 Nov 2013 09:33:08 -0800 (PST)
Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id ED92C1ADDDA for <tls@ietf.org>; Tue, 26 Nov 2013 09:33:07 -0800 (PST)
Received: by mail-vb0-f45.google.com with SMTP id p14so4071023vbm.18 for <tls@ietf.org>; Tue, 26 Nov 2013 09:33:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CfuWurCdrFzIbNdZSpwDXPIOFbcj2i+HExajY3W59yQ=; b=V3u5ew3Be0pWcVzs0Hg5EZUJDmHwukFAtlu0XZXbTZi5o2lsAh/gYKB6Z/H52l6mAU wkpaaYXhRp7BQG219VCZYDefOYruEDXG/TdIW81LBZEvvOqkii4s1F1fYuqyCNBXw30l iQCkqjVZPAApjsuf4u5SfryIh6u4RKH7LhtfcBG3UM8BfSAg2laCl8NlnnnLtH++iv86 YrF2nS02H7zZOB8cOOIU3gRt87bEkN1pwEr8nTW3vXzLoTePRkvu0XA8ujs3UoKz/gbe W74EI3rmIPt9c1FFKlj74hAy0l4xA3YMCOCaLrFVt5w7y7P53KyLsCP8dPCLLW9o8GiZ jFdA==
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:from:date :message-id:subject:to:cc:content-type; bh=CfuWurCdrFzIbNdZSpwDXPIOFbcj2i+HExajY3W59yQ=; b=C6it6GGn0fVPN5DFpV8xrZAEuCPofHYyNRWfUw2T9+kalyKVtfjqH1bGu3IbIbe/Zm Ya8EksgxAbsxI0zmZ7W0p9DOJY1HXHcceuhkjW0R4uucBFa5EEzVJyLgFeu5Ow92H9HQ DB2WY2qmdjwPtywJ6UxnCpNEkA857TCW2sjFz9WiRX2Vy1aPjoDhpFnJ8G+z3gWESpYl ZfdHyd56NoXMhFEbczuDdsRaawsAc/x/uEOvdU3MXO0f05POGPPqUa7Z1rnBRuHEiNW7 Rv9bmL68gTsGDxW0tBb/+SJ7NJbUBbEh2QLFsYjDOI1XycEoP7RcsGn4vHmHalfszNil zUoA==
X-Gm-Message-State: ALoCoQkRMtFlS1xRjSJvyQQrtOYC/nNHs3JSJl++IlwUSZXpVRwuybcd6Q9sRf4nUGekrOxRx+BwKUPThHFEXQ+kSMimfelsDEt0OGvIoG4rSH9vT5UuvIzHz5jxX1V2c71vbfq27U7CestWjo43KNLalmMZzvvMRFgiiBPY/1+Zby07fbz5DCEirtcRddWcuRhIMj92RpUf
X-Received: by 10.52.245.9 with SMTP id xk9mr27061903vdc.8.1385487187652; Tue, 26 Nov 2013 09:33:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Tue, 26 Nov 2013 09:32:47 -0800 (PST)
In-Reply-To: <op.w64s0vig3dfyax@killashandra.invalid.invalid>
References: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com> <op.w64s0vig3dfyax@killashandra.invalid.invalid>
From: Adam Langley <agl@google.com>
Date: Tue, 26 Nov 2013 12:32:47 -0500
Message-ID: <CAL9PXLyZvD+p=abPNZ05vX2SBWXNYyD1XaKsr83aKYov08zMsQ@mail.gmail.com>
To: "Yngve N. Pettersen" <yngve@spec-work.net>
Content-Type: text/plain; charset=UTF-8
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: Tue, 26 Nov 2013 17:33:09 -0000

On Mon, Nov 25, 2013 at 7:59 PM, Yngve N. Pettersen <yngve@spec-work.net> wrote:
>  - Are these implementations functioning as proxies or just inspecting the
> encrypted protocol data, without decrypting?

I think that the problems so far have been with full MITM proxies.

>  - Does *any* of these implementations support the Renego patch? If they
> don't, then my suggestion for using the Renego extension support as a proxy
> for version tolerance might still work.

Unfortunately I've no idea. There seem to be more variants of some of
these products than pips in a pomegranate.

>  - Do you know that none of them will not break due to an SCSV? If they are
> breaking due to expectations of what is supposed to be in the handshake,
> some of them they could very well break due to unexpected ciphersuites, as
> well. (while the Renego SCSV seem to have worked well, I don't think it can
> be relied on as a reliable indication as it is only used for SSL v3-only
> hellos, because there are servers that does not tolerate the Renego
> extension in combination with the Renego SCSV.

It is possible that there could be compat issues with an SCSV but, as
far as I know, it's the least likely to have problems.

> A pessimistic guess is that, as per Murhpy's Law, there will be both broken
> Renego patched implementations, and implementations that react to the
> proposed SCSV. As far as the SCSVs are concerned, how do you propose to
> handle those cases?

Tiny amounts of breakage are acceptable if there are some edge cases.
I don't know yet whether the breakage will be tiny and, as ever, it'll
be a bunch of work to find out. But it seems to be the best way
forward.

You report that 0.3% of sites are expected to fail if we use renego as
an anti-fallback signal. That is not a heart warming number and I'd
like to try to break less, if at all possible.


Cheers

AGL