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

Martin Rex <mrex@sap.com> Fri, 04 June 2010 16:02 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 313023A69B9 for <tls@core3.amsl.com>; Fri, 4 Jun 2010 09:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level:
X-Spam-Status: No, score=-7.548 tagged_above=-999 required=5 tests=[AWL=0.101, 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 nkUXVV0sMxxV for <tls@core3.amsl.com>; Fri, 4 Jun 2010 09:02:26 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 96F4A3A69C3 for <tls@ietf.org>; Fri, 4 Jun 2010 09:02:25 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o54G1w03008130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jun 2010 18:01:58 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006041601.o54G1vCW022151@fs4113.wdf.sap.corp>
To: nmav@gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 4 Jun 2010 18:01:57 +0200 (MEST)
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 virwal05
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: Fri, 04 Jun 2010 16:02:27 -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 think the issue is much more about API semantics.

Most APIs are pretty binary, either they succeed, or they fail with
a (numeric) error code.  The case "succeeds with a warning code"
is fairly unusual for APIs, and very unusual to application programmers.

Defining non-fatal error codes might be possible, but you don't know
what exactly apps will do: will they simply ignore error codes that
are classified non-fatal or will they abort on all error codes that
they do not recognize.

And as soon as you have several software/abstraction layers in your
software architecture, the picture becomes more and more fuzzy,
because you don't know whether intermediate layers are prepared
to deal with non-fatal error codes and in particular non-fatal
error codes that were defined after the intermediate layers
were shippped.

A warning-level "unrecognized_name" alert is useful for the receiver
only when it is made available to the application on top of TLS in
a clearly defined and consistent fashion.  If we want to allow
warning-level "unrecognized_name" alerts, then we must define
the API semantics for the receiving TLS implementation that
its calling app is going to experience.  Otherwise, we should get
rid of it (and use the fatal-level alert for the situation where
the server is condigured to abort the handshake).


-Martin