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

Alexey Melnikov <alexey.melnikov@isode.com> Sun, 17 June 2012 09:46 UTC

Return-Path: <alexey.melnikov@isode.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 2CC8B21F8622 for <websec@ietfa.amsl.com>; Sun, 17 Jun 2012 02:46:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.077
X-Spam-Level:
X-Spam-Status: No, score=-100.077 tagged_above=-999 required=5 tests=[AWL=-1.474, BAYES_50=0.001, MIME_QP_LONG_LINE=1.396, 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 kJK3wAbcxuY1 for <websec@ietfa.amsl.com>; Sun, 17 Jun 2012 02:46:36 -0700 (PDT)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7A521F861E for <websec@ietf.org>; Sun, 17 Jun 2012 02:46:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1339926393; d=isode.com; s=selector; i=@isode.com; bh=nNJCMTFZCWiLRN0jkPRpI7Vbhz5TxYzvhggoKNGKnG4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uSHlU6gFWSTnR7smjOpqhw6TNHcwzzH4LPsKhJShsnRtjj60Weor8LK99KFbKc4BiIaSkz c5nYLATqufQMVDEklsq2a5oVth3fC4gaazWnmvmYBG27A4sHkATaO76RjIGLstDUrgrqav tWP56ZmTvlRi9f7ACnYPWJTHC6A1hRg=;
Received: from [188.29.11.137] (188.29.11.137.threembb.co.uk [188.29.11.137]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <T92neAAHdUMY@statler.isode.com>; Sun, 17 Jun 2012 10:46:33 +0100
References: <4FDA8AA4.5060205@KingsMountain.com> <4FDCDC2D.5070606@gondrom.org>
In-Reply-To: <4FDCDC2D.5070606@gondrom.org>
Message-Id: <9B856474-7096-404D-8D32-94228AB82BCF@isode.com>
X-Mailer: iPad Mail (9B206)
From: Alexey Melnikov <alexey.melnikov@isode.com>
Date: Sun, 17 Jun 2012 10:46:27 +0100
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Cc: "websec@ietf.org" <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: Sun, 17 Jun 2012 09:46:37 -0000

On 16 Jun 2012, at 20:19, Tobias Gondrom <tobias.gondrom@gondrom.org>; wrote:

> <hat="individual">

Same here in this message.

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

I tend to think that "don't use this hammer if it doesn't suit you" is the best answer here. Exceptions are bad (hard to handle properly).

> 
> 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