[TLS] SCSVs and SSLv3 fallback

Trevor Perrin <trevp@trevp.net> Thu, 04 April 2013 21:02 UTC

Return-Path: <trevp@trevp.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822B521F93A9 for <tls@ietfa.amsl.com>; Thu, 4 Apr 2013 14:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.356
X-Spam-Level: *
X-Spam-Status: No, score=1.356 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCJQ4jzp9Ooa for <tls@ietfa.amsl.com>; Thu, 4 Apr 2013 14:02:29 -0700 (PDT)
Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D043621F8FD3 for <tls@ietf.org>; Thu, 4 Apr 2013 14:02:28 -0700 (PDT)
Received: by mail-we0-f174.google.com with SMTP id u12so2398654wey.5 for <tls@ietf.org>; Thu, 04 Apr 2013 14:02:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=WCNffB/C9dp9HCn/MuaPFTWkgE6JQ564KWCnM7KzWGg=; b=KjV9WSSy+PZSdufJgtXPQBtb0SV7rDN0mcfqZs93wL1BTA3578wLlYN/ejYgJ8mwTw hyBCwtlg5eGHLupqMp/Hk8xJ8NSV7KBqxt8top2d3aalYprptOZ/BAV7RNN88h/QZWFX Bw+9GxH2i4CsuVHq/eWiuYs8OGxA+BAZejwn97B21AXMrVmIRa8rsh7BgQ6Ah5/pvPlW JKXu5oTHtNYbvPsA+cJ6Gg+Q+3HSseNKDShzMN2oii8xm+TarXypEdHNcKUSmfrMax/w dJ3emb74C4MYL9dV9yKZAzsSvqEbfNOT+odmi38ypTk+ojWk3xO3YEHyFtIwXkZgm1nY enRQ==
MIME-Version: 1.0
X-Received: by 10.194.123.168 with SMTP id mb8mr11643296wjb.24.1365109347932; Thu, 04 Apr 2013 14:02:27 -0700 (PDT)
Received: by 10.216.111.1 with HTTP; Thu, 4 Apr 2013 14:02:27 -0700 (PDT)
X-Originating-IP: [64.134.227.227]
Date: Thu, 04 Apr 2013 14:02:27 -0700
Message-ID: <CAGZ8ZG0i4-ZDPu=O1+Qy1DJ8oV80_eMz5J9NZrn2UC1-zYu4Sw@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: tls@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQlxOb6xNfNABqHsLvwm6vIyQZObf4EOxL1+fmDrYsaqLrVVTNSzx81NxdfqKumfho89bw1A
Subject: [TLS] SCSVs and SSLv3 fallback
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 04 Apr 2013 21:02:29 -0000

Hi,

I've heard (anecdotally) that HTTPS between browsers and webservers
who are both TLS-capable sometimes results in SSLv3 connections.
Presumably this is due to firewall interference with the TLS
handshake, causing browsers to retry an SSLv3 handshake.

I believe TLS Extensions are generally not sent in the SSLv3
ClientHello (?).  This isn't a major problem for TLS Extensions as
optimizations (e.g. session tickets or OCSP stapling).

However, there are proposals that *require* a TLS Extension response,
for security:
 - TACK's "TackExtension" [1]
 - Certificate Transparency's "SignedCertificateTimestampList" [2]
 - OCSP stapling in the presence of an X.509 "must-staple" extension [3]

How should these work in the case of a network-triggered SSLv3 fallback?


One proposal would note that some browsers do, I think, send the
RFC5746 TLS_EMPTY_RENEGOTIATION_INFO_SCSV ciphersuite in an SSLv3
ClientHello, and receive a "renegotiation_info" ServerHello extension
in return.

So there's evidence that this idiom of a "special ciphersuite value"
in an SSLv3 ClientHello, and a TLS Extension in ServerHello, is
"compatible-enough" with the horrible middleboxes triggering these
fallbacks.

This idiom wouldn't work with a proposal that sends data in
ClientHello, but both the TACK and CT proposals use empty
extension_data, and OCSP stapling seems like it would work as a binary
signal, as well (?).

So, is it reasonable for things like TACK to consider an SCSV value
that could be used instead of (or in combination with) a ClientHello
Extension, to request the corresponding ServerHello extension?


Trevor