Re: [TLS] Root certificates in server certificate chains

"Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu> Wed, 01 September 2010 02:14 UTC

Return-Path: <prvs=68602c451d=uri@ll.mit.edu>
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 CDBD13A6859 for <tls@core3.amsl.com>; Tue, 31 Aug 2010 19:14:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.207
X-Spam-Level:
X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.391, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 S1ChDJRaw7yc for <tls@core3.amsl.com>; Tue, 31 Aug 2010 19:14:55 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by core3.amsl.com (Postfix) with ESMTP id DBD743A6A01 for <tls@ietf.org>; Tue, 31 Aug 2010 19:14:54 -0700 (PDT)
Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id o812FL9E008551; Tue, 31 Aug 2010 22:15:21 -0400
From: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
To: "'marsh@extendedsubset.com'" <marsh@extendedsubset.com>
Date: Tue, 31 Aug 2010 22:15:23 -0400
Thread-Topic: [TLS] Root certificates in server certificate chains
Thread-Index: ActJeUgCSn/zi0mrTzyPgQ0RBsW20wAAibw6
In-Reply-To: <4C7DB2E5.6030307@extendedsubset.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011, 1.0.148, 0.0.0000 definitions=2010-09-01_01:2010-09-01, 2010-09-01, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-1005130000 definitions=main-1008310181
Message-Id: <20100901021454.DBD743A6A01@core3.amsl.com>
Cc: "'tls@ietf.org'" <tls@ietf.org>
Subject: Re: [TLS] Root certificates in server certificate chains
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: Wed, 01 Sep 2010 02:14:57 -0000

Sending root cert makes sense for Trust model based on computed probabilities - which does not exist today except in research papers.

The idea is - you verify as much as practical, and decide how much you trust the requester regarding his request.

E.g. consider two questions: "can I use your phone?" and "can I use your car?"
 
Oh, and the current trust model has little room for root cert as a part of the transmitted chain. Although - a home-grown CA, a bunch of pals establishing a  TLS-protected Web chat site...? No need to get VeriSign involved... Why not? 

--
Regards,
Uri

----- Original Message -----
From: Marsh Ray [mailto:marsh@extendedsubset.com]
Sent: Tuesday, August 31, 2010 09:56 PM
To: Matt McCutchen <matt@mattmccutchen.net>
Cc: 1.41421@gmail.com <1.41421@gmail.com>; tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Root certificates in server certificate chains

On 08/31/2010 07:09 PM, Matt McCutchen wrote:
> The following is my understanding.  Others should feel free to disagree
> or correct me.
>
> On Tue, 2010-08-31 at 22:30 +0000, 1.41421@gmail.com wrote:
>> The standard (RFC 5246, sec. 7.4.2) says that a server certificate
>> chain may include, as the last entry in this chain, the root
>> certificate that is to be considered the ultimate trust anchor as far
>> the server certificate is concerned. What would prevent an attacker
>> from inserting a Certificate message of its own during the handshake,
>> containing a totally bogus root certificate?
>
> Like any other tampering with the handshake, this would cause the
> Finished check to fail.

Not if the attacker is successful in getting the client to accept his 
proposed root certificate.

>> Actually, doesn't this render the whole idea of authentication of the
>> remote useless?

Sure, if the client is willing to accept it.

>> How can one make sure that a root certificate received
>> in a certificate chain is genuine?

Perhaps the client already trusts that root cert or key? If so, why even 
bother to send it?

>> But, in this case, why allow the server to include a root certificate
>> in the certificate chain in the first place?
>
> Perhaps as a hint to clients that might decide they wish to add that
> certificate as a trust anchor, possibly after further research?

To make it easier for users to "Permanently store this exception"?  :-P

- Marsh
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls