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

Martin Rex <mrex@sap.com> Tue, 25 May 2010 16:57 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 DB1E33A6ABE for <tls@core3.amsl.com>; Tue, 25 May 2010 09:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.734
X-Spam-Level:
X-Spam-Status: No, score=-7.734 tagged_above=-999 required=5 tests=[AWL=-0.085, 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 nac+3lu4B1Nh for <tls@core3.amsl.com>; Tue, 25 May 2010 09:57:47 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 8B69A3A6AE1 for <tls@ietf.org>; Tue, 25 May 2010 09:57:46 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o4PGvbdE022994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 25 May 2010 18:57:37 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201005251657.o4PGvZkE006346@fs4113.wdf.sap.corp>
To: mike-list@pobox.com (Michael D'Errico)
Date: Tue, 25 May 2010 18:57:35 +0200 (MEST)
In-Reply-To: <4BFBEF9B.6070602@pobox.com> from "Michael D'Errico" at May 25, 10 08:41:15 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: Tue, 25 May 2010 16:57:49 -0000

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.

Support for SNI is something that will at some point be adopted by
a server TLS stack, and it can easily happen before the application
(server) above is able to configure it appropriately.

This is particularly likely to happen if an updated TLS implementation is
made a drop-in replacement for a previous version without it and one
is distributing the updated TLS implementation into an installed base,
i.e. the TLS implementation is updated without touching application
code or configuration.

Usually, this indicates an avoidable and unnecessary backwards interop
problem created by the server TLS implementation.  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.

There are other unnecessary interop problems created by TLS implementations
that are sloppy.  Like TLS implementations sending out-of-order
certificate_list elements in Certificate handshake messages or
sending incomplete certification chains, that (server) lack more
that just a self-signed root certificate or that (client) do not
end at one of the trusted issuers announced by the server in the
certificate_authorities list of the CertificateRequest handshake
message.  While such behaviour might be helpful for automated
testing, it ought _NOT_ to be the default behaviour and only be
used when _explicitly_ requested by the calling application.

It is not a good idea for a protocol implementation to make a
remote peer suffer for a configuration problem that can be
only be fixed locally, in particular when it can be easily
detected locally.


-Martin