From nobody Fri Dec 5 08:43:39 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BFD1AD041; Fri, 5 Dec 2014 08:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beeU6Es0wsNS; Fri, 5 Dec 2014 08:43:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2DC1A1B7D; Fri, 5 Dec 2014 08:43:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3C969BF0A; Fri, 5 Dec 2014 16:43:19 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmXYFvKbK2O3; Fri, 5 Dec 2014 16:43:19 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1819FBF06; Fri, 5 Dec 2014 16:43:19 +0000 (GMT) Message-ID: <5481E0A7.2090604@cs.tcd.ie> Date: Fri, 05 Dec 2014 16:43:19 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: "saag@ietf.org" , websec , "uta@ietf.org" , "ietf-http-wg@w3.org Group" , "http-auth@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/BluUg13PK39XvrRJ5Vfh_TO79-8 Subject: [websec] unbearable - new mailing list to discuss better than bearer tokens... X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Stephen Farrell List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 16:43:33 -0000 Hiya, Following up on the presentation at IETF-91 on this topic, [1] we've created a new list [2] for moving that along. The list description is: "This list is for discussion of proposals for doing better than bearer tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks." If you're interested please join in. Thanks to Vinod and Andrei for agreeing to admin the list. We'll kick off discussion in a few days when folks have had a chance to subscribe. Cheers, S. PS: Please don't reply-all to this, join the new list, wait a few days and then say what you need to say:-) [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf [2] https://www.ietf.org/mailman/listinfo/unbearable From nobody Wed Dec 17 06:26:54 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8321A8A8B for ; Wed, 17 Dec 2014 05:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1Ytn4tJ_3X1 for ; Wed, 17 Dec 2014 05:57:31 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2D51A1AA4 for ; Wed, 17 Dec 2014 05:57:31 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id B733A280285; Wed, 17 Dec 2014 14:57:29 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id B1359280151; Wed, 17 Dec 2014 14:57:29 +0100 (CET) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id AE53C4C007C; Wed, 17 Dec 2014 14:56:59 +0100 (CET) Date: Wed, 17 Dec 2014 14:56:59 +0100 From: Stephane Bortzmeyer To: websec@ietf.org, Jeff.Hodges@PayPal.com, collin.jackson@sv.cmu.edu, ietf@adambarth.com Message-ID: <20141217135659.GA4781@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 8.0 X-Kernel: Linux 3.16.0-4-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/2xzc5RlpZIpC90zdR0YCZezWS_o X-Mailman-Approved-At: Wed, 17 Dec 2014 06:26:43 -0800 Cc: bortzmeyer@nic.fr Subject: [websec] [HSTS] Contradiction between sections 8.1 and 11.3 of RFC 6797? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 13:57:33 -0000 [I'm not subscribed to the websec working group so please copy me when replying.] I don't know how to read section 11.3 of RFC 6797. It says "If all four of the following conditions are true... [self-signed certificates...] ...then secure connections to that site will fail, per the HSTS design." It seems to imply that adding a Strict-Transport-Security: header to a site which has a self-signed certificate is an error. But section 8.1 says that the Strict-Transport-Security: will be ignored if the HTTPS session is not secured (for instance because the client uses a self-signed cert, section 8.1 says the header will be accepted only "if there are no underlying secure transport errors or warnings"). So, it seems that adding Strict-Transport-Security: is useless (they will be ignored, per section 8.1) but not an error. I checked with the Chromium browser "Version 20.0.1132.47 Ubuntu 12.04 (144678)" and a HTTPS site signed by CAcert.org (unknown CA for most browsers) and, indeed, Chromium ignores the HSTS header and accepts to use HTTP. Once CAcert.org cert is added, Chromium accepts the HSTS header and uses only HTTPS. So, it seems the Chromium programmers decided to ignore section 11.3? From nobody Wed Dec 17 11:51:16 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D56F1A8AF5 for ; Wed, 17 Dec 2014 11:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szzC88U5f9n7 for ; Wed, 17 Dec 2014 11:51:11 -0800 (PST) Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE5DC1A8A9A for ; Wed, 17 Dec 2014 11:51:11 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id v10so16863648pde.29 for ; Wed, 17 Dec 2014 11:51:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=f4ZxTYmqbDlAg1ElfKQNedMMuZyXflecH1E5VJU3Fd4=; b=hVnApI4QmhO74/4O7q18pWXUlwq+PoUqQdBJ7IKZq4He/m3Q4RR9fSJzSAcXtXh7/R KD9qIvOxxmkB7MsLEFM14i7To5BUYvt1dGprxBwoVYI2HvLW9bqiNnBqTZpZ4MypECc0 dlr4g6pmwIHf25+I3ksT2ID2J+nsrCBeBlHDj76AbT8JtEUBtIf6Skr+CpyPXel0kfd9 Kv/Q3LNb4FYWrB38HaRh/KJMGWq9V84ZdMEMvc1hSvuyiNDdUqh2S/WDll9uypvHjgxb RUaKXWuLOeN4ed/h2/scjQF+8dXDNshFuwRPDfxOrG9vr0sDA1LYi5U2x2zRbJnJEAb4 59fw== X-Gm-Message-State: ALoCoQmt5pCGkil5aPRzqusKTki4/QqJe0eYtCNzZ0COD8tc8r9j7VsREK6Wlp/4U3+b0yb/lk5u X-Received: by 10.70.37.35 with SMTP id v3mr72875184pdj.4.1418845871277; Wed, 17 Dec 2014 11:51:11 -0800 (PST) Received: from [10.248.28.41] ([207.126.102.129]) by mx.google.com with ESMTPSA id ye3sm4597071pbb.93.2014.12.17.11.51.09 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Dec 2014 11:51:10 -0800 (PST) Message-ID: <5491DEAC.8040706@mozilla.com> Date: Wed, 17 Dec 2014 11:51:08 -0800 From: David Keeler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Stephane Bortzmeyer , websec@ietf.org, Jeff.Hodges@PayPal.com, collin.jackson@sv.cmu.edu, ietf@adambarth.com References: <20141217135659.GA4781@nic.fr> In-Reply-To: <20141217135659.GA4781@nic.fr> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/Bfp5GiBf6esFQ8TxFSM5rkZ6PPo Subject: Re: [websec] [HSTS] Contradiction between sections 8.1 and 11.3 of RFC 6797? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 19:51:14 -0000 Hi Stephane, Here's how I look at it: Section 8.1 is about a user agent noting a new HSTS host. If the connection had an underlying error (e.g. self-signed cert), the user agent will not note that host as using HSTS. Section 11.3 is about when the user agent connects to a host that it previously noted as using HSTS. If there are underlying transport errors, the user agent will not allow the connection to continue under any circumstances (e.g. certificate exception overrides are disabled). Hope this helps, David On 12/17/2014 05:56 AM, Stephane Bortzmeyer wrote: > > [I'm not subscribed to the websec working group so please copy me when > replying.] > > I don't know how to read section 11.3 of RFC 6797. It says "If all > four of the following conditions are true... [self-signed > certificates...] ...then secure connections to that site will fail, > per the HSTS design." It seems to imply that adding a > Strict-Transport-Security: header to a site which has a self-signed > certificate is an error. > > But section 8.1 says that the Strict-Transport-Security: will be > ignored if the HTTPS session is not secured (for instance because the > client uses a self-signed cert, section 8.1 says the header will be > accepted only "if there are no underlying secure transport errors or > warnings"). So, it seems that adding Strict-Transport-Security: is > useless (they will be ignored, per section 8.1) but not an error. > > I checked with the Chromium browser "Version 20.0.1132.47 Ubuntu 12.04 > (144678)" and a HTTPS site signed by CAcert.org (unknown CA for most > browsers) and, indeed, Chromium ignores the HSTS header and accepts to > use HTTP. Once CAcert.org cert is added, Chromium accepts the HSTS > header and uses only HTTPS. So, it seems the Chromium programmers > decided to ignore section 11.3? > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > From nobody Thu Dec 25 06:04:14 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F52B1A8780 for ; Wed, 17 Dec 2014 12:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ur78oXmWzzxl for ; Wed, 17 Dec 2014 12:43:48 -0800 (PST) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [IPv6:2001:4b98:dc0:41:216:3eff:fece:1902]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142A51A8799 for ; Wed, 17 Dec 2014 12:43:48 -0800 (PST) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 3B9B03B993; Wed, 17 Dec 2014 21:43:46 +0100 (CET) Received: by tyrion (Postfix, from userid 1000) id 1F6D5F00A31; Wed, 17 Dec 2014 21:38:37 +0100 (CET) Date: Wed, 17 Dec 2014 21:38:37 +0100 From: Stephane Bortzmeyer To: David Keeler Message-ID: <20141217203836.GA10001@laperouse.bortzmeyer.org> References: <20141217135659.GA4781@nic.fr> <5491DEAC.8040706@mozilla.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5491DEAC.8040706@mozilla.com> X-Transport: UUCP rules X-Operating-System: Ubuntu 14.04 (trusty) User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/websec/W6HZHof4QP3a2yE5PdqvgsfrjWc X-Mailman-Approved-At: Thu, 25 Dec 2014 06:04:12 -0800 Cc: collin.jackson@sv.cmu.edu, websec@ietf.org, Stephane Bortzmeyer Subject: Re: [websec] [HSTS] Contradiction between sections 8.1 and 11.3 of RFC 6797? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 20:43:52 -0000 On Wed, Dec 17, 2014 at 11:51:08AM -0800, David Keeler wrote a message of 47 lines which said: > Section 11.3 is about when the user agent connects to a host that it > previously noted as using HSTS. OK, so a example case with section 11.3 could be a server publishing a HSTS header while it has a recognized certificate and then later switching to a self-signed certificate. In that case, access would be denied. Am I correct? From nobody Tue Dec 30 13:24:12 2014 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A721A8746 for ; Tue, 30 Dec 2014 13:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD_OONzwiMyE for ; Tue, 30 Dec 2014 13:24:07 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C35721A873D for ; Tue, 30 Dec 2014 13:24:07 -0800 (PST) Received: from [10.70.10.88] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 9E08DF984; Tue, 30 Dec 2014 16:24:03 -0500 (EST) Message-ID: <54A317F0.5030706@fifthhorseman.net> Date: Tue, 30 Dec 2014 16:24:00 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Icedove/34.0 MIME-Version: 1.0 To: Stephane Bortzmeyer , David Keeler References: <20141217135659.GA4781@nic.fr> <5491DEAC.8040706@mozilla.com> <20141217203836.GA10001@laperouse.bortzmeyer.org> In-Reply-To: <20141217203836.GA10001@laperouse.bortzmeyer.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/websec/BlNiaAU3ccm_kQa30KmDCnp2DbA Cc: collin.jackson@sv.cmu.edu, websec@ietf.org Subject: Re: [websec] [HSTS] Contradiction between sections 8.1 and 11.3 of RFC 6797? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 21:24:09 -0000 On 12/17/2014 03:38 PM, Stephane Bortzmeyer wrote: > On Wed, Dec 17, 2014 at 11:51:08AM -0800, > David Keeler wrote > a message of 47 lines which said: > >> Section 11.3 is about when the user agent connects to a host that it >> previously noted as using HSTS. > > OK, so a example case with section 11.3 could be a server publishing a > HSTS header while it has a recognized certificate and then later > switching to a self-signed certificate. In that case, access would be > denied. Am I correct? Yes, this is a known consequence of using HSTS. --dkg