Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Fri, 04 June 2010 06:38 UTC

Return-Path: <jsalowey@cisco.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 D321A3A6A20 for <tls@core3.amsl.com>; Thu, 3 Jun 2010 23:38:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.227
X-Spam-Level:
X-Spam-Status: No, score=-10.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, 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 yM0UlEpSsv0y for <tls@core3.amsl.com>; Thu, 3 Jun 2010 23:38:48 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DCE853A6926 for <tls@ietf.org>; Thu, 3 Jun 2010 23:38:48 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAGM8CEyrR7H+/2dsb2JhbACeOHGkK5oCAoUUBINI
X-IronPort-AV: E=Sophos;i="4.53,359,1272844800"; d="scan'208";a="207016429"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 04 Jun 2010 06:38:35 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o546cZxo016849; Fri, 4 Jun 2010 06:38:35 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 3 Jun 2010 23:38:35 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 3 Jun 2010 23:38:33 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50A9EDC4E@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <op.vdqdftkkvqd7e2@killashandra.oslo.osa>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
Thread-Index: AcsDMrWcVYNymp9bSfKq73rLJ6LN6wAeVNjQ
References: <201005251657.o4PGvZkE006346@fs4113.wdf.sap.corp> <4BFC0FB9.5030908@pobox.com> <AC1CFD94F59A264488DC2BEC3E890DE50A9ED6F5@xmb-sjc-225.amer.cisco.com> <AANLkTilRO_rj68yZlX3WenciASNybJqHTSsnIMHHoLBU@mail.gmail.com> <AC1CFD94F59A264488DC2BEC3E890DE50A9ED759@xmb-sjc-225.amer.cisco.com> <op.vdqdftkkvqd7e2@killashandra.oslo.osa>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: <yngve@opera.com>, "Nikos Mavrogiannopoulos" <nmav@gnutls.org>
X-OriginalArrivalTime: 04 Jun 2010 06:38:35.0598 (UTC) FILETIME=[8EDA26E0:01CB03B0]
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
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: Fri, 04 Jun 2010 06:38:51 -0000

Hi Yngve,

Thanks for the text, some questions below:

> -----Original Message-----
> From: Yngve Nysaeter Pettersen [mailto:yngve@opera.com]
> Sent: Thursday, June 03, 2010 8:32 AM
> To: Nikos Mavrogiannopoulos; Joseph Salowey (jsalowey)
> Cc: tls@ietf.org
> Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
> 
> Hi,
> 
> 
> Actual text depends on what one want the extension and the alert to
do.
> 
> Relevant text:
> 
>     A server that receives a client hello containing the "server_name"
>     extension MAY use the information contained in the extension to
guide
>     its selection of an appropriate certificate to return to the
client,
>     and/or other aspects of security policy.  In this event, the
server
>     SHALL include an extension of type "server_name" in the (extended)
>     server hello.  The "extension_data" field of this extension SHALL
be
>     empty.
> 
>     If the server understood the client hello extension but does not
>     recognize the server name, it SHOULD send an "unrecognized_name"
>     alert (which MAY be fatal).
> 
> What needs to be specified is what a warning with this alert should
mean
> to the process of establishing the connection, and how it should be
used
> in combination with the returned extension. IMO only one of them may
be
> returned.
> 
> My preferred option is that the alert is only sent when the server
does
> not want to continue the negotiation, that is, a fatal alert, and not
> return a server_name extension in case it did not know the hostname,
but
> is willing to continue.
> 
> If that is the route we go then the last paragraph above could be
changed
> to
> 
>     If the server understood the client hello extension but does not
>     recognize the server name, and is not willing to establish a
> connection,
>     it MUST send a fatal "unrecognized_name" alert. If it is willing
to
>     establish the connection it MUST NOT return a "server_name"
extension,
>     and SHOULD NOT send a "unrecognized_name" warning.
> 
[Joe] It seems we still have the same problem, this just replaces the
warning with a lack of empty server_name extension.  I'm not sure I see
what this gains.  It also doesn't seem appropriate in this case to
mandate a change in behavior on the server.  It seems that the server
should return a server_name extension if it understands the extension
(its implemented and enabled).  

It doesn't seem that this is different than other cases where the client
receives a warning. From 5246 the text about warnings says:

" If an alert with a level of warning is sent and received, generally
   the connection can continue normally.  If the receiving party decides
   not to proceed with the connection (e.g., after having received a
   no_renegotiation alert that it is not willing to accept), it SHOULD
   send a fatal alert to terminate the connection.  Given this, the
   sending party cannot, in general, know how the receiving party will
   behave.  Therefore, warning alerts are not very useful when the
   sending party wants to continue the connection, and thus are
   sometimes omitted.  For example, if a peer decides to accept an
   expired certificate (perhaps after confirming this with the user) and
   wants to continue the connection, it would not generally send a
   certificate_expired alert."

Maybe we should change the second paragraph text to 

"If the server understood the client hello extension but does not
 recognize the server name, and it refuses to continue it MUST 
 send a fatal "unrecognized_name" alert.  If the server continues the 
 handshake, sending a "unrecognized_name"
 alert with a warning level is NOT RECOMMENDED, since the 
 client behavior is unpredictable.  Some clients
 may respond by aborting the handshake while others may allow it
 to continue to certificate validation, which may fail as a result 
 of a name mismatch. "







> One can also add a note that some current implementations will send a
> warning _and_ include the "server_name" extension (that is the current
> status on the server I observed with the configuration issue), and
that
> some clients escalate the warning to Fatal.
> 
> 
> On Thu, 03 Jun 2010 16:02:43 +0200, Joseph Salowey (jsalowey)
> <jsalowey@cisco.com> wrote:
> 
> > If we are going to make a change then we need some suggested text.
> >
> > Joe
> >
> >> -----Original Message-----
> >> From: n.mavrogiannopoulos@gmail.com
> >> [mailto:n.mavrogiannopoulos@gmail.com] On Behalf Of Nikos
> >> Mavrogiannopoulos
> >> Sent: Thursday, June 03, 2010 12:24 AM
> >> To: Joseph Salowey (jsalowey)
> >> Cc: Michael D'Errico; mrex@sap.com; tls@ietf.org
> >> Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112)
alert
> >>
> >> I believe that it is quite bad practice to delegate to application
> >> protocol. This is protocol stack signalling and shouldn't be
> >> application specific. Otherwise interoperability problems occur. A
> >> protocol spec should be clear on what it does.
> >>
> >> regards,
> >> Nikos
> >>
> >> On Thu, Jun 3, 2010 at 7:22 AM, Joseph Salowey (jsalowey)
> >> <jsalowey@cisco.com> wrote:
> >> > It seems that the behavior is dependent upon the application.
I'm
> >> not
> >> > sure we would come up with useful text here.  In the interest of
> >> getting
> >> > this document published I suggest we leave it as is.
> >> >
> >> > Joe
> >> >
> >> >> -----Original Message-----
> >> >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On
Behalf
> >> Of
> >> >> Michael D'Errico
> >> >> Sent: Tuesday, May 25, 2010 10:58 AM
> >> >> To: mrex@sap.com
> >> >> Cc: tls@ietf.org
> >> >> Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112)
alert
> >> >>
> >> >> Martin Rex wrote:
> >> >> > Michael D'Errico wrote:
> >> >> >> In my server code, the SNI is checked to see if there is a
> >> matching
> >> >> >> virtual host with that domain name.  If there is, then no
alert
> >> is
> >> >> >> sent.  If there is no matching virtual host, then it checks
> >> whether
> >> >> >> there is a default virtual host set up.  If there is a
default,
> >> > then
> >> >> >> an unrecognized_name alert is sent with the warning level.
When
> >> no
> >> >> >> default is configured, the alert sent is fatal since the
> >> handshake
> >> >> >> can not continue.
> >> >> >>
> >> >> >> The warning lets the client know that there was not a match,
but
> >> >> that
> >> >> >> the server can still continue using its default.
> >> >> >
> >> >> >
> >> >> > While this behaviour appears quite sensible/plausible, it will
> >> lead
> >> >> > to the behaviour in the wild that Yngve is reporting.
> >> >> >
> >> >> > An application which
> >> >> > does not configure any SNI characteristics, is not using SNI,
and
> >> >> > for these, the server TLS implementation should _NOT_ be
sending
> >> >> > SNI mismatch TLS alerts unless the application explicitly
requests
> >> >> so.
> >> >>
> >> >> My server code will not send an alert unless the client (a) sent
an
> >> >> SNI and (b) that SNI did not map to a virtual host.
> >> >>
> >> >> So that should not cause a problem.
> >> >>
> >> >> It might be a good idea to clarify when sending an
unrecognized_name
> >> >> alert would be appropriate and clarify that it can be just a
warning
> >> >> and what that means.
> >> >>
> >> >> Mike
> >> >> _______________________________________________
> >> >> TLS mailing list
> >> >> TLS@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/tls
> >> > _______________________________________________
> >> > TLS mailing list
> >> > TLS@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/tls
> >> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> 
> 
> --
> Sincerely,
> Yngve N. Pettersen
> ********************************************************************
> Senior Developer		     Email: yngve@opera.com
> Opera Software ASA                   http://www.opera.com/
> Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
> ********************************************************************