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

Marsh Ray <marsh@extendedsubset.com> Fri, 04 June 2010 17:15 UTC

Return-Path: <marsh@extendedsubset.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 CFD6A3A67E5 for <tls@core3.amsl.com>; Fri, 4 Jun 2010 10:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 DwVwnCRQCHsj for <tls@core3.amsl.com>; Fri, 4 Jun 2010 10:15:06 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 0DF613A694C for <tls@ietf.org>; Fri, 4 Jun 2010 10:15:05 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OKaTq-0001qt-S1 for tls@ietf.org; Fri, 04 Jun 2010 17:14:50 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D436D64D8 for <tls@ietf.org>; Fri, 4 Jun 2010 17:14:49 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/LLk1zPYJq5oPHrkKuB5DBwa75h1LnBuA=
Message-ID: <4C093484.5010803@extendedsubset.com>
Date: Fri, 04 Jun 2010 12:14:44 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: tls@ietf.org
References: <201006041647.o54Gl4iH024692@fs4113.wdf.sap.corp>
In-Reply-To: <201006041647.o54Gl4iH024692@fs4113.wdf.sap.corp>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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: Fri, 04 Jun 2010 17:15:19 -0000

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.

Although it is good to try to avoid it, the vast majority of nontrivial
systems have failure modes that were not anticipated during development
and testing. As a developer, I really value the ability to issue some
opaque internal error code message into some log file. Somehow the
system got into a state that I didn't expect it could, if I could have
described how the system should react, I would have coded it that way.

A strict policy like "all warnings must X" just leads to the warning
message facility being unusable for cases where X is too difficult.

- Marsh