Re: [websec] #42: STS exception for CRL fetching

=JeffH <Jeff.Hodges@KingsMountain.com> Fri, 15 June 2012 01:06 UTC

Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561B021F847F for <websec@ietfa.amsl.com>; Thu, 14 Jun 2012 18:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.081
X-Spam-Level:
X-Spam-Status: No, score=-98.081 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 zwZqftZc11Gl for <websec@ietfa.amsl.com>; Thu, 14 Jun 2012 18:06:47 -0700 (PDT)
Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 5B34121F847C for <websec@ietf.org>; Thu, 14 Jun 2012 18:06:47 -0700 (PDT)
Received: (qmail 32017 invoked by uid 0); 15 Jun 2012 01:06:46 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 15 Jun 2012 01:06:46 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=9D34MOr02shvmckerP6MJoCVZApCM6Ksy3rkF9QKLA4=; b=rdcZ6+8Zeju1Nsv+82zqGAh5EwUbzUuJwBoHM4Kq3Dxbif1BSVod5rY5XUAkZrWTR/5qLffi5pDF+Yf4Bjkb659TOKKt9RgEE6CuFYTTrIeKlweuzIYYsbPMWdhTLg46;
Received: from [24.4.122.173] (port=38945 helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1SfKzu-00054b-5L; Thu, 14 Jun 2012 19:06:46 -0600
Message-ID: <4FDA8AA4.5060205@KingsMountain.com>
Date: Thu, 14 Jun 2012 18:06:44 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com}
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] #42: STS exception for CRL fetching
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jun 2012 01:06:48 -0000

 > This is about fetching CRLs from a domain that happens to be the same as
 > that of a website.
 >
 > Obviously you can't get a CRL or an OCSP response over HTTPS. Jeff's
 > response was that they should use a different domain name for the CRLs (if
 > they want to deploy HSTS)
 >
 > Obviously, it's too late to change AIA or CDP in existing certificates. But
 > I think it goes deeper. HSTS affects what the browser is doing. Different
 > resources from the same domain should all be protected by TLS. But we don't
 > expect this to affect things that are outside the browser, like email or
 > system updates. IMO the fetching of CRLs or OCSP responses is not part of
 > the browsing, but part of the HTTPS handshake. The fact that some browsers
 > implement both is besides the point. Internet Explorer uses an OS library to
 > do the TLS handshake, including any checking of revocation. In fact getting
 > the CRL fetch function to apply the HSTS policy would require extra effort
 > from the browser implementer.
 >
 > I think we should simply say that HSTS does not apply to non-content.
 > Fetching CRLs or browser software updates is not content, and HSTS should
 > not apply to it.

Unfortunately, we would then have to define what comprises "content", and 
that's a huge rathole I think we should unequivocally avoid.

I've taken a (ad-hoc, limited, unscientific) look at the AIA and CDP in some 
existing certificates (from major CAs), and all of the ones I checked used a 
dedicated subdomain for their OCSP responder, e.g...

   evsecure-crl.verisign.com
   evsecure-ocsp.verisign.com
   SVRSecure-G3-crl.verisign.com
   ocsp.verisign.com
   ocsp.thawte.com
   crl.thawte.com


So in order not to cause themselves and their customers problems, CAs simply 
shouldn't issue HSTS policy with "includsubdomains" from their top-level domain 
name, and they will be fine. This is already discussed in S 10.3 of the HSTS 
draft.

HTH,

=JeffH