Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00

mrex@sap.com (Martin Rex) Mon, 02 March 2015 23:24 UTC

Return-Path: <mrex@sap.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 5FE541A8AAD for <tls@ietfa.amsl.com>; Mon, 2 Mar 2015 15:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 oew4MQkd-wYt for <tls@ietfa.amsl.com>; Mon, 2 Mar 2015 15:24:33 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB7A1A8AAB for <tls@ietf.org>; Mon, 2 Mar 2015 15:24:33 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id CF8C62AB5B; Tue, 3 Mar 2015 00:24:30 +0100 (CET)
X-purgate-ID: 152705::1425338671-0000765A-5CD806B8/0/0
X-purgate-size: 1109
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 800754266C; Tue, 3 Mar 2015 00:24:30 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 707871B1F3; Tue, 3 Mar 2015 00:24:30 +0100 (CET)
In-Reply-To: <CAKC-DJgKMdjFm0C2VzTFGipW-sdMWxycXJ=6kY0KLJsG88ntvQ@mail.gmail.com>
To: Erik Nygren <erik+ietf@nygren.org>
Date: Tue, 03 Mar 2015 00:24:30 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20150302232430.707871B1F3@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/dHzYTJWHvsMN4x8X9uMNkcVwzec>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-sslv3-diediedie-00
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
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, 02 Mar 2015 23:24:35 -0000

Erik Nygren wrote:
> Is it worth adding in a note to section 4 (Limited Capabilities) of:
> 
> * Server Name Indication to enable virtual hosting of multiple hosts with
> independent certificates on a single IP address
> 
> ?
> 
> I'm not sure if it's critical enough to hold up last-call?  It is another
> major down-side of the lack of extension support in SSLv3 from a
> deploy-ability perspective.


Your notion seems to be based on a urban legend.

SSLv3 (the protocol), in the final, after-the-fact publication
of November 18, 1996 (which the IETF failed to publish for 15 years,
but finally did as https://tools.ietf.org/html/rfc6106 ),
has _the_exact_same_ support for extensions as TLSv1.0.

Implementations of SSLv3, however, do not necessarily make use of
that capability.

SNI has only limited value, and provides an additional attack surface, e.g.
  https://bh.ht.vc/vhost_confusion.pdf


Personally, I'm much more concerned about newer software that breaks
horribly when no TLS extension SNI is present in the ClientHello,
such as Microsoft ADFS 2012.


-Martin