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

Eric Rescorla <ekr@rtfm.com> Fri, 23 January 2015 00:24 UTC

Return-Path: <ekr@rtfm.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 4A85B1A19E4 for <tls@ietfa.amsl.com>; Thu, 22 Jan 2015 16:24:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 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] 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 T4s9Zf3xGda4 for <tls@ietfa.amsl.com>; Thu, 22 Jan 2015 16:24:13 -0800 (PST)
Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D30D1A004C for <tls@ietf.org>; Thu, 22 Jan 2015 16:24:12 -0800 (PST)
Received: by mail-we0-f174.google.com with SMTP id x3so4806447wes.5 for <tls@ietf.org>; Thu, 22 Jan 2015 16:24:11 -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:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0RzuBjVbKB331NQRAqCsqtZ4xRdfDBBQekQ7eMBG2H0=; b=Q6KyzzGehCKpGioFllGiVT5WfVEIYJpQ18HF2htZU9NgeOhHKCbnm2Dur2qXwCScT0 r0lpRzbEBOyxe7tkn8J5GSR0498M1ZdsAmZkGr1OdSQFT5Gl3UAFEe8174muWmztK2Nd +cNh0MaUtLq9ASEAo2VHo6sSdesInNdn6WHKrP+VHBCw+SpOUsrNFvQ5mdjmHWyjLrAH KD1lxQhpvPhhfOwXAnjY+B49jNq4DdPzLFkgM8BeVoS1c5lFYCF0B1pM5dmDsrpUdZmv g3NhOXzMgxxt9Yext9PkDLGNQh5utssAe7KVwYfYagaBAWsrxW92rCsVkWLaC+rHXmwY uTsw==
X-Gm-Message-State: ALoCoQnatZG6BLy7SJv7ATWAH2vYKy8j5xWcmO8tESJrc1bbEKAv7AnEP4G9QoLNBmtkPuq/ntkN
X-Received: by 10.194.2.240 with SMTP id 16mr8520852wjx.108.1421972651340; Thu, 22 Jan 2015 16:24:11 -0800 (PST)
MIME-Version: 1.0
Received: by 10.27.142.215 with HTTP; Thu, 22 Jan 2015 16:23:31 -0800 (PST)
In-Reply-To: <201501221918.56994.davemgarrett@gmail.com>
References: <40128f312378442fbd26459bf5d7593b@usma1ex-dag1mb2.msg.corp.akamai.com> <39B8BC24-D539-456F-970B-B11665B0E892@gmail.com> <54C0B783.2060604@metaparadigm.com> <201501221918.56994.davemgarrett@gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 22 Jan 2015 16:23:31 -0800
Message-ID: <CABcZeBNm2pogFosePd9YeVwhi1nOGq1OMBHBNo+ioLsSjQPPcg@mail.gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b343d84c38cbf050d46ce69"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/1M0DD7zwu-e5QmJzAfa8g3vwcBI>
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: Fri, 23 Jan 2015 00:24:15 -0000

Sorry I've been AWOL here. I'll try to take a look at it this weekend.

If the chairs wanted to review these PRs and confirm that they match the
WG consensus, that would save me some time.

-Ekr


On Thu, Jan 22, 2015 at 4:18 PM, Dave Garrett <davemgarrett@gmail.com>
wrote:

> On Thursday, January 22, 2015 03:40:35 am 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.
> [...]
> > The core issue is Appendix E does not make explicit a protocol version
> > deprecation mechanism. It seems TLSv1.3 { 3, 4 } should specify a
> > lower bound of { 3, 1 } for the record layer TLS version in the
> > ClientHello as they are the same major version (in reality).
> > The fact that SSLv3.0 has partial record layer binary compatibility
> > is a red herring. We should notionally subtract { 2, 1 }.
> > SSLv3.0 is past the used by date.
>
> I have PRs to deal with this area in TLS 1.3 still pending a decision. The
> current version is the consensus from the previous discussion on the topic.
>
> https://github.com/tlswg/tls13-spec/pull/105
> https://github.com/tlswg/tls13-spec/pull/107
>
> The changes are to prohibit SSL negotiation, drop SSL2 hello format
> documentation, freeze record layer hello version to 3.1, as well as other
> editorial improvements.
>
> I haven't heard back from ekr in a couple weeks.
>
>
> Dave
>