IETF Logo Mail Archive

Re: [TLS] Quest for Unified Solution to TLS Renegotiation

Martin Rex <mrex@sap.com> Thu, 26 November 2009 18:53 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 5CB373A6930 for <tls@core3.amsl.com>; Thu, 26 Nov 2009 10:53:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.185
X-Spam-Level:
X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 37yXjvnYHkQg for <tls@core3.amsl.com>; Thu, 26 Nov 2009 10:53:34 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 61BA53A6801 for <tls@ietf.org>; Thu, 26 Nov 2009 10:53:34 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAQIrRm6014370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 19:53:27 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911261853.nAQIrRjP018552@fs4113.wdf.sap.corp>
To: mike-list@pobox.com
Date: Thu, 26 Nov 2009 19:53:27 +0100
In-Reply-To: <4B0ECAC0.6080609@pobox.com> from "Michael D'Errico" at Nov 26, 9 10:36:48 am
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] Quest for Unified Solution to TLS Renegotiation
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: Thu, 26 Nov 2009 18:53:35 -0000

Michael D'Errico wrote:
> 
> David-Sarah Hopwood wrote:
> > 
> > The TLS spec doesn't seem to be very clear on whether handshake messages
> > with an unrecognized HandshakeType must cause an error (section 7.4).
> > Does anyone know what implementations actually do?
> 
> My code will send a fatal unexpected_message alert.  This seems
> like something that should be a MUST in the spec.

Well.  I remember that a few years back when ASN.1 parsers were
attacked with random garbage, there was something called "asn1brute.c"
that would blindly send a ClientHello directly by a crafted
Certificate message and a lot of Servers would choke on the
ASN.1 of the certificate, including those who had not even
requested a client certificate with CertificateRequest.

There may be some unexpected slack in what kind of handshake
messages individual TLS implementations might process or
even accept in specific situations, where the protocol
doesn't define them to be valid.

An attitude "the finished message will split the good guys from
the bad ones" would not be advisable.

-Martin

v2.23.0 | Report a Bug | By Email