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

Martin Rex <mrex@sap.com> Tue, 08 June 2010 13:28 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 E10F928C1AE for <tls@core3.amsl.com>; Tue, 8 Jun 2010 06:28:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.723
X-Spam-Level:
X-Spam-Status: No, score=-7.723 tagged_above=-999 required=5 tests=[AWL=-0.074, 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 zvGXHPuun0X2 for <tls@core3.amsl.com>; Tue, 8 Jun 2010 06:27:57 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 21B4928C193 for <tls@ietf.org>; Tue, 8 Jun 2010 06:27:56 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o58DRmsX006979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jun 2010 15:27:48 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006081327.o58DRkWD016953@fs4113.wdf.sap.corp>
To: pgut001@cs.auckland.ac.nz (Peter Gutmann)
Date: Tue, 8 Jun 2010 15:27:46 +0200 (MEST)
In-Reply-To: <E1OLpyn-0007OA-TL@wintermute02.cs.auckland.ac.nz> from "Peter Gutmann" at Jun 8, 10 03:59:57 pm
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: Tue, 08 Jun 2010 13:28:03 -0000

Peter Gutmann wrote:
> 
> Martin Rex <mrex@sap.com> writes:
> >
> > The IETF golden rule for protocol applies here
> > "be liberal in what you accept".
> 
> What people usually omit when they quote this is the footnote in the
> appendix to the apocrypha:
> 
> "... unless it's a security protocol".


That IMHO misses the point by a significant margin.

"be liberal in what you accept" was never meant in the sense
of being sloppy in performing validation of security-critical parameters.

As previously described here
  http://www.ietf.org/mail-archive/web/tls/current/msg06356.html
SSL-Alerts during the TLS handshake are _not_ protected by the
TLS handshake message hash that is authenticated with the finished
messages, so Alerts are purely optional protocol features that are
not security relevant and therefore the golden IETF rule applies
to them without restriction.

If we want to convey security-critical parameters in the TLS handshake
protocol, then it must either be part of regular handshake messages
or otherwise get covered by the protection of the handshake message
hash and/or finished message calculations.


>
> > If there are protocol elements that convey information between to
> > communication peers, then the semantics of that piece of information
> > must be well-defined for both, sender and receipient.
> 
> ... unless the protocol is IPsec, OCSP, CMP, TSP, portions of SSH, uhh...
> what else is there... well, in any case I think I've made my point.

I do not understand what you mean.

In security protocols it is much more important to specify the exact
semantics of all security-critical parameters for both, sender and
recipient, otherwise this will result in interop problems, because
being sloppy about checking security-critical parameter values is
_not_ an option.

Did you want to assert that the mentioned protocols contain a lot of
underspecified security-critical parameters?

-Martin