Re: [TLS] New Draft: Using DNS to set the SNI explicitly

mrex@sap.com (Martin Rex) Fri, 10 March 2017 12:33 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE57B1298D9 for <tls@ietfa.amsl.com>; Fri, 10 Mar 2017 04:33:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.922
X-Spam-Level:
X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 gS1IgRwg0hWk for <tls@ietfa.amsl.com>; Fri, 10 Mar 2017 04:33:17 -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 105F51298C7 for <tls@ietf.org>; Fri, 10 Mar 2017 04:33:17 -0800 (PST)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3vfmrW2Bgzz1JLY; Fri, 10 Mar 2017 13:33:15 +0100 (CET)
X-purgate-ID: 152705::1489149195-0000521C-5D3DEAB4/0/0
X-purgate-size: 1087
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
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3vfmrW09dqzGpC3; Fri, 10 Mar 2017 13:33:15 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 000591A63F; Fri, 10 Mar 2017 13:33:14 +0100 (CET)
In-Reply-To: <20170310111732.GA825@LK-Perkele-V2.elisa-laajakaista.fi>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Fri, 10 Mar 2017 13:33:14 +0100 (CET)
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: <20170310123315.000591A63F@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QwZ4GcT13lNXw7HMPjXdiojD2tI>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] New Draft: Using DNS to set the SNI explicitly
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 10 Mar 2017 12:33:19 -0000

Ilari Liusvaara wrote:
> On Fri, Mar 10, 2017 at 09:25:41AM +0100, Martin Rex wrote:
>> 
>> You don't understand the purpose of SNI and how the (already weak)
>> rfc2818 section 3.1 server endpoint identification and CABrowser Forum
>> public CA Domain validation has been designed to work.
> 
> SNI has extremely little to do with public CA domain validation,
> except for special validation certificate selection in some
> methods.

SNI is the TLS-standard for clients to tell the server

"This is the DNS-Hostname, which I will use for rfc2818 section 3.1
 server endpoint identification. If you have multiple server certificates
 to choose from, you may want to consider this SNI value for choosing
 the server certificate to use for this TLS handshake".

CABrowser-Forum defines the rules which browsers implemenent on
top of rfc2818 section 3.1 server endpoint identity checks
of server certificates.

btw. SNI explicitly excludes IPv4 and IPv6 address matching that
is defined in rfc2818 section 3.1 as alternatives to DNS Hostname
matching.


-Martin