Re: [secdir] [TLS] secdir review of

Robert Relyea <rrelyea@redhat.com> Fri, 24 September 2010 22:00 UTC

Return-Path: <rrelyea@redhat.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399603A6AA7; Fri, 24 Sep 2010 15:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.008
X-Spam-Level:
X-Spam-Status: No, score=-110.008 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, 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 cH79sicS8fHQ; Fri, 24 Sep 2010 15:00:17 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 169963A6A9C; Fri, 24 Sep 2010 15:00:16 -0700 (PDT)
Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o8OM0ihY007067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Sep 2010 18:00:44 -0400
Received: from [10.14.54.215] (dhcp-215.sjc.redhat.com [10.14.54.215]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o8OM0efJ003448; Fri, 24 Sep 2010 18:00:40 -0400
Message-ID: <4C9D1F8E.70608@REDHAT.COM>
Date: Fri, 24 Sep 2010 15:00:46 -0700
From: Robert Relyea <rrelyea@redhat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Thunderbird/3.0.5
MIME-Version: 1.0
To: mrex@sap.com
References: <201009242029.o8OKTqcc023470@fs4113.wdf.sap.corp>
In-Reply-To: <201009242029.o8OKTqcc023470@fs4113.wdf.sap.corp>
X-Enigmail-Version: 1.0.1
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070600000007040902010805"
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11
X-Mailman-Approved-At: Fri, 24 Sep 2010 18:36:44 -0700
Cc: tls@ietf.org, secdir@ietf.org, certid@ietf.org, iesg@ietf.org, Peter Saint-Andre <stpeter@stpeter.im>
Subject: Re: [secdir] [TLS] secdir review of
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Sep 2010 22:00:18 -0000

On 09/24/2010 01:29 PM, Martin Rex wrote:
> Peter Saint-Andre wrote:
>   
>> For context, the "quoted advice" is mostly a description of current
>> usage in some existing user agents. Incorporating Barry's suggestions,
>> that text currently reads as follows in our working copy:
>>
>>       Security Note: Some existing interactive user agents give advanced
>>       users the option of proceeding despite an identity mismatch.
>>       Although this behavior can be appropriate in certain specialized
>>       circumstances, in general it ought to be exposed only to advanced
>>       users and even then needs to be handled with extreme caution, for
>>       example by first encouraging even an advanced user to terminate
>>       the connection and, if the advanced user chooses to proceed
>>       anyway, by forcing the user to view the entire certification path
>>       and only then allowing the user to accept the certificate on a
>>       temporary basis (i.e., for this connection attempt and all
>>       subsequent connection attempts for the life of the application
>>       session, but not for connection attempts during future application
>>       sessions).
>>     
> This whole paragraph is evil and completely wrong.
>
> It's bad enough that the web browser crowds replaced a useful option
> and important security feature with an extremely evil scary page.
>   

No, this paragraph is exactly what should happen. Click through dialogs
are demonsterably useless. They train users to ignore them. The only
place for them is if you decide that validation is not necessary.
> Offering to end-users, in a single-time-only leap-of-faith approach similar
> to what SSH has been successfully doing since its invention to memorize
> the peers certificate is magnitudes more secure than the endpoint
> identification linking to one of a hundred trust anchors, provisionally
> preconfigured by your software supplier.
>   
SSH is good for small numbers of point to point connections where the
user controls both sides. SSH model is not appropriate for the general
population connection to millions of webservers. That is why SSH is used
extensively in admin deployments (where the admin controls both
machines) and is not used for e-commerce. If you want that semantic use
SSH. If you want security for the masses, use SSL (with full PKI).


[ case where SSL is being used for an SSH use case deleted]

bob