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

Michael D'Errico <mike-list@pobox.com> Mon, 07 June 2010 16:35 UTC

Return-Path: <mike-list@pobox.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 B9E1628C3A9 for <tls@core3.amsl.com>; Mon, 7 Jun 2010 09:35:51 -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 pOXDJAHv6J-H for <tls@core3.amsl.com>; Mon, 7 Jun 2010 09:35:49 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id D4A4A3A8679 for <tls@ietf.org>; Sun, 6 Jun 2010 09:10:33 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8D9E3B9311 for <tls@ietf.org>; Sun, 6 Jun 2010 12:10:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type; s=sasl; bh=CKb0 WGVPUz0Q9vTHsdkRzmmIcUY=; b=vcTeoDJN8J3pDHzvt0zRRDN3pOxQYT2t+fx5 HYH40nJhr5car4rf3kSfuuA3UxLTran9MI7o0/+4F5m0HbK5HXf1dEVY3yVD/qmV A2vqDNtkHSLelxBCGskMeAwQR/XcAvy5d4EUSRoCzjzVv1D267V+BQJg9LjE1DB1 H/STijU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type; q=dns; s=sasl; b=tJH Rn18S8Nx46gZjcDPFZkV46FElN130K0PpgLuwHrPWyBE/kwKH1lVEPZNaUXNR3cs d5X9utAL0ZaV5JDRUTqAB1nYto4oryIDbrJLrKA5LrXfmf5k9GgtuNti1YtCaCvH 78upDr+3mjkf6YRbMFb/K1CxwZwJjcLNTNeFQabA=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8A870B9310 for <tls@ietf.org>; Sun, 6 Jun 2010 12:10:33 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 1F6BAB930F for <tls@ietf.org>; Sun, 6 Jun 2010 12:10:32 -0400 (EDT)
Message-ID: <4C0BC878.1050302@pobox.com>
Date: Sun, 06 Jun 2010 09:10:32 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: TLS Mailing List <tls@ietf.org>
Content-Type: multipart/mixed; boundary="------------090806000109070902020103"
X-Pobox-Relay-ID: 0906660C-7186-11DF-BA62-6730EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Subject: [TLS] [Fwd: Re: 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: Mon, 07 Jun 2010 16:35:51 -0000

[I'm resending this message since it never made it to the list
the first time.  --Mike]
--- Begin Message ---
Nikos Mavrogiannopoulos wrote:
> Michael D'Errico wrote:
>> I prefer the above text, but would modify it slightly:
>>     If the server decides to continue the handshake, sending an
>>     unrecognized_name(112) alert with a warning level is NOT
>>     RECOMMENDED at this time due to legacy client software that
>>     escalates it to a fatal error.  
> 
> This wording however suggests that at a later time it might be good to
> send this alert with warning level. I agree with Martin here, that if a
> warning level alert is to be sent then it's purpose should be well
> defined. Otherwise it just increases complexity, without actual benefit.

I have already shown when a warning alert makes sense.  If a server
doesn't recognize the name but is willing to continue with the handshake
anyway (using a default configuration), it can alert the client to this
fact by sending a warning alert.  It is NOT fatal.  You and others want
to suppress this piece of information, which I believe could be useful.
So that's why my text suggests that in the future this alert might be
good to send with a level of warning.

>>     New software is encouraged
>>     to treat warning alerts as informational, and not to abort
>>     an otherwise legitimate handshake.
> 
> I believe this is too much for an extensions document. If wording like
> this is to be adopted it should be in the main TLS document.

It should be in both places, especially since there won't be another
update to the main spec for several years.

The problem seems to be that the names given to alert levels both sound
bad.  Really what they mean are "fatal" and "non-fatal" but since the
name "warning" was chosen as the label, implementers who haven't thought
much about it decide that warning == bad, so they escalate it to fatal.

They need to be told that warning alerts should not automatically be
treated as fatal, but should be ignored by default.  If they have gone
through an analysis and determined that a particular warning alert is
really fatal for them, then they are justified in aborting the handshake
when they see that particular warning.

> My version of how the text should be is:
> 
> (1) "The ServerNameList MUST NOT contain more than one name of the same
> name_type. If the server understood the client hello extension, but does
> not recognize the server name, and it refuses to continue it MUST send a
> fatal unrecognized_name(112) alert and terminate the handshake.
> The server might decide to continue the  handshake, but in that case it
> is NOT RECOMMENDED send any warning alert. Clients SHOULD be prepared to
> receive and ignore the unrecognized_name(112) alert with warning level.

I could live with this text.  I would also like section 9 (Error Alerts)
to mention that warning alerts should be treated as informational (non-
fatal) by default to help avoid similar problems in the future.

Mike

--- End Message ---