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

Martin Rex <mrex@sap.com> Fri, 04 June 2010 18:48 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 8EA6D3A69EF for <tls@core3.amsl.com>; Fri, 4 Jun 2010 11:48:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.579
X-Spam-Level:
X-Spam-Status: No, score=-7.579 tagged_above=-999 required=5 tests=[AWL=0.070, 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 HzWBMY+wcRrg for <tls@core3.amsl.com>; Fri, 4 Jun 2010 11:48:20 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 172FB3A6A08 for <tls@ietf.org>; Fri, 4 Jun 2010 11:48:18 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o54IljAC024328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Jun 2010 20:47:45 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006041847.o54IliTQ001508@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Fri, 4 Jun 2010 20:47:44 +0200 (MEST)
In-Reply-To: <4C093484.5010803@extendedsubset.com> from "Marsh Ray" at Jun 4, 10 12:14:44 pm
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: Fri, 04 Jun 2010 18:48:22 -0000

Marsh Ray wrote:
> 
> On 6/4/2010 11:47 AM, Martin Rex wrote:
> >
> > But defining only the situation when one peer can send a particular
> > warning level alert is entirely insufficient.  The definition of
> > a warning-level alert _MUST_ describe how the receiving peer is
> > supposed to react to this.
> 
> I don't agree with such an absolute statement.
> 
> Sometimes the only use of a protocol message is to provide information
> to a software developer who wrote the code so he has some clues to go on
> when the bug report with the protocol trace lands in his inbox.

It seems that I wasn't clear enough in my description.

This must first of all describe how the implementor of the technology TLS
must make this information available to the consumer of the
technology/implementation (i.e. the application caller).

This is similar of how an implementation of TCP must exihibt specific
semantics to the application caller on receipt of certain TCP flags,
e.g. the TCP PUSH flag.

If the spec does not describe this, then it may result in either getting
entirely ignored--at which point it is useless complexity in the spec,
or result in unnecessary interop problems, i.e. if a client unconditionally
abort receiving a warning-level unrecognized_name alert.  In both cases
such a (mis-)feature would have to be stripped when advancing the spec
to draft, so there is no point including it in the spec in the first place.

-Martin