[websec] Issue #42

Yoav Nir <ynir@checkpoint.com> Mon, 26 March 2012 15:30 UTC

Return-Path: <ynir@checkpoint.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 BE7A821E80BB for <websec@ietfa.amsl.com>; Mon, 26 Mar 2012 08:30:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.493
X-Spam-Level:
X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 jgBp9xdxT+07 for <websec@ietfa.amsl.com>; Mon, 26 Mar 2012 08:30:19 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB7721E80CF for <websec@ietf.org>; Mon, 26 Mar 2012 08:30:14 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q2QFU9BU002270 for <websec@ietf.org>; Mon, 26 Mar 2012 17:30:10 +0200
X-CheckPoint: {4F708AB4-1-1B221DC2-5FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 26 Mar 2012 17:30:09 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: "websec@ietf.org WG" <websec@ietf.org>
Date: Mon, 26 Mar 2012 17:30:08 +0200
Thread-Topic: Issue #42
Thread-Index: Ac0LZVP2jkXoBiRgQGSqdUNO4CAVXw==
Message-ID: <A4D79279-FFE2-4BA7-92D9-76CB9DD65AC4@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [websec] Issue #42
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: Mon, 26 Mar 2012 15:30:20 -0000

Hi

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.

Yoav