Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 22 January 2015 09:40 UTC

Return-Path: <nmav@redhat.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 2F1FF1A0687 for <tls@ietfa.amsl.com>; Thu, 22 Jan 2015 01:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EFdy5mEggiOi for <tls@ietfa.amsl.com>; Thu, 22 Jan 2015 01:40:47 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77301A049C for <tls@ietf.org>; Thu, 22 Jan 2015 01:40:47 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0M9ej8E016470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 22 Jan 2015 04:40:46 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0M9eg8g019715 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 04:40:44 -0500
Message-ID: <1421919642.2723.63.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Michael Clark <michael@metaparadigm.com>
Date: Thu, 22 Jan 2015 10:40:42 +0100
In-Reply-To: <54C0B783.2060604@metaparadigm.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <, > <20150119192701.190C71B0FF@ld9781.wdf.sap.corp> <, > <CAFewVt6LRafnJN_L=xVeiAxNcpSB+8vPYzquPfjXsduudyj+QQ@mail.gmail.com> <BAY180-W688DE2930CB7F231E60989FF480@phx.gbl> <, <04690E05-4905-4941-A60D-7BC5CDC93431@gmail.com> <> > <BAY180-W1849690A1D8C42F1063DDBFF480@phx.gbl> <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com> <54C0B783.2060604@metaparadigm.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/NTjWUW6nKw_-O0pQQ9DBWFGCzsE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard
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: Thu, 22 Jan 2015 09:40:50 -0000

On Thu, 2015-01-22 at 16:40 +0800, Michael Clark wrote:

> = TLSv1.3 implementations could remove SSLv3.0 support such that
>   the minimum TLS record layer version for TLS 1.3 is 1.0 { 3, 1 }
>   instead of { 3, 0 } which is mentioned in the Appendix as a
>   "typical value" and the maximum "message layer" version a server
>   accepts is specified as { 3, XX }. A TLSv1.2 client could send
>   { 3, 1 } { 3, 3 } and a TLSv1.3 client would send { 3, 1 } { 3, 4 }
>   in its ClientHello to support TLSv1.0 through TLSv1.2/3. This accords
>   with protocol major/minor best practices for binary changes and
>   backwards compatibility. i.e. no binary incompatible changes in minor
>   versions. Just raise non-compliance with Appendix E.1 as a bug.
> [...]
> = ClientHello Record Layer TLS version intolerance; strict lower bound
>   for the *record layer* TLS "minor" protocol version) is protective.
>   Use { 3, 1 } to deprecate SSLv3.0, which is now past its use by date
>   (from an evolutionary perspective).

These recommendations are plainly wrong, and worse, they harm
interoperability for no security benefit. Unfortunately for some reason
they somehow got implemented.

1. The version in the record layer, _DOES NOT_ indicate the minimum
version the client supports. It does indicate the format of the record
packet. Having SSL 3.0 is perfectly valid, since the packet format
remained the same.

2. Using it as an indicator of the client's minimum version is wrong as
this field is not protected by the handshake hashes, so it shouldn't
affect any of the decisions taken as part of the handshake.

3. Forbidding SSL 3.0 version from the record layer breaks perfectly
valid clients, which advertise TLS 1.2. These clients can only use a
variant of fallback dance to connect to broken servers which impose
those limits. Please _DON'T CREATE MORE REASONS FOR FALLBACK DANCES_.

regards,
Nikos