[TLS] Fallback SCSV summary

Joseph Salowey <joe@salowey.net> Sat, 08 November 2014 01:52 UTC

Return-Path: <joe@salowey.net>
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 CB3B61A00C5 for <tls@ietfa.amsl.com>; Fri, 7 Nov 2014 17:52:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 K4zunZet8Oy2 for <tls@ietfa.amsl.com>; Fri, 7 Nov 2014 17:52:38 -0800 (PST)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755BA1A00A6 for <tls@ietf.org>; Fri, 7 Nov 2014 17:52:38 -0800 (PST)
Received: by mail-qc0-f169.google.com with SMTP id i17so3547379qcy.28 for <tls@ietf.org>; Fri, 07 Nov 2014 17:52:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=hO+gExtmUE2/CKaK0GweYJhoITKvd/HoepWbSLAQcfU=; b=TVmMu1mVH9HchGT8aMWBVfc5OW0acfXunryPjRUDHqRoDGeEqJuYqa0VY/Wm7Qtlsm NmaMvtUPzSDr+JhI3T1lFgw1H497JzqUBU6nj2dPgAaRut70cWEZh2ykpsTMkQi0pUGM L1YTRhsUm4vFPRcGgrDOhuMg0FcbDNJE2xa8176PbjCgJ+fn4YgJ5082MZ+Nasd2vLR4 90QMvCNTWCuZiSg3S/c2bMG6Dw9rPC1vz7Q4sIpU5MCSNkPIyTTyziibcZzrmU5b7Se4 xOp1rpZwYLNJbspu8R4PcgyY6T/4qkwG3Y5UsXA0cIj9bVWo8sEgA/nn6nBNvYTSTQih WN+w==
X-Gm-Message-State: ALoCoQm71vmdhlmN75sFBDc+X46V3BVafWFj1Cq49zq9aJfPwOtAEs3nxTK8LiSQeqxFbHEhkEUf
MIME-Version: 1.0
X-Received: by 10.140.104.65 with SMTP id z59mr21474142qge.75.1415411557782; Fri, 07 Nov 2014 17:52:37 -0800 (PST)
Received: by 10.96.215.170 with HTTP; Fri, 7 Nov 2014 17:52:37 -0800 (PST)
X-Originating-IP: [67.168.161.122]
Date: Fri, 7 Nov 2014 17:52:37 -0800
Message-ID: <CAOgPGoDr-UyBHpY3TMfPA8b_b3Brtpj3iYRt7a86ZNR8LunfuA@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary=001a11354e4c1cf1b105074f2f39
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4Oe84qb-76KVqa621-kiA-nU1wc
Subject: [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: Sat, 08 Nov 2014 01:52:41 -0000

Below is my summary of the fallback SCSV issue with some suggestions.
Since I'm weighing in on the text as an individual I'm asking Sean to
finish up the consensus process on this draft.

I've gone through he SCSV comments and I think the following issues need to
be resolved:

1.  The draft does not really state that the fallback SCSV is really a hack
and that standard version negotiation should really be encouraged.  Here is
some text that could go into the introduction:

"The fallback SCSV defined in this document is not suitable substitute for
proper TLS version negotiation. TLS implementations need to properly handle
TLS version negotiation and extensibility mechanisms to avoid the security
issues and connection delays associated with fallback mechanisms."

2.  The current draft will cause TLS connections to fail if a downgrade
happens for any reason.  This will result in additional retries even if the
server is willing to continue at the lower version.  An alternative using
extensions has been described to allow the server to communicate the status
of the downgrade back to the client and let the client decide whether to
continue.

>From reading the list I don't think we have consensus to abandon the the
SCSV approach.  The SCSV mechanism is simpler and it does not rely on
extensions which have been a reason for server failures in the past.
However, I think the draft can better describe the conditions of when the
client SHOULD include the SCSV and what the client SHOULD do if it receives
an inappropriate_fallback alert.  Here is some proposed text for section 4
and security considerations:

Section 4

"If the client receives an inappropriate_fallback alert then the server
intends to support a higher version and the client should retry with the
highest version it supports.   Implementors should review the security
considerations section before deciding to make a connection with a lower
version without including the TLS_FALLBACK_SCSV.

Security Considerations

"Section 4 does not require client implementations to send
TLS_FALLBACK_SCSV in any particular case, it merely recommends it; behavior
can be adapted according to the client's security needs.  However, it is
important to remember that omitting the TLS_FALLBACK_SCSV leaves the TLS
connection vulnerable to version rollback so it is not recommended to omit
the SCSV unless the negotiated version provides an acceptable level of
protection.

For example, during the initial deployment of a new protocol version
(when some interoperability problems may have to be expected),
   smoothly falling back to the previous protocol version in case of
   problems may be preferrable to potentially not being able to connect
   at all: so TLS_FALLBACK_SCSV could be omitted for this particular
   protocol downgrade step.

   However, it is strongly recommended to send TLS_FALLBACK_SCSV when
   downgrading to SSL 3.0 as the CBC cipher suites in SSL 3.0 have
   weaknesses that cannot be addressed by implementation workarounds
   like the remaining weaknesses in later (TLS) protocol versions."

3.  The introduction should indicate that the Fallback SCSV also applies to
DTLS.

4.  The IANA considerations section needs to allocate the number for the
alert:

"IANA is asked to assign the following value in the TLS Alert Registry for
use with TLS and DTLS.

86  inappropriate_fallback Y [RFC TBD]"