Re: [TLS] interop for TLS clients proposing TLSv1.1

Bill Frantz <frantz@pwpconsult.com> Mon, 26 September 2011 23:29 UTC

Return-Path: <frantz@pwpconsult.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF4921F8DDE for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 16:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9wI2AXk2PCZ for <tls@ietfa.amsl.com>; Mon, 26 Sep 2011 16:29:57 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2978821F8DDB for <tls@ietf.org>; Mon, 26 Sep 2011 16:29:56 -0700 (PDT)
Received: from [173.75.83.49] (helo=Bill-Frantzs-MacBook-Pro.local) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <frantz@pwpconsult.com>) id 1R8Kf7-0000dX-Hv; Mon, 26 Sep 2011 19:32:37 -0400
Date: Mon, 26 Sep 2011 16:32:37 -0700
From: Bill Frantz <frantz@pwpconsult.com>
To: "Yngve N. Pettersen" <yngve@opera.com>
X-Priority: 3
In-Reply-To: <op.v2fuq8d4kvaitl@lessa-ii>
Message-ID: <r422Ps-1068i-BDA7EE4404A24A818F407021587398EE@Bill-Frantzs-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79b5c79f028f5e8728aeaf9483e5383f70350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.49
Cc: tls@ietf.org
Subject: Re: [TLS] interop for TLS clients proposing TLSv1.1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Mon, 26 Sep 2011 23:29:59 -0000

I would add on this topic:

Browsers should refuse to display their highest security UI 
indicators if they negotiate a version of TLS with known flaws.

This suggestion would apply to SSL3/TLS0 today.

Since modern browsers are either automatically updated (Chrome) 
or updated regularly with automatic checking mechanisms (Safari, 
Firefox, Explorer) this policy can be quite dynamic. 
Organizations which buy high-security certificates will have a 
strong incentive to upgrade their servers. Other users, perhaps  
e-commerce sites using credit cards, do not need as high a 
quality of security and can be a bit behind on the security 
update treadmill.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle
(408)356-8506      | to C's continuing support of | 16345 
Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, 
CA 95032