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

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Fri, 04 June 2010 17:37 UTC

Return-Path: <jsalowey@cisco.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 5554B3A67AB for <tls@core3.amsl.com>; Fri, 4 Jun 2010 10:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.98
X-Spam-Level:
X-Spam-Status: No, score=-9.98 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, 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 rv-OCax-UHAJ for <tls@core3.amsl.com>; Fri, 4 Jun 2010 10:37:18 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 483AD3A67E5 for <tls@ietf.org>; Fri, 4 Jun 2010 10:37:18 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAK3VCEyrR7Hu/2dsb2JhbACeRnGlTZoNhRcEg0k
X-IronPort-AV: E=Sophos;i="4.53,362,1272844800"; d="scan'208";a="139545260"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 04 Jun 2010 17:37:04 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o54Hb4Xr010944; Fri, 4 Jun 2010 17:37:04 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jun 2010 10:37:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 4 Jun 2010 10:37:02 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50A9EDDA1@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <201006041647.o54Gl4iH024692@fs4113.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
Thread-Index: AcsEBZvnPDt2HUJqS8akuD/yXHR9UgAA1w/g
References: <4C092737.2060604@pobox.com> from "Michael D'Errico" at Jun 4, 10 09:17:59 am <201006041647.o54Gl4iH024692@fs4113.wdf.sap.corp>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: <mrex@sap.com>, "Michael D'Errico" <mike-list@pobox.com>
X-OriginalArrivalTime: 04 Jun 2010 17:37:03.0556 (UTC) FILETIME=[8B6E2040:01CB040C]
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
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:37:19 -0000

The discussion in 5246 indicates that the warning messages are
unpredictable.  I don't think we can solve this problem in this document
so we wither discourage the warning in this case or we just explain the
unpredictability.  Below are two proposed text change to paragraph after
the structure definition in section 3 in draft-ietf-tls-rfc4366-bis-08.
Let me know which you prefer soon as we need to get this document
finished, because other documents are waiting on it.  

Thanks,

Joe

(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.  If the
server decides to continue the  handshake, sending a
unrecognized_name(112) alert with a warning level is NOT RECOMMENDED,
since the  client behavior is unpredictable.  Some clients respond by
aborting the handshake while others allow it  to continue to certificate
validation, which may fail as a result of a name mismatch. "

or

(2) "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 any of the server names, it SHOULD send an
unrecognized_name(112) alert (which MAY be fatal). Sending an
unrecognized_name(112) alert with a warning level will lead to
unpredictable behavior as some clients respond by aborting the handshake
while others allow it to continue to certificate validation, which may
fail as a result of a name mismatch."



> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> Martin Rex
> Sent: Friday, June 04, 2010 9:47 AM
> To: Michael D'Errico
> Cc: tls@ietf.org
> Subject: Re: [TLS] RFC-4366-bis and the unrecognized_name(112) alert
> 
> Michael D'Errico wrote:
> >
> > I would like to see text that says a peer SHOULD ignore warning
alerts
> > that it doesn't otherwise handle.  Clearly the peer that sent the
alert
> > with a warning level doesn't think it's a showstopper -- if it was a
> > problem, the alert level would have been fatal.
> >
> > Peers that escalate a warning to fatal are not playing nice; they
are
> > causing other software to abandon the practice of sending warnings
even
> > though they could prove useful.  Just because you can't imagine why
a
> > warning alert would be useful, today, doesn't mean that a use will
never
> > be found for it.
> 
> I think we are talking past each other.
> 
> I do not have any problems with the existence of warning level alerts.
> 
> 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.  In most cases, a warning-level alert
> indicates that something unusal happend on the last protocol
> exchange, and there is no means _within_ the TLS handshake to resend
> a previous handshake message with different properties -- which means
> that we will may have to specify application/API semantics.
> 
> For the warning-level unrecognized_name alert, I believe we have to
> specify
> application/API semantics for the receiver.
> 
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls