[websec] Issue that came up about HSTS
Yoav Nir <ynir@checkpoint.com> Sat, 27 October 2012 06:42 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 CC20D21F868F for <websec@ietfa.amsl.com>; Fri, 26 Oct 2012 23:42:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.588
X-Spam-Level:
X-Spam-Status: No, score=-10.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDn8byEuKI2C for <websec@ietfa.amsl.com>; Fri, 26 Oct 2012 23:42:51 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BFAD221F8625 for <websec@ietf.org>; Fri, 26 Oct 2012 23:42:50 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q9R6gmg4012692 for <websec@ietf.org>; Sat, 27 Oct 2012 08:42:48 +0200
X-CheckPoint: {508B8033-2-1B221DC2-2FFFF}
Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 27 Oct 2012 08:42:47 +0200
Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 27 Oct 2012 08:42:48 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: IETF WebSec WG <websec@ietf.org>
Date: Sat, 27 Oct 2012 08:42:47 +0200
Thread-Topic: Issue that came up about HSTS
Thread-Index: Ac20DkaD8zHkXAo/SM6CcAwX5Nsjzw==
Message-ID: <70C766B8-FBF5-4421-B6CE-BCE616FC023B@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
X-KSE-AntiSpam-Interceptor-Info: protection disabled
Subject: [websec] Issue that came up about HSTS
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, 27 Oct 2012 06:42:52 -0000
Hi all draft-ietf-websec-strict-transport-sec is now being edited by the RFC editor. An issue has come up. We need to resolve this quickly, so please read the following and reply to the list with your opinions. Section 8.4 begins as follows: 8.4. Errors in Secure Transport Establishment When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 12 "User Agent Implementation Advice") if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying secure transport. For example, this includes any errors found in certificate validity checking UAs employ such as via Certificate Revocation Lists (CRL) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC2560]. The list of example ways that the UA employs to validate certificates includes CRLs and OCSP. The authors believe that the list should be extended to also include a reference to the succinctly-named RFC 6125 ("Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"). See the below suggested text, the new stuff begins with "as well as" on the penultimate line. 8.4. Errors in Secure Transport Establishment When connecting to a Known HSTS Host, the UA MUST terminate the connection (see also Section 12 "User Agent Implementation Advice") if there are any errors, whether "warning" or "fatal" or any other error level, with the underlying secure transport. For example, this includes any errors found in certificate validity checking UAs employ such as via Certificate Revocation Lists (CRL) [RFC5280], or via the Online Certificate Status Protocol (OCSP) [RFC2560], as well as via server identity checking [RFC6125]. Note that this is not an additional Last Call. If nobody strongly objects to this addition, we will add it. We have already heard from Barry that this addition is fine, and will not require a new LC. Please respond soon, as the RFC editor is working on this document now. Thanks Yoav
- [websec] Issue that came up about HSTS Yoav Nir
- Re: [websec] Issue that came up about HSTS Paul Hoffman
- Re: [websec] Issue that came up about HSTS Steingruebl, Andy
- Re: [websec] Issue that came up about HSTS Yoav Nir