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

Bodo Moeller <bmoeller@acm.org> Sun, 15 November 2009 20:30 UTC

Return-Path: <bmoeller@acm.org>
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 B28AE3A6816 for <tls@core3.amsl.com>; Sun, 15 Nov 2009 12:30:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.575
X-Spam-Level:
X-Spam-Status: No, score=-100.575 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
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 1jTeVo7rosyT for <tls@core3.amsl.com>; Sun, 15 Nov 2009 12:30:54 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by core3.amsl.com (Postfix) with ESMTP id C26F43A6849 for <tls@ietf.org>; Sun, 15 Nov 2009 12:30:53 -0800 (PST)
Received: from [10.1.64.105] (216-239-44-65.google.com [216.239.44.65]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MWvfk-1NfZnR0Yzc-00W5gf; Sun, 15 Nov 2009 21:30:50 +0100
From: Bodo Moeller <bmoeller@acm.org>
To: Marsh Ray <marsh@extendedsubset.com>
In-Reply-To: <4B0062EA.8060906@extendedsubset.com>
References: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com> <3494BBB0-E80A-4CCA-92EF-A7EC794BEF9D@acm.org> <4B005E54.6030600@extendedsubset.com> <FD7FB19E-2A6B-48FA-9DAD-D0C4835C22EF@acm.org> <4B0062EA.8060906@extendedsubset.com>
Message-Id: <1F698852-2C4B-4F21-8B4F-0D6CFA6BB41E@acm.org>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 15 Nov 2009 12:30:46 -0800
X-Mailer: Apple Mail (2.936)
X-Provags-ID: V01U2FsdGVkX19uUw4G+C1R27j6fINXJOOvk2c1AdI6zdpUZbw yvVEZIjGIb5IT1sq32+W5gOQyeSlUjP6DFn+iVO7PSFqtSrXwg HmGYWQEEqwzOAWp0abnOA==
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego
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 20:30:54 -0000

On Nov 15, 2009, at 12:22 PM, 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.

How would they do that?  Everything is supposed to be encrypted then.


> It may be that we need two bits: 'endpoint patched' and 'endpoint
> configured secure'.

I don't think the protocol should too much be designed around making  
monitoring systems happy.  You can't do this for all interesting  
issues that client or server implementations might have anyway.  Here  
we have a vulnerability that's easy to fix in such a way that  
monitoring systems can see some fix deployment information, so why  
not.  Adding extra flags just for monitoring's sake, I'm not so sure.

Bodo