IETF Logo Mail Archive

Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft

Martin Thomson <martin.thomson@gmail.com> Mon, 29 December 2014 19:03 UTC

Return-Path: <martin.thomson@gmail.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 935FD1A9042 for <tls@ietfa.amsl.com>; Mon, 29 Dec 2014 11:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 jU8Ow8iAvkMh for <tls@ietfa.amsl.com>; Mon, 29 Dec 2014 11:03:33 -0800 (PST)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432A71A903E for <tls@ietf.org>; Mon, 29 Dec 2014 11:03:31 -0800 (PST)
Received: by mail-oi0-f53.google.com with SMTP id g201so30067438oib.12 for <tls@ietf.org>; Mon, 29 Dec 2014 11:03:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=se0uU6kEec2vrSLrSdaC92X5X2IwvNQndrX+4ehdiD0=; b=nmxWpWXujsE8rgzIfKB3oJBMiIjJIVc8vphoJwP8X7+8/U978/mI4WSO/zyMMki2gw qpcfzcSOnrVq8XV7ex7M/ZRrX19SS7U9oCLQfIlYcWLMo17h21OIKoFxbtcQu7xIK/B9 iQ9NinFGGrqSljcN3F93wgyF41n9vV4xbVJwkwrpSbHVdzJtT5buqJhC/nNTdkL7uJbo BEdTi368e17addl9LxORqESA7dX1R4Y2/IsveRKYJJNrO/TmQ3M4mBcoz12Mpa38CDxJ 5A7uBhagd1YHZdgA/xXxiqRzowJL9ODorZOmYPgxhokPrZ/OV0O4Lez71Z87MVEPIwHH vmXg==
MIME-Version: 1.0
X-Received: by 10.202.89.213 with SMTP id n204mr8063142oib.77.1419879810385; Mon, 29 Dec 2014 11:03:30 -0800 (PST)
Received: by 10.202.49.203 with HTTP; Mon, 29 Dec 2014 11:03:30 -0800 (PST)
In-Reply-To: <20141229115843.258CD1B0B4@ld9781.wdf.sap.corp>
References: <38DB9255-0F1B-40BC-A36B-D0241BE65E40@gmail.com> <20141229115843.258CD1B0B4@ld9781.wdf.sap.corp>
Date: Mon, 29 Dec 2014 11:03:30 -0800
Message-ID: <CABkgnnXRrNncvUdvBL2g+k6DCRUxMi-rTbDeymws_h5a--N8+g@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "mrex@sap.com" <mrex@sap.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yWKDGWtyJrwzDzt-TKFulchFTrk
Cc: Dave Garrett <davemgarrett@gmail.com>, "TLS@ietf.org (tls@ietf.org)" <tls@ietf.org>
Subject: Re: [TLS] drop obsolete SSL 2 backwards compatibility from TLS 1.3 draft
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, 29 Dec 2014 19:03:36 -0000

On 29 December 2014 at 03:58, Martin Rex <mrex@sap.com> wrote:
> Breaking backwards interop just for the sake of the fun of it is a bad
> idea and will slow down adoption.  Poor backwards interop slowed and is
> still slowing down adoption of TLSv1.2, and same for IPv6.

I think that - as I think Brian suggested earlier - requiring TLS 1.3
clients not to offer SSLv2/3; and requiring TLS 1.3 servers not to
negotiate 1.3 with clients that offer SSLv2/3; is perfectly
reasonable.  As a practical matter, we'll be relying on Hello
extensions, so those combinations are impossible anyway.

No one is going to change what Java 6 does.  And mandates on what any
deployment should do outside of what is required for TLS 1.3 would be
inappropriate for this draft.  Our separate recommendations on SSLv2/3
elsewhere should suffice.

You might agree to ignore those recommendations.  That is, as always,
your prerogative.  RFC compliance being essentially voluntary.

v2.23.0 | Report a Bug | By Email