Re: [TLS] Deprecating SSLv3

Alfredo Pironti <alfredo@pironti.eu> Fri, 21 November 2014 22:35 UTC

Return-Path: <alfredo@pironti.eu>
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 DF4411A8AB3 for <tls@ietfa.amsl.com>; Fri, 21 Nov 2014 14:35:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.378
X-Spam-Level:
X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, 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 PIsek6UnIQH7 for <tls@ietfa.amsl.com>; Fri, 21 Nov 2014 14:35:26 -0800 (PST)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BB471A8AA8 for <tls@ietf.org>; Fri, 21 Nov 2014 14:35:26 -0800 (PST)
Received: by mail-oi0-f42.google.com with SMTP id v63so4361777oia.15 for <tls@ietf.org>; Fri, 21 Nov 2014 14:35:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IQaUiiF4LuzwGdglHlRTglqrblzDKb3V/NTjr07alqs=; b=WMUFiWRbHW3cBoGhU+TIxeJnWnGCh3W7sCcm2hEs0O5gyIZn559x2EKwA4Mk3NtpMG nF6exZawJSWq0OeCGfsWJaKC8sKvD/Mfnt9RF8qRotsGm11mx28/NtuCQWHkc4koXJDr GUrAsocJ2iPTOWny6GH2ECtvVyKNhzYZJuz+0=
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:date :message-id:subject:from:to:cc:content-type; bh=IQaUiiF4LuzwGdglHlRTglqrblzDKb3V/NTjr07alqs=; b=L0cAUKr9hH4jrIqYwUfC2tOaelUEZkApDvZEEwAlpEeueqXvXx/2b37jgzS4JYIAPQ ieaNETBMPLVYjaHASs+Pv84t2Wv82h0H8IuVSg3r5OZPnb1nuW0YtZ141+EwimUg5GrF 3kOo28pAn452w3qXg/TUtvjDzka/xVd0JABx2JYuCxzGIRTxT2rUUSESBxzSjR8Un7Yi uVDH4ALYGIGxfqa28UXHgMbpD0p2x7iY9C1aZit6HKJ/Hq/28gYDkRGJtU76bDoUuV1n 49r9H8cLrEKwDpia42nOawc+gxN0g5cl+4LvH8BU9ZeuAjfe1/yiJv+Hg/SPpDB+zbwa Hxrg==
X-Gm-Message-State: ALoCoQmrhLxw3WbE3Ct2e1ZFzq0Ea3E59EesUlFJ6SfM+q0FWwIbKmbLBWNLN4JlePgBhxdCjj/l
MIME-Version: 1.0
X-Received: by 10.60.134.20 with SMTP id pg20mr4708332oeb.36.1416609325565; Fri, 21 Nov 2014 14:35:25 -0800 (PST)
Received: by 10.76.84.65 with HTTP; Fri, 21 Nov 2014 14:35:25 -0800 (PST)
X-Originating-IP: [82.224.193.99]
In-Reply-To: <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com>
References: <CABkgnnWw9zsrqQzHVU0vXLJM+HBK3QYxJAZE+0kgGkEQEzwS=w@mail.gmail.com> <5462714E.5020201@polarssl.org> <CABkgnnUm=6TriH9UU-Uv8_rWt_CEvW1Xy8P_955ryFCvn3mWOA@mail.gmail.com> <1193984696.9333579.1416162106243.JavaMail.zimbra@redhat.com> <CALR0uiLfH-p9EbGF_=J8XMEuMczMsZJMfECKDt5E0Q9BBEpDOQ@mail.gmail.com> <1416584605.18312.21.camel@dhcp-2-127.brq.redhat.com>
Date: Fri, 21 Nov 2014 23:35:25 +0100
Message-ID: <CALR0ui+1e8pm+67Pn3LV_Pw2Ma1K7c2egWf=m7amDck9fAn62A@mail.gmail.com>
From: Alfredo Pironti <alfredo@pironti.eu>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Content-Type: multipart/alternative; boundary="047d7b472948a2e4f10508660f60"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q9D7tCnQCD3QtbO-HraYa43tYRM
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Deprecating SSLv3
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, 21 Nov 2014 22:35:30 -0000

Hi Nikos,

Thanks for your further comments. I'm answering to them inline.

On Fri, Nov 21, 2014 at 4:43 PM, Nikos Mavrogiannopoulos <nmav@redhat.com>
wrote:

> On Sun, 2014-11-16 at 23:22 +0100, Alfredo Pironti wrote:
>
>
> > Yes, I agree this is a fair point. I'll complete the wording tomorrow
> > in the pending PR, and these ideas will get into the updated version.
>
> Some additional comments:
> 1. It has quite awkward structure. The main body of the document is at
> the introduction section.
>

The structure can certainly be reworked once further consensus is reached,
and hence the text stabilizes. I expect that some further editorial work
may be required anyway if the draft proceeds forwards.


>
> 2. The text "Negotiation of SSLv3 from any version of TLS MUST NOT be
> permitted."
> Not sure I understand what it means. Does it mean that fallback to SSL
> 3.0 from any version of TLS MUST NOT be permitted?
>

Well, the idea is that once SSLv3-only software is eradicated, then only
TLS implementations capable of running SSLv3 will remain. Those should not
negotiate SSLv3, even if they're able to do so. Anyway, most of this text
is being recently reworked to be clearer and fix the Record layer potential
interop issues you and others have already noted. See for instance the
proposed draft [1].


>
> 3. The document doesn't provide any instructions for clients that have
> no other way to communicate with a server that only supports SSL 3.0.
> MUST NOT is nice in theory, but can only be enforced on the systems one
> has control on, and if the advise is followed to the letter legacy
> systems (not talking of web) will be only be accessible in plaintext.
>

My understanding is that MUST NOT is the way legacy protocols usage is
prohibited, see for example SSLv2 deprecation [2], which uses a very
similar terminology. Of course closed systems will be free to ignore this
document and still negotiate SSLv3 (or v2, for that matters). But yes, I'd
claim the whole purpose of this draft is to outlaw (and encourage to update
to TLS, not to retrofit to plaintext) open systems that connect to the
Internet.


> I'd expect prohibiting the fallback dance instead, and requiring that
> SSL 3.0 is negotiated only if TLS 1.0 or later are advertised in the
> clientHello.
>

I'd keep fallback out of the scope of this document, as the so notorious
fallback dance has never been part of the TLS protocol negotiation itself.
And, certainly, I wouldn't advocate fallback (even straight SSLv3
negotiation could be used as a last-resort fallback by some) to still
support negotiation of SSLv3 for systems that don't really bother to
upgrade to TLS almost 15 years after it was specified.

Best,
Alfredo

[1] https://github.com/unicorn-wg/sslv3-diediedie/pull/10
[2] http://tools.ietf.org/html/rfc6176


>
> regards,
> Nikos
>
>
>
>