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

Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 16 June 2012 19:19 UTC

Return-Path: <tobias.gondrom@gondrom.org>
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 8CB2E21F851C for <websec@ietfa.amsl.com>; Sat, 16 Jun 2012 12:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.759
X-Spam-Level:
X-Spam-Status: No, score=-100.759 tagged_above=-999 required=5 tests=[AWL=-5.840, BAYES_20=-0.74, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 XvCaPC-hfHtH for <websec@ietfa.amsl.com>; Sat, 16 Jun 2012 12:19:19 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 3E93421F851A for <websec@ietf.org>; Sat, 16 Jun 2012 12:19:19 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=UPaWUpe73ipMwFieGig/xTpiW3D7VcO9dTpsEUuWiUpwOmvhOZZkC70i+jkiAMphcXY/ijjF6G2jrsKAy8R9ZaBUxkiUgy7opmFKH7sHB30yaQnXLl8GkSyDuILYYp6g; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Received: (qmail 28024 invoked from network); 16 Jun 2012 21:19:10 +0200
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.71?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Jun 2012 21:19:10 +0200
Message-ID: <4FDCDC2D.5070606@gondrom.org>
Date: Sat, 16 Jun 2012 20:19:09 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: websec@ietf.org
References: <4FDA8AA4.5060205@KingsMountain.com>
In-Reply-To: <4FDA8AA4.5060205@KingsMountain.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Sat, 16 Jun 2012 19:19:20 -0000

<hat="individual">
+1. I would agree with Jeff on that.
(Mostly because I see no other good solution.)
Any other comments/ideas on this one?

Best regards, Tobias

On 15/06/12 02:06, =JeffH wrote:
> > 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
>
> _______________________________________________
> websec mailing list
> websec@ietf.org
> https://www.ietf.org/mailman/listinfo/websec