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

"Yngve Nysaeter Pettersen" <yngve@opera.com> Thu, 03 June 2010 15:35 UTC

Return-Path: <yngve@opera.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 E077A3A69DF for <tls@core3.amsl.com>; Thu, 3 Jun 2010 08:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 kVomjFrMnbiL for <tls@core3.amsl.com>; Thu, 3 Jun 2010 08:34:59 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 79B613A6986 for <tls@ietf.org>; Thu, 3 Jun 2010 08:34:00 -0700 (PDT)
Received: from killashandra.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o53FW9iK022880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Jun 2010 15:32:18 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Nikos Mavrogiannopoulos" <nmav@gnutls.org>, "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
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>
Date: Thu, 03 Jun 2010 17:32:07 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve Nysaeter Pettersen" <yngve@opera.com>
Organization: Opera Software
Message-ID: <op.vdqdftkkvqd7e2@killashandra.oslo.osa>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50A9ED759@xmb-sjc-225.amer.cisco.com>
User-Agent: Opera Mail/10.53 (Win32)
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: yngve@opera.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: Thu, 03 Jun 2010 15:35:41 -0000

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.

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
********************************************************************