Re: [TLS] assert TLSext in renego-ServerHello instead of disable

Martin Rex <mrex@sap.com> Sun, 15 November 2009 20:43 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 8A2803A68BD for <tls@core3.amsl.com>; Sun, 15 Nov 2009 12:43:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.413
X-Spam-Level:
X-Spam-Status: No, score=-5.413 tagged_above=-999 required=5 tests=[AWL=0.836, 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 viB1J+lcCv4W for <tls@core3.amsl.com>; Sun, 15 Nov 2009 12:43:14 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 944703A68B6 for <tls@ietf.org>; Sun, 15 Nov 2009 12:43:14 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nAFKhA5g020194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 21:43:10 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911152043.nAFKhAbD020309@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Sun, 15 Nov 2009 21:43:10 +0100
In-Reply-To: <4B0062EA.8060906@extendedsubset.com> from "Marsh Ray" at Nov 15, 9 02:22:02 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable
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: Sun, 15 Nov 2009 20:43:15 -0000

Marsh Ray wrote:
> 
> Bodo Moeller wrote:
> >
> > Arguably I'd rather have monitoring tell me about clients that will
> > *tolerate* a handshake with a server that doesn't support the extension
> > (not so much about clients that don't support the extension at all).  In
> > that case, I wouldn't want these clients to send the extension on the
> > initial handshake.
> 
> Good point.
> 
> These systems will probably spot unsafe renegotiations happening.
> 
> It may be that we need two bits: 'endpoint patched' and 'endpoint
> configured secure'.

Do you really need more?

If you see the client's signal in the ClientHello that it is updated
and no signal for the new behaviour in the ServerHello, then you can
distinguish configured secure (Client closes network connection with
or without sending a fatal alert) from configured insecure (handshake
continues).

If your idea is about being able to "check" client's configuration on
_any_ TLS connection, that is not something that TLS is designed
(or supposed) to provide.

-Martin