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

Marsh Ray <marsh@extendedsubset.com> Sun, 15 November 2009 21:04 UTC

Return-Path: <marsh@extendedsubset.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 66DB03A692D for <tls@core3.amsl.com>; Sun, 15 Nov 2009 13:04:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.685
X-Spam-Level:
X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.914, BAYES_00=-2.599]
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 2owHs0vsW0dK for <tls@core3.amsl.com>; Sun, 15 Nov 2009 13:04:44 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id A879F3A68D9 for <tls@ietf.org>; Sun, 15 Nov 2009 13:04:44 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1N9mH5-000D3h-QE; Sun, 15 Nov 2009 21:04:43 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C2607667C; Sun, 15 Nov 2009 21:04:41 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX19RW21QVImiKbUEZ3jwDJReG9hUfu1EquY=
Message-ID: <4B006CE7.9050804@extendedsubset.com>
Date: Sun, 15 Nov 2009 15:04:39 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mrex@sap.com
References: <200911152043.nAFKhAbD020309@fs4113.wdf.sap.corp>
In-Reply-To: <200911152043.nAFKhAbD020309@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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
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 21:04:45 -0000

Martin Rex wrote:
> 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).

Good point. The info may be available without the need to be stated
explicitly. But only after an insecure handshake gets underway.

> 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.

We're dealing with something that's already outside of the original
design, so we can't afford to be too principled. These protocol bits
have to satisfy the installed base.

Is it all that different than sending GMT instead of random data?

- Marsh