Re: [secdir] SecDir review of draft-ietf-tls-downgrade-scsv-03
Bodo Moeller <bmoeller@acm.org> Sun, 18 January 2015 20:56 UTC
Return-Path: <SRS0=F53o=CF=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281C81ACE17; Sun, 18 Jan 2015 12:56:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.938
X-Spam-Level:
X-Spam-Status: No, score=-0.938 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_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ee0Sl0MpobB8; Sun, 18 Jan 2015 12:56:17 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (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 DA78D1ACD13; Sun, 18 Jan 2015 12:56:16 -0800 (PST)
Received: from mail-la0-f44.google.com ([209.85.215.44]) by mrelayeu.kundenserver.de (mreue005) with ESMTPSA (Nemesis) id 0LtBoV-1XlPLJ2y8R-012r8N; Sun, 18 Jan 2015 21:56:14 +0100
Received: by mail-la0-f44.google.com with SMTP id hz20so3512392lab.3; Sun, 18 Jan 2015 12:56:09 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.142.201 with SMTP id ry9mr26535361lbb.4.1421614569148; Sun, 18 Jan 2015 12:56:09 -0800 (PST)
Received: by 10.25.25.145 with HTTP; Sun, 18 Jan 2015 12:56:09 -0800 (PST)
In-Reply-To: <B85F10BC-18FD-4220-B5E2-719068E814CC@gmail.com>
References: <B85F10BC-18FD-4220-B5E2-719068E814CC@gmail.com>
Date: Sun, 18 Jan 2015 21:56:09 +0100
Message-ID: <CADMpkcKdEEL5JWCj8y=Sit6Pw4RJNsETGmeF6x8s-211DCYo7w@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="089e011836aa66dbb6050cf36ff8"
X-Provags-ID: V03:K0:MykFgAfhUYaOHbJReBn772e9Ilz82b+4nPvv0VsOEGghBuXQVXP xJ+W9Gv+VNz7VyD1HvPtx/GVzIrjDGkMjHj8YICUFoOybj4mzyoajKAiMcqMM4LFa8OmisP ivm5s2EINXjRLAat0by9cR8pl0St4pNDgyOAD9SHVJv67Gf++GHChN8fYo5jExGPjzqR8Bh MMTSuMswNLhG9zmEjmVuA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/5gIEjdnqV1A8jW4IHh2dOO2_aeM>
X-Mailman-Approved-At: Sun, 18 Jan 2015 12:59:16 -0800
Cc: "draft-ietf-tls-downgrade-scsv.all@tools.ietf.org" <draft-ietf-tls-downgrade-scsv.all@tools.ietf.org>, The IESG <iesg@ietf.org>, Adam Langley <agl@google.com>, secdir <secdir@ietf.org>
Subject: Re: [secdir] SecDir review of draft-ietf-tls-downgrade-scsv-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Jan 2015 20:56:19 -0000
Thanks for your comments, Yoav! > The Security Considerations section has some strange text about omitting > the SCSV when "the protocol version given by ClientHello.client_version > still provides an acceptable level of protection". This implies that it is > appropriate to use a protocol version that does not provide and acceptable > level of protection as long as the client sends the SCSV. This is not the > case, and this is the reason that several browsers are disabling the > downgrade to SSLv3. I realize it is difficult to write text that turns the > secure/insecure dichotomy into a trichotomy (secure/so-so secure/insecure), > but if we're going to make including the SCSV optional we need such text. > Could you make a concrete (if rough) suggestion for what you'd like to see in the document? Note that the text that you cite above was essentially contributed by one of the WG chairs :-) [*] Personally, I don't see a need for additional text because I think that the document already makes it quite clear that the reason why a client might tolerate an otherwise unacceptable level of security when sending the SCSV is as a last resort for connections to legacy servers. Regarding your statement that "this is the reason that several browsers are disabling the downgrade to SSLv3", I don't agree. If TLS_FALLBACK_SCSV was already widely deployed in servers, browser vendors would have had a much less pressuring need to disable the downgrade to SSL 3.0 entirely -- with the SCSV, SSL 3.0 would have been exclusively about hopeless legacy servers anyway, A scenario that bothers me is a server that returns an > inappropriate_fallback whenever it receives a TLS_FALLBACK_SCSV with > version TLS 1.1, but breaks at TLS 1.2. Such an (admittedly broken) server > could potentially send the client into an endless loop of regular and > fallback handshake attempts. An attacker could simulate this by RST-ing all > TCP connections with TLS 1.2 in ClientHello. I think the draft should warn > against doing the regular-fallback-regular cycle more than once. IOW: after > receiving the alert, clients MUST NOT perform the downgrade dance on the > following connection. The problem is, the alert is not authenticated. (We'd have to complete the handshake to authenticate it.) So a "MUST NOT" can't be right: if a browser users tries to access a web page a second time after the above failure, it's appropriate for the client to perform the entire downgrade dance again if needed. Implementors shouldn't go into infinite reconnect loops, but I don't think there's anything special here about TLS_FALLBACK_SCSV. > Nits and minor issues: > > Since the client speaks first, it would make sense to have section 4 > (Client Behavior) before section 3 (Server Behavior). Section 3 describes > how the server responds to this SCSV when the document had only hinted > about when the client should send it. > My rationale for describing server behavior before client behavior was that I think this makes it easier to read the document, given that server behavior follows simple, concrete, and strict rules. After you've read those in the Server Behavior section, I believe it will be much easier to make sense of the (more complex) section on Client Behavior. If you don't know what server behavior TLS_FALLBACK_SCSV triggers, my fear is that the Client Behavior section will seem very esoteric, abstract, and nebulous. > The IANA Considerations are very confusing, saying on the one hand that no > values have been allocated, and on the other hand that IANA has assigned > 0x56,0x00. Unless the authors are requesting that IANA assign the numbers > that they have used in early implementations, it's better to just write > "IANA is requested to assign..." and replace the numbers in the rest of the > documents with TBDs (if you leave actual numbers and IANA assigns different > identifiers, it's likely to be overlooked by the RFC editor). > Right, the point is specifically to use the numbers that have been used in existing implementations. Isn't the "TO BE REMOVED" note rather clear about that? In any case, the contradictive part obviously isn't meant to go into the final document -- the current form is meant to show the intended final document text while also making it clear that IANA hasn't yet assigned anything. > A few missing articles: > "The fallback SCSV defined in this document is not *a* suitable substitute" > "if *the* TLS implementations also include support for (the) predecessor > protocol SSL 3.0" I don't think either of these is technically necessary, but I'l entirely leave the decision about these articles to my co-author :-) (In the first case, by the way, it's again language contributed by said WG chair. [*]) Bodo [*] No intent to shift any blame: I think the current text is fine, or I wouldn't have used it. However, this lets you know who's in a special position to convince me to change that wording.
- [secdir] SecDir review of draft-ietf-tls-downgrad… Yoav Nir
- Re: [secdir] SecDir review of draft-ietf-tls-down… Bodo Moeller
- Re: [secdir] SecDir review of draft-ietf-tls-down… Yoav Nir
- Re: [secdir] SecDir review of draft-ietf-tls-down… Joseph Salowey
- Re: [secdir] SecDir review of draft-ietf-tls-down… Bodo Moeller