Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
Martin Rex <mrex@sap.com> Mon, 07 June 2010 17:24 UTC
Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C3D43A6F22 for <tls@core3.amsl.com>; Mon, 7 Jun 2010 10:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.649
X-Spam-Level:
X-Spam-Status: No, score=-7.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN1LqKHJOUlW for <tls@core3.amsl.com>; Mon, 7 Jun 2010 10:24:13 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id DA3D828C810 for <tls@ietf.org>; Mon, 7 Jun 2010 09:06:11 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o57EkZXO001676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jun 2010 16:46:35 +0200 (MEST)
Received: from fs4113.wdf.sap.corp (fs4113.wdf.sap.corp [10.21.76.84]) by mail.sap.corp (mail03-25) with ESMTP id o57EkTnf023491 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 7 Jun 2010 16:46:34 +0200 (MEST)
Received: (from d019080@localhost) by fs4113.wdf.sap.corp (8.13.4+Sun/8.13.4/Submit) id o57EkTuW029119; Mon, 7 Jun 2010 16:46:29 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006071446.o57EkTuW029119@fs4113.wdf.sap.corp>
To: nmav@gnutls.org
Date: Mon, 07 Jun 2010 16:46:29 +0200
In-Reply-To: <4C08926B.2080107@gnutls.org> from "Nikos Mavrogiannopoulos" at Jun 4, 10 07:43:07 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 07 Jun 2010 17:24:15 -0000
Nikos Mavrogiannopoulos wrote: > > Michael D'Errico wrote: > > I agree with Yngve that a server should send either an empty SNI > > extension OR an unrecognized_name alert but not both. However, I > > disagree that the server SHOULD NOT send a warning alert since that > > hides information from the client. > [...] > > 1 - server understood the SNI and used it to select an appropriate > > certificate chain and other parameters > > 2 - server understood the SNI but did not recognize it as one of > > its configured virtual hosts; however, the server is set up > > to use a default configuration in that case > > 3 - server understood the SNI but did not recognize it as one of > > its configured virtual hosts; there is no default configuration > > available so the handshake can not continue > > 4 - server does not understand the SNI extension > > > > The way my server reacts to each of these cases is: > > > > 1 - add an empty SNI extension to ServerHello > > 2 - send a warning unrecognized_name alert > > 3 - send a fatal unrecognized_name alert > > 4 - send nothing > > > > Yngve would prefer that nothing is sent in case 2, but then a client > > can not distinguish it from case 4. > > I believe that his point was, what can the client do anyway? In both > cases the client just follows the handshake and will be prompted if the > "default" certificate doesn't match the connected host. Would the client > need to be warned that he is being connected using the "default" > certificate rather than any specific? I actually fail to see the exact purpose of a warning-level alert "unrecognized_name". The client is supposed to perform the server endpoint identification in any case, and that warning should not affect the outcome of that process at all. Btw. this warning-level alert could be stripped from the handshake by an attacker _without_ affecting the handshake message hash and finished calculations (alerts are not handshake messages and are therefore invisible to the handshake message hash). Similarly, an attacker can insert such a warning-level alert into handshakes without affecting the handshake message hash. I think there should be a guidance in the spec what the receiver of that alert at level warning should do. A client that receives a warning-level "unrecognized_name" alert SHOULD ignore this alert and continue the TLS handshake. The purpose of a warning-level "unrecognized_name" is for diagnostic purposes, if anything. A client TLS implementation MAY offer API functionality for the client application to determine what warning-level alerts were received during a TLS handshake. When the server endpoint identification performed by the client application fails, then a client application might want to query whether any warning-level alerts have been received during the TLS handshake and mention these in the information presented to a user or written to a logfile for diagnostic purposes. -Martin
- [TLS] RFC-4366-bis and the unrecognized_name(112)… Yngve Nysaeter Pettersen
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Yngve Nysaeter Pettersen
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Yngve Nysaeter Pettersen
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Marsh Ray
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Marsh Ray
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Saint-Andre
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- [TLS] [Fwd: Re: RFC-4366-bis and the unrecognized… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Marsh Ray
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Gutmann
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Donald Eastlake
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Sean Turner
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… t.petch
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Paul Hoffman
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Marsh Ray
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Saint-Andre
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Joseph Salowey (jsalowey)
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Marsh Ray
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Nikos Mavrogiannopoulos
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Michael D'Errico
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Sylvester
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Sylvester
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Peter Sylvester
- Re: [TLS] RFC-4366-bis and the unrecognized_name(… Martin Rex