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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 12 January 2015 11:12 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 1030C1A6F10; Mon, 12 Jan 2015 03:12:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 yUDc59dUDhUB; Mon, 12 Jan 2015 03:11:55 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557461A1B75; Mon, 12 Jan 2015 03:11:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5B619BEFC; Mon, 12 Jan 2015 11:11:53 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztp4w9WT0kDo; Mon, 12 Jan 2015 11:11:53 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 32082BEF3; Mon, 12 Jan 2015 11:11:53 +0000 (GMT)
Message-ID: <54B3ABF9.7000809@cs.tcd.ie>
Date: Mon, 12 Jan 2015 11:11:53 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
References: <20150109180539.22231.7270.idtracker@ietfa.amsl.com> <285245260.5608886.1420918276899.JavaMail.zimbra@redhat.com> <54B1C841.2020707@cs.tcd.ie> <1421054156.3211.15.camel@redhat.com>
In-Reply-To: <1421054156.3211.15.camel@redhat.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/NRywxRGJUW90Dm4YH3fDc2CNqxE>
Cc: ietf@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: Mon, 12 Jan 2015 11:12:01 -0000

Hi Nikos,

On 12/01/15 09:15, Nikos Mavrogiannopoulos wrote:
> On Sun, 2015-01-11 at 00:48 +0000, Stephen Farrell wrote:
>> Hi Nikos,
>>>> The IESG plans to make a decision in the next few weeks, and solicits
>>>> final comments on this action. Please send substantive comments to the
>>>> ietf@ietf.org mailing lists by 2015-01-23. Exceptionally, comments may be
>>>> sent to iesg@ietf.org instead. In either case, please retain the
>>>> beginning of the Subject line to allow automated sorting.
>>>>    This document defines a Signaling Cipher Suite Value (SCSV) that
>>>>    prevents protocol downgrade attacks on the Transport Layer Security
>>>>    (TLS) protocol.  It updates RFC 2246, RFC 4346, and RFC 5246.
>>> The "TLS Fallback Signaling Cipher Suite" fix cannot be a proposed standard. 
>>> The mechanism it fixes (the browser's special downgrade of TLS) is not an IETF
>>> protocol, nor related to the TLS WG. Making this a proposed standard, would 
>>> imply that the flawed technique is into standards track. 
>> I don't believe that that last conclusion follows. AFIAK there is
>> nothing to prevent the IETF standardising a fix for someone else's
>> or even our own past mistakes(*) even when those mistakes are not
>> on the standards track. And if in fact stardardising the "fix"
>> improves the Internet, then we should do that as the set of folks
>> responsible for this technology. (If doing so has IETF consensus.)
> 
> It's not up to me to say whether there was consensus for this draft or
> not. 

Yep, we'll see when the IETF LC is done.

> I voiced my opinion against that draft. 

Not quite. You said this "cannot be" a PS based on an argument
that is independent of the content of the draft.

> However, if you think that
> this has to be on standards track, please provide at least some
> argumentation for it. 

Sorry, I was only answering your general point above, where
you said the IETF couldn't produce a PS to fix a problem with
a non-IETF thing - I was addressing the "cannot be a proposed
standard" part. I think it clearly can, and given that you're
moving the discussion along to the specifics of the draft, I
assume you accept that.

So now you're being more specific and saying that I need
to provide an argument that this "has to be on the standards
track." I don't think I actually do need to provide such an
argument that there was no other good choice - that the TLS
WG chose to process it as a PS is reasonable enough. And are
we really going to benefit if we argue about the RFC status
here anyway? (Especially when it seems from the text below
and the WG list discussion that your main issue is with the
approach being taken and not with the RFC meta-data or
process followed.)

But in any case, this is changing protocol that is specified
in PS RFCs so a PS RFC does seem like the only good choice in
this case. I think the WG also made that choice because this
formally updates a bunch of RFCs and they want implementers
of those to pick this up, which is a teeny bit more likely
with the updates meta-data in the RFC editor's database.
That's explicitly noted in the shepherd's write-up [1] and I
assume was made clear on the WG list. As also noted in [1]
the volume of mail on this was very high, so I'd have to go
look. So having this be a PS that updates a bunch of other
PS RFCs is cleaner and I hope avoids a bunch of RFC process
wrangling. (It is sadly not uncommon for one or other of us
on the IESG to quibble about the utterly boring minutiae of
such relationships between RFCs as we process them:-)

> As far as I understand, this fix exists because Microsoft, Google and
> Mozilla cannot coordinate and drop their insecure negotiation of TLS.

I don't see that as a new argument. I think we all agree
there is a problem. The TLS WG (after much debate) chose
this particular approach. At this point I do not see that
opinions as to the ultimate cause of the problem are useful
for the IETF LC.

Cheers,
S.

[1]
https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/shepherdwriteup/


> 
> regards,
> Nikos
> 
>