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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 03 June 2010 07:24 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 832E43A6A01 for <tls@core3.amsl.com>; Thu, 3 Jun 2010 00:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.437
X-Spam-Level:
X-Spam-Status: No, score=0.437 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FM_FORGED_GMAIL=0.622]
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 OYBXYLveq9tl for <tls@core3.amsl.com>; Thu, 3 Jun 2010 00:24:35 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id F261E3A672E for <tls@ietf.org>; Thu, 3 Jun 2010 00:24:34 -0700 (PDT)
Received: by wyf23 with SMTP id 23so2409077wyf.31 for <tls@ietf.org>; Thu, 03 Jun 2010 00:24:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=zumafjgPR1E4B9PV8GZMG+RU+rmqvYwjo8sryA1HXr0=; b=fPA7Zhj7NBUThXNVBSJPdiQpmuz/QqkXsB1gb0LpBmr7QLibMHoSMCIZGLscmJhul9 g6ToikajK/pR/qtff4GXW95U+z3IN75c0U4cfXrNT+reKEgjxEXJeNN/+A6bRy3F6YqF 1rZjdb/KM8eIGe7osLXNFzYld2ZHzWA8ApNe0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=niuMka6JZmWQgH15XJtoFTHuY5YfYFVEPy7vv0lgjER3N9HZ4IDS6/G405MRBVPxND GvfNI7P5OgbvzNyeic8Twb9lH/uW8OsGKqloBZX/yZvB5suwEWf2RZ0SHwsNVVlCisVP 3ShVQJ6vpcmJ4VUlJWT0U+A+BEinCojMomxsg=
MIME-Version: 1.0
Received: by 10.227.69.213 with SMTP id a21mr8775838wbj.220.1275549856899; Thu, 03 Jun 2010 00:24:16 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.216.171.211 with HTTP; Thu, 3 Jun 2010 00:24:16 -0700 (PDT)
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE50A9ED6F5@xmb-sjc-225.amer.cisco.com>
References: <201005251657.o4PGvZkE006346@fs4113.wdf.sap.corp> <4BFC0FB9.5030908@pobox.com> <AC1CFD94F59A264488DC2BEC3E890DE50A9ED6F5@xmb-sjc-225.amer.cisco.com>
Date: Thu, 3 Jun 2010 09:24:16 +0200
X-Google-Sender-Auth: hEhPKVhhrpyYCFfNcNDKe50E0Fo
Message-ID: <AANLkTilRO_rj68yZlX3WenciASNybJqHTSsnIMHHoLBU@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Thu, 03 Jun 2010 07:24:39 -0000

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
>