From trac+websec@trac.tools.ietf.org Fri Jun 1 10:20:21 2012 Return-Path: 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 4AB1F21F89C9 for ; Fri, 1 Jun 2012 10:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cuYsvWsF1LFk for ; Fri, 1 Jun 2012 10:20:20 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B890621F89C7 for ; Fri, 1 Jun 2012 10:20:20 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SaVW4-0007SD-5s; Fri, 01 Jun 2012 13:20:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Fri, 01 Jun 2012 17:19:59 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/46 Message-ID: <070.4eddcfcdc5893029bfcf92fdbf76a8f2@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120601172020.B890621F89C7@ietfa.amsl.com> Resent-Date: Fri, 1 Jun 2012 10:20:20 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: [websec] #46: HSTS: AppsDir Editorial comments X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2012 17:20:21 -0000 #46: HSTS: AppsDir Editorial comments Editorial ("minor issues") noted in Murray Kucherawy's AppsDir review.. [websec] AppsDir review of draft-ietf-websec-strict-transport-sec https://www.ietf.org/mail-archive/web/websec/current/msg01147.html -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: minor | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: websec From Jeff.Hodges@KingsMountain.com Fri Jun 1 10:36:01 2012 Return-Path: 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 54FCA21F8A24 for ; Fri, 1 Jun 2012 10:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.495 X-Spam-Level: X-Spam-Status: No, score=-100.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 8jjiCMGVG6oZ for ; Fri, 1 Jun 2012 10:36:00 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 6A0CE21F8A22 for ; Fri, 1 Jun 2012 10:36:00 -0700 (PDT) Received: (qmail 21929 invoked by uid 0); 1 Jun 2012 17:35:59 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 1 Jun 2012 17:35:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=gSlQTVnh8NRk33qgWY9i8ii8hirfpA7QfnxCpTLIWFk=; b=JfITYWNBrwgXSCwgvgryqF2yaW76DBVioQMgSV+GuitK6YWI2HT4RaM0Ls8ehdh1s1vKA/mJSHYVSCh5XbKpbuMs3I8Vca4P0qKa4+Y6/U6xOax4muOIRo6TW2SZUpcJ; Received: from [216.113.168.128] (port=10492 helo=[10.244.136.116]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SaVlX-0006qt-Ce; Fri, 01 Jun 2012 11:35:59 -0600 Message-ID: <4FC8FD7F.3020200@KingsMountain.com> Date: Fri, 01 Jun 2012 10:35:59 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Apps Discuss , IETF WebSec WG , draft-ietf-websec-strict-transport-sec@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 17:36:01 -0000 Hi, thanks for your review Murray, apologies for latency. Nice to see you didn't find any major issues. The most major obvious item in this review, concerning ABNF in section 6, was discussed on the list -- and then I neglected to submit a bug for the overall review feedback (sorry). that's now done: HSTS: AppsDir Editorial comments http://trac.tools.ietf.org/wg/websec/trac/ticket/46 ..and I'm working on -09 to incorporate your feedback and will reply to your msg on-list. =JeffH From Jeff.Hodges@KingsMountain.com Fri Jun 1 11:32:10 2012 Return-Path: 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 8BB8511E80A0 for ; Fri, 1 Jun 2012 11:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.751 X-Spam-Level: X-Spam-Status: No, score=-99.751 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 EQQ-JY7vjjG1 for ; Fri, 1 Jun 2012 11:32:10 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id CB33111E8097 for ; Fri, 1 Jun 2012 11:32:09 -0700 (PDT) Received: (qmail 23341 invoked by uid 0); 1 Jun 2012 18:32:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 1 Jun 2012 18:32:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=kqir87jSuYeRe1YVZzAWgzR+Hv8EI9YZaaK9MiZBrDE=; b=CWHpz8n6oFXC40RAj8cy8CEpQHviQqnhP3RdNzN+cZpGU1KWGLq7S+D1zN9lWUw0txoGXDvRGsN2551Pd72SQ7fQTn5TgsFWThYtvEQ2fYLOqD1mJu8H0gVEmYE+fMt0; Received: from [216.113.168.128] (port=59136 helo=[10.244.136.116]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SaWdr-0000bB-14; Fri, 01 Jun 2012 12:32:07 -0600 Message-ID: <4FC90AA5.8090502@KingsMountain.com> Date: Fri, 01 Jun 2012 11:32:05 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] ignoring STS header fields with undefined directives (was: new rev: draft-ietf-websec-strict-transport-sec-08) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 18:32:10 -0000 > Most of my issues were addressed in the latest version, except for this one: > > > 6.1. Strict-Transport-Security HTTP Response Header Field > > > > 4. UAs MUST ignore any STS header fields containing directives, or > > other header field value data, that does not conform to the > > syntax defined in this specification. > > So this is saying that syntactically invalid STS header fields are > to be ignored. This still doesn't say if unrecognized directives are to > be ignored or not. (Because they can comply with the generic syntax for > directives, so they would be syntactically valid, albeit unrecognized). > So can you please add an explicit sentence about that? Here's the text in my working copy for that item.. UAs MUST ignore any STS header fields containing directives, or other header field value data, that does not conform to the syntax defined in this specification. UAs MUST also ignore any STS header fields containing undefined directives. Ok? thanks, =JeffH From julian.reschke@gmx.de Fri Jun 1 12:49:32 2012 Return-Path: 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 6350411E80E3 for ; Fri, 1 Jun 2012 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 MI6fdMLi47Yh for ; Fri, 1 Jun 2012 12:49:31 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6AA6C11E80E2 for ; Fri, 1 Jun 2012 12:49:31 -0700 (PDT) Received: (qmail invoked by alias); 01 Jun 2012 19:49:30 -0000 Received: from p54BB353B.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.53.59] by mail.gmx.net (mp069) with SMTP; 01 Jun 2012 21:49:30 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/7+yFasdr7z6xMPW4T6jcYS3phOEQ6l57bzOcf06 I+OaQbHDpuyu+v Message-ID: <4FC91CC9.8020409@gmx.de> Date: Fri, 01 Jun 2012 21:49:29 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =JeffH References: <4FC90AA5.8090502@KingsMountain.com> In-Reply-To: <4FC90AA5.8090502@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] ignoring STS header fields with undefined directives (was: new rev: draft-ietf-websec-strict-transport-sec-08) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 19:49:32 -0000 On 2012-06-01 20:32, =JeffH wrote: > > Most of my issues were addressed in the latest version, except for > this one: > > > > > 6.1. Strict-Transport-Security HTTP Response Header Field > > > > > > 4. UAs MUST ignore any STS header fields containing directives, or > > > other header field value data, that does not conform to the > > > syntax defined in this specification. > > > > So this is saying that syntactically invalid STS header fields are > > to be ignored. This still doesn't say if unrecognized directives are to > > be ignored or not. (Because they can comply with the generic syntax for > > directives, so they would be syntactically valid, albeit unrecognized). > > So can you please add an explicit sentence about that? > > > Here's the text in my working copy for that item.. > > > UAs MUST ignore any STS header fields containing > directives, or other header field value data, that does > not conform to the syntax defined in this specification. > UAs MUST also ignore any STS header fields containing > undefined directives. > > > Ok? > ... That makes it basically impossible to add extensions; is that intended? Best regards, Julian From alexey.melnikov@isode.com Fri Jun 1 13:33:41 2012 Return-Path: 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 53A2C11E80B0 for ; Fri, 1 Jun 2012 13:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.884 X-Spam-Level: X-Spam-Status: No, score=-102.884 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, 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 g-Y8iBhaIv91 for ; Fri, 1 Jun 2012 13:33:40 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 35AE211E8097 for ; Fri, 1 Jun 2012 13:33:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338582819; d=isode.com; s=selector; i=@isode.com; bh=jrzsCN1OFSfeEvnbaNr5oQPnlSjYO9LB9I99ctgOPJA=; 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=Y0eK3e1/LiUqFbXVdoJReL+GeAo3wBKY3os5TwZnME6m4JtlfsajlGNvPh9eZe0MqP6RtK MC8XzEE1YN6dKiIvL8boR4kp65sI2tnZeaQJT2OhpIBB9C2kalF1O8nArAmUwXdLVqh6Dm kS56w+RZaigkIlnWFXRB/sIBWe/jxtg=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 1 Jun 2012 21:33:39 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING Message-ID: <4FC92727.5000402@isode.com> Date: Fri, 01 Jun 2012 21:33:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: =JeffH References: <4FC90AA5.8090502@KingsMountain.com> In-Reply-To: <4FC90AA5.8090502@KingsMountain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] ignoring STS header fields with undefined directives (was: new rev: draft-ietf-websec-strict-transport-sec-08) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 20:33:41 -0000 On 01/06/2012 19:32, =JeffH wrote: > > Most of my issues were addressed in the latest version, except for > this one: > > > > > 6.1. Strict-Transport-Security HTTP Response Header Field > > > > > > 4. UAs MUST ignore any STS header fields containing directives, or > > > other header field value data, that does not conform to the > > > syntax defined in this specification. > > > > So this is saying that syntactically invalid STS header fields are > > to be ignored. This still doesn't say if unrecognized directives are to > > be ignored or not. (Because they can comply with the generic syntax for > > directives, so they would be syntactically valid, albeit unrecognized). > > So can you please add an explicit sentence about that? > > > Here's the text in my working copy for that item.. > > > UAs MUST ignore any STS header fields containing > directives, or other header field value data, that does > not conform to the syntax defined in this specification. > UAs MUST also ignore any STS header fields containing > undefined directives. > > > Ok? I agree with Julian: this will make the header field effectively non extensible. And if you update the header field by adding new values, all older implementations will start ignoring it, which is a deployment headache. But if the WG thinks that that is the way to go... From palmer@google.com Fri Jun 1 14:02:45 2012 Return-Path: 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 24E6F11E80E0 for ; Fri, 1 Jun 2012 14:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 MrQpc3Gbl6cm for ; Fri, 1 Jun 2012 14:02:44 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 19C0C11E8097 for ; Fri, 1 Jun 2012 14:02:43 -0700 (PDT) Received: by lagv3 with SMTP id v3so1983679lag.31 for ; Fri, 01 Jun 2012 14:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=8aKFVcCSBVN4/razCID6WuK3QVdUS0s4dlK7DBA8ezI=; b=DFDkIXFrnjqNKjHf5dKEtat/FyNik15bBZJV4ymZ9sOQqTorjwl3EXPPLj4u5fIn4/ /k7AoIy0j2fRjoBEn5gLawg8A2KPqRk+HYkpYv+uQLAboj0vTuefhO5fD+F+z1boYhBU fU8NPg04i8xIqk8OstXbGmmN5PpCGHn/1/vh3wHJFP7X1f+koM2UcC8/r0uS0mNV+9fr mjzmo7fapzHgQ80L0LOEP+105tQlP1v+Z+K/hVhils+jv26fbWZxyl1wvcbPcvroPl7q U4wj8SskDDH2KAT7RM57eKIDyXQ7dnnbDatDkMt36R2xKLRLTjh29dbvYuO+WPhLyG/y 1vhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=8aKFVcCSBVN4/razCID6WuK3QVdUS0s4dlK7DBA8ezI=; b=iQLZ6OJfpg1vbWseXAeQwhyydQrCaBSmkU1EEl7OaOMxDBZzDqsUCstKsPIkjP8d28 WY3cGLyeJY/Th7OuRaJliLpl5VxWuw5i/ORWoLTaKEBvLcxqqf0dtho9KhoC8R3/7Ndz l+XKQLALIDwWEPm2UHj2q6Fp2kCaKzbUFLi0CYhbmvmNW8rrtxde2uNWdHRr0rR0GZC3 QWimXPA8V/9ufFSuvE77F6DRzCjurYUDGbkyk0tR9orzY3RsrQbD1p08MU70Umq80Zhk lKhHc/bL1z/56WJ1rBL5e6LS+Zmu4j8FYoonPFR9KnrxlviBbsK/ZoAUmu9Q3N2cFtj0 tmqg== Received: by 10.152.108.178 with SMTP id hl18mr4506377lab.11.1338584563031; Fri, 01 Jun 2012 14:02:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.108.178 with SMTP id hl18mr4506367lab.11.1338584562864; Fri, 01 Jun 2012 14:02:42 -0700 (PDT) Received: by 10.112.99.129 with HTTP; Fri, 1 Jun 2012 14:02:42 -0700 (PDT) In-Reply-To: <4FC92727.5000402@isode.com> References: <4FC90AA5.8090502@KingsMountain.com> <4FC92727.5000402@isode.com> Date: Fri, 1 Jun 2012 14:02:42 -0700 Message-ID: From: Chris Palmer To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl/vHZy7qHX3csxvG7sNXoJ2iKrPLnzpAt9MoB7ykGcRA380YF6i150rJBguaxzAxxLj2hB3pMoSaK5G/b9Qye5O8GFbyrJqJlK7/cpfZjJO+J9CReFVLC47evs8gn+E7Fy46Rl Cc: IETF WebSec WG Subject: Re: [websec] ignoring STS header fields with undefined directives (was: new rev: draft-ietf-websec-strict-transport-sec-08) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 01 Jun 2012 21:02:45 -0000 On Fri, Jun 1, 2012 at 1:33 PM, Alexey Melnikov wrote: > I agree with Julian: this will make the header field effectively non > extensible. And if you update the header field by adding new values, all > older implementations will start ignoring it, which is a deployment > headache. For public key pinning, I'm allowing undefined directives in my implementation. I should check that I'm explicit about that in the I-D, come to think of it... From Jeff.Hodges@KingsMountain.com Fri Jun 1 17:22:08 2012 Return-Path: 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 85F3911E8091 for ; Fri, 1 Jun 2012 17:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.309 X-Spam-Level: X-Spam-Status: No, score=-100.309 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 RMvciEJYprtM for ; Fri, 1 Jun 2012 17:22:07 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 8D42111E8073 for ; Fri, 1 Jun 2012 17:22:07 -0700 (PDT) Received: (qmail 2892 invoked by uid 0); 2 Jun 2012 00:22:07 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 2 Jun 2012 00:22:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=JlRGRfkHa8nnco1TZwnazLSkcz9SpD/U+YksWt/+8FY=; b=cwdmWI/KqZrwl+cdPu/viyPGLxfoYlsX0egQtOMpXLUWTMMzo+qQkdiRuy/LPA1OiWppymV6qa4Pc4tjJk/SPtgs04bFQ3c1iyQCJ4HMaTQy0KszSRWIPWLWUsyYJ244; Received: from [216.113.168.128] (port=28240 helo=[10.244.136.116]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sac6Y-0006y7-C1; Fri, 01 Jun 2012 18:22:06 -0600 Message-ID: <4FC95CAD.20600@KingsMountain.com> Date: Fri, 01 Jun 2012 17:22:05 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] ignoring STS header fields with undefined directives (was: new rev: draft-ietf-websec-strict-transport-sec-08) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 02 Jun 2012 00:22:08 -0000 > On 2012-06-01 20:32, =JeffH wrote: > >> Alexey wrote: >> >> > Most of my issues were addressed in the latest version, except for >> this one: >> > >> > > 6.1. Strict-Transport-Security HTTP Response Header Field >> > > >> > > 4. UAs MUST ignore any STS header fields containing directives, or >> > > other header field value data, that does not conform to the >> > > syntax defined in this specification. >> > >> > So this is saying that syntactically invalid STS header fields are >> > to be ignored. This still doesn't say if unrecognized directives are to >> > be ignored or not. (Because they can comply with the generic syntax for >> > directives, so they would be syntactically valid, albeit unrecognized). >> > So can you please add an explicit sentence about that? >> >> >> Here's the text in my working copy for that item.. >> >> >> UAs MUST ignore any STS header fields containing >> directives, or other header field value data, that does >> not conform to the syntax defined in this specification. >> UAs MUST also ignore any STS header fields containing >> undefined directives. >> >> >> Ok? >> ... > > That makes it basically impossible to add extensions; is that intended? No, that is not my intention, nor the WG's as far as I understand. Alexey follows up with: > > I agree with Julian: this will make the header field effectively non > extensible. And if you update the header field by adding new values, all > older implementations will start ignoring it, which is a deployment > headache. Ok, so the first proposal is broken, how about this.. UAs MUST ignore any STS header fields containing directives, or other header field value data, that does not conform to the syntax defined in this specification. UAs MUST ignore any directives they do not recognize, but MAY accept and process a STS header field containing an unrecognized directive but otherwise satisfying the other requirements (1 through 4) stated here. ..? Note that the paragraph following the above numbered list items states: Additional directives extending the semantic functionality of the STS header field can be defined in other specifications. thanks, =JeffH From Jeff.Hodges@KingsMountain.com Fri Jun 1 21:38:42 2012 Return-Path: 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 0CE5A21F898D for ; Fri, 1 Jun 2012 21:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.195 X-Spam-Level: X-Spam-Status: No, score=-98.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MANGLED_EMAIL=2.3, RDNS_NONE=0.1, 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 8DkiW2XlmKpF for ; Fri, 1 Jun 2012 21:38:40 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id D75F521F898B for ; Fri, 1 Jun 2012 21:38:39 -0700 (PDT) Received: (qmail 7989 invoked by uid 0); 2 Jun 2012 04:38:39 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 2 Jun 2012 04:38:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=qz2va2nZK+4Ejho4U4isWBK6c5q06J623q2fS8RhVRg=; b=ox5ZZ5WTjDBUJ5EsEkBbZKujo0rXgnT6X0L3IjTVYski5812C6yMh1+u6hGHN53Dh0U02ijoa2EG4OSgy8+2vcxtYzE+YCYjK9YaHi5gPr1h8Elwx3eAIAjGmm5khS3y; Received: from [24.4.122.173] (port=36095 helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sag6o-0002Gb-PU; Fri, 01 Jun 2012 22:38:38 -0600 Message-ID: <4FC998CD.4040407@KingsMountain.com> Date: Fri, 01 Jun 2012 21:38:37 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Apps Discuss , IETF WebSec WG , draft-ietf-websec-strict-transport-sec@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] AppsDir review of draft-ietf-websec-strict-transport-sec X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 02 Jun 2012 04:38:42 -0000 Hi, thanks again for your review of draft-ietf-websec-strict-transport-sec-06, Murray. I've interpreted and applied your comments [1] to -08, yielding an -09 working copy. In the below, "done in -09" means done in my working copy of -09 -- which I haven't published quite yet. I'm trying to resolve the unrecognized directives language thing being discussed on websec@ before doing so. thanks again, =JeffH [1] HSTS: AppsDir Editorial comments http://trac.tools.ietf.org/wg/websec/trac/ticket/46 > MINOR ISSUES: > > Section 2.3.2: Your Security Considerations section should probably include > a pointer to this section. very good point. done in -09. > Section 3: Are the latter two paragraphs really necessary? I only find such > statements useful when minimum conformance is not the same thing as full > conformance. It's apparently helpful for readers with a strong W3C-style spec background. I'll leave them in. > Section 4, HTTP Strict Transport Security Host: Should this say "for all > web pages it serves" or similar? That sort of detailed requirements are given in Section 7 Server Processing Model. I'd rather keep the term definition to be high-level. Plus, the statement isn't strictly true -- an HSTS Host doesn't have to return the STS header field for all resources on all requests. (again see S7) > Section 4: Expand ABNF on first use, and include a reference to RFC5234. > (The reference could instead go in Section 6.) > > Section 6.1: The ABNF you have there requires a leading semi-colon. Based > on your examples, I think instead you want: > > Strict-Transport-Security = "Strict-Transport-Security" ":" > directive *( ";" [directive] ) > > Note that this also allows: > > Strict-Transport-Security: foobar;;;;;;;;;;;; > > Is that okay? > > Section 6.1: What's "the STS directive extension point"? > > Section 6.1.1: I think the "delta-seconds" should be: > > delta-seconds = 1*DIGIT > ; defined in Section 3.3.2 of [RFC2616] > > The angle-bracket notation you have there doesn't seem to be normal. > > Section 6.2: The second example isn't strictly correct because no space is > allowed around the semi-colon in the ABNF in Section 6.1. It looks like you'll > need to add optional whitespace at various points in the ABNF, or correct the > example. the above issues were discussed on list, the spec is based on RFC2616 ABNF (not RFC5234), as well as there having been changes to aspects of the above quoted text from -06 to -08. please refer to at least -08. thx. > Section 8.1: The "Note:" includes stuff that should be normative, and thus > is not appropriate for a side discussion note. It doesn't quite jive with > how you've defined use of "Note:" as a document convention. "Note:" removed. done in -09. > Section 8.2: The "Note that..." at the end threw me for a loop. How does > what's said in 8.2 imply what's stated here? For example, what does it say > about SMTP or FTP? sec 8.2 (now 8.3) was heavily re-written in rev -07 -- I believe this comment no longer applies. > Section 10.1: This discussion got me wondering why an absolute time for > HSTS Policy expiration isn't used instead of a delta. Perhaps that could be > explained somewhere like Appendix A. (Yes, I know about time synchronization, > but this text gave me pause.) as I recall (this was early in the HSTS work), there were the time sync issues plus the whole mess with cookies having both "expires" and "max-age" and other non-trivial stuff such as needing to parse various date formats because server implementors got it wrong but its incumbent on UA implementors to try to be a lenient as possible, etc. Without rummaging back through all those discussions, I've added this note to Appendix A "Design Decision Notes" in -09, and hope it's sufficient... The max-age approch of having the HSTS Host provide a simple integer number of seconds for a cached HSTS Policy time-to-live value, as opposed to an approach of stating an expiration time in the future was chosen for various reasons. Amongst the reasons are no need for clock syncronization, no need to define date and time value syntaxes (specification simplicity), and implementation simplicity. > Section 10.3: "example-ca.com" is not a reserved domain name for use in > examples. Suggest "ca.example.com" or "ca.example". Same issue with > "example-ca-services.net". done in -09. > Section 14.2: The "but the attacker has established somewhere" clause > doesn't parse for me. What's it trying to say? clarified in -09: "...but that the attacker has managed to register in the DNS and point at an HTTP server under the attacker's control.." ##### Ok, so amongst the below "NITS" comments was the "a HSTS" vs "an HSTS", as well as "a STS" vs "an STS". I did some research (e.g. Chicago Manual of Style) and will change 'em all to the "an" form. Those various comments are elided from the below in a perhaps vain attempt at shortening the below. > NITS (mostly trying to save the RFC Editor some work here): > > There are so many important references to [ForceHTTPS] that I think it > might be helpful to include page or section numbers for those. I added section #s to a couple more [ForceHTTPS] citation occurrences. > Section 1: The Abstract uses "Web" as a proper noun, but this section > includes uses of it that are all lowercase. I believe it should be used > one way or the other throughout the document. I fixed the occurrences in the abstract. done in -09. > Section 1: "Section", when referring to a section of a document, should be > capitalized. (Also occurs in a few other places.) not sure what's being referred to here. "Section" is capitalized when it is used to denote an explicit section in a cited doc. Am declining to capitalize "section" in phrases such as "This section..." > Section 2.2, bullet 1: s/to be/such that they are replaced by/ > > Section 2.2, bullet 3: s/to a HSTS Host/to an HSTS Host/ sec 2.2 re-written in -07/-08, decline. > Section 2.3.1.1: Define or provide a reference for what Firefox is, in case > it's somehow not in common use at the time some future reader gets this. s/Firefox/web browser extension/ done in -09. > Section 2.3.1.2: Define or expand "CA" on first use. done in -09. > For that matter, would > it be possible to reference something that talks about the difference between > self-signed and CA-signed certificates, and why they get different treatment? suggestions welcome. > Section 2.3.1.3: Define or expand "SWF" on first use. > > Section 2.3.1.3: s/by injecting script/by injecting a script/ done in -09. > > Section 2.4.1.1, bullet 1: s/interacted with/accessed/ > > Section 2.4.1.1, bullet 3: s/to persistently remember/to retain persistent > data about/ > > Section 2.4.1.1, ending Note: The last "," should be a ";", or a period > followed by a new sentence. done in -09. > > Section 4: Suggest ending terms with ":" so that you don't get things like > how "domain name label" looks in this version of the draft. > > Section 4, "HTTP Strict Transport Security Host": s/policy/Policy/, so it's > clear we're using your definition. done in -09. > > Section 4, "HTTP Strict Transport Security Policy": Is "Policy" right here? > Isn't it really a "Protocol"? perhaps. text ? > Section 4, "HTTP Strict Transport Security Policy": s/specified/defined/ > (so as to avoid "specified in this specification") done in -09. > Section 4, "Local policy": Why is "configuration settings" quoted? quoted no longer. done in -09. > Section 5 and beyond: You define "HSTS Policy" and "HSTS Host" (note > capitalization), but use "HSTS policy" and "HSTS host" in numerous places. > Best to be consistent agreed. thought I'd caught them all. done in -09. > Section 5, second paragraph: All-lowercase "may" should probably be "MAY". It's on "overview" -- those are not normative MAYs, lowercase usage is on purpose. declined. > Section 6.1.2: s/which/that/ I prefer which. declined. > Section 7: s/facets:/facets,/; s/the second/and the second/ stylistic preference, declined. > Section 7.1: s/difficult to uniformly emit STS header fields/difficult to > emit STS header fields uniformly/ stylistic preference, declined. > Section 7.2, second bullet: Add a matching "--" after "components". some modest fixups made to that bulleted list. done in -09. > Section 8.1.1: s/that the host responded to/to which the host responded/ done in -09. > Section 8.1.1: That last paragraph is one big long sentence. Suggest > breaking it up. text? > Section 8.5: The "For example, ..." is a sentence fragment. done in -09. > Section 9, bullet 2: Remove the "," after "label". addressed in -07. > Section 9, bullet 2: s/latter,/latter;/ addressed in -07. > Section 9, bullet 3: The (".") should come after the hex. done in -09. > Section 10: "This section is non-normative." (cringe; I'm still of the > opinion that a section is implicitly non-normative if it has no normative > text in it, and these notations are extraneous) am being purposefully painfully explicit with their usage in the two sections where they occur. Keeping them. > Section 10.1, fourth paragraph: This is another sentence fragment. addressed in -07. > Section 10.2: s/their own/its own/ (the noun is singular, the verb has to > agree) done in -09. > Section 10.2, second paragraph: s/certificates, and their own/certificates > and its own/; various other "their/they" to "its/it", because "organization" > isn't plural done in -09. > Section 10.2, note: s/attack, see/attack. See/ > > Section 10.3: s/implications -- for/implications. For/ done in -09. > Section 10.3, second paragraph: s/which/that/ stylistic. declined. > Section 10.3: s/HSTS, and that have/HSTS that have/; s/application, > would/application would/ done in -09. > Section 11: (cringe) > > Section 11: You variably spell it "implementors" and "implementers". I'm > pretty sure the latter is correct, but either way, some of them are not. :-) done in -09. > Section 11.1: s/Establishment"),/Establishment")/ > > > Section 11.2, Note: s/basis -- see/basis. See/ > > Section 11.2, Note: s/is independent of/is independent of,/ done in -09. > Section 11.2: Opens with a non-sentence. > > Section 11.3: Opens with a non-sentence. > > Section 11.4: Opens with a non-sentence. fixed in -07. > Section 11.4, Note: s/to more clearly define the term(s)/to define the > term(s) more clearly/ done in -09. > Section 11.5: Opens with a non-sentence. fixed in -07. > Section 12: All lowercase MUST here. eh? I believe the "MUST NOT" at the end of S12.2 should remain. that's the only one. > Section 12.2: Seriously nitty here: The "host, and the port (if present)" > doesn't make it clear if the separating colon is included. those are production names from the ABNF in S12.1, so I don't think it needs addressing. If this is a problem, then you need to comment on the appropriate draft of the httpbis suite-o-drafts (draft -p1 me thinks), too. > Section 14.1, first bullet: Missing close parenthesis. doh. done in -09. > Section 14.1, second bullet: s/to no longer be regarded/to cease being > regarded/ done in -09. > Section 14.1: s/And even if the risk/Even if the risk/ > > Section 14.1: s/as a HSTS Host. Thus as/as an HSTS Host. Thus, as/ > > Section 14.1: s/But once/Once/ done in -09. > Section 14.2: s/to adequately protect/to provide adequate protection for/ stylisticly declined. > Section 14.3: s/to manually configure HSTS Policy/to configure HSTS Policy > manually/ stylisticly declined. > Section 14.3, third "*" bullet: Contains two sentence fragments. done in -09. > Section 14.3, final paragraph: s/to automatically regard/to regard > automatically/ stylisticly declined. > Section 14.5: Expand NTP on first use, and provide a reference. done in -09. > Section 14.6: Opens with a sentence fragment. rewrote this section in -09. please review. --- end From julian.reschke@gmx.de Fri Jun 1 23:01:38 2012 Return-Path: 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 42B2221F8A8C for ; Fri, 1 Jun 2012 23:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Tk0ZPoohVGnw for ; Fri, 1 Jun 2012 23:01:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 03D3821F8A8B for ; Fri, 1 Jun 2012 23:01:36 -0700 (PDT) Received: (qmail invoked by alias); 02 Jun 2012 06:01:35 -0000 Received: from p54BB353B.dip.t-dialin.net (EHLO [192.168.178.36]) [84.187.53.59] by mail.gmx.net (mp017) with SMTP; 02 Jun 2012 08:01:35 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/cPTQxajTcxbGNukswC7tZYTjiFwhQ0ijv1gQ6hd 5uF/qnKzNnHb5X Message-ID: <4FC9AC3F.8070800@gmx.de> Date: Sat, 02 Jun 2012 08:01:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =JeffH References: <4FC95CAD.20600@KingsMountain.com> In-Reply-To: <4FC95CAD.20600@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF WebSec WG Subject: Re: [websec] ignoring STS header fields with undefined directives (was: new rev: draft-ietf-websec-strict-transport-sec-08) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 02 Jun 2012 06:01:38 -0000 On 2012-06-02 02:22, =JeffH wrote: > > On 2012-06-01 20:32, =JeffH wrote: > > > >> Alexey wrote: > >> > >> > Most of my issues were addressed in the latest version, except for > >> this one: > >> > > >> > > 6.1. Strict-Transport-Security HTTP Response Header Field > >> > > > >> > > 4. UAs MUST ignore any STS header fields containing directives, or > >> > > other header field value data, that does not conform to the > >> > > syntax defined in this specification. > >> > > >> > So this is saying that syntactically invalid STS header fields are > >> > to be ignored. This still doesn't say if unrecognized directives > are to > >> > be ignored or not. (Because they can comply with the generic > syntax for > >> > directives, so they would be syntactically valid, albeit > unrecognized). > >> > So can you please add an explicit sentence about that? > >> > >> > >> Here's the text in my working copy for that item.. > >> > >> > >> UAs MUST ignore any STS header fields containing > >> directives, or other header field value data, that does > >> not conform to the syntax defined in this specification. > >> UAs MUST also ignore any STS header fields containing > >> undefined directives. > >> > >> > >> Ok? > >> ... > > > > That makes it basically impossible to add extensions; is that intended? > > No, that is not my intention, nor the WG's as far as I understand. > > > Alexey follows up with: > > > > I agree with Julian: this will make the header field effectively non > > extensible. And if you update the header field by adding new values, all > > older implementations will start ignoring it, which is a deployment > > headache. > > Ok, so the first proposal is broken, how about this.. > > > UAs MUST ignore any STS header fields containing > directives, or other header field value data, that does > not conform to the syntax defined in this specification. > > > UAs MUST ignore any directives they > do not recognize, but MAY accept and > process a STS header field containing an > unrecognized directive but otherwise > satisfying the other > requirements (1 through 4) stated here. > > > ..? > > Note that the paragraph following the above numbered list items states: > > Additional directives extending the semantic functionality of the STS > header field can be defined in other specifications. "UAs MUST ignore any directives they do not recognize, ..." Yes. " ...but MAY accept and process a STS header field containing an unrecognized directive but otherwise satisfying the other requirements (1 through 4) stated here." Why "MAY accept" here? If the MUST ignore extension directives, doesn't that mean that that "MAY" indeed is a "MUST"? Best regards, Julian From barryleiba.mailing.lists@gmail.com Sat Jun 2 06:03:46 2012 Return-Path: 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 D16D321F8672; Sat, 2 Jun 2012 06:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.003 X-Spam-Level: X-Spam-Status: No, score=-103.003 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 srIeHHNbQP9q; Sat, 2 Jun 2012 06:03:44 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B987121F8671; Sat, 2 Jun 2012 06:03:40 -0700 (PDT) Received: by lagv3 with SMTP id v3so2289707lag.31 for ; Sat, 02 Jun 2012 06:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=OeKTWuKZ6GEQd9u+PN8pg+gFYXXlsvZd0bZTYzmzcrg=; b=ohCXoFXVaBsbFb6GIJUMvnDKi5WdN/PNry/H+L6SuF/Sl//3vRjDva7973taWVDmdf QAtamPoJVlEzdZjTux3e6jHfrlTBwqCTGHXRQcF+wTAz2hulTIbHTkm1uqmLjiix/NYt gx1crcVjI7LxTXwkv9pYmsLRWR77a4yAtS1eFMnZYfmlk8OpVfXYzMM3Wl+Wchx07/H6 dSfrv7T337cs4ph/o2g9zk1NV7bmF3L1DhfMJRdedQK8CjIUlSt/qjA01wt2hxPS6HQU h88GNU/psGf2caOZ1CQyuSTNlBz7eeSIjDnDnszXR7/S0EEF6tPjzwOWPmTpnSbWYL9f 4KyQ== MIME-Version: 1.0 Received: by 10.152.108.144 with SMTP id hk16mr6547257lab.2.1338642219659; Sat, 02 Jun 2012 06:03:39 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.48.104 with HTTP; Sat, 2 Jun 2012 06:03:39 -0700 (PDT) In-Reply-To: <4FC998CD.4040407@KingsMountain.com> References: <4FC998CD.4040407@KingsMountain.com> Date: Sat, 2 Jun 2012 09:03:39 -0400 X-Google-Sender-Auth: W9f2FDEkeoDex3LC11GsoasJmOs Message-ID: From: Barry Leiba To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-websec-strict-transport-sec@tools.ietf.org, IETF WebSec WG , Apps Discuss Subject: Re: [websec] [apps-discuss] AppsDir review of draft-ietf-websec-strict-transport-sec X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 02 Jun 2012 13:03:46 -0000 [Changed Murray's address to his new one.] >> Section 3: Are the latter two paragraphs really necessary? I only find >> such >> statements useful when minimum conformance is not the same thing as full >> conformance. > > It's apparently helpful for readers with a strong W3C-style spec background. > I'll leave them in. It might be a good idea, then, to put something like the following in at the beginning of the section: [[IESG Note: This section is for readers with a background in W3C specification style, of which we expect many. RFC Editor, please remove this note before publication.]] This will avoid the same question/complaint from ADs during IESG evaluation. I also suggest that you move the 2119 paragraph to the end of the section, to keep all three compliance-related paragraphs together. Barry From internet-drafts@ietf.org Mon Jun 4 11:35:32 2012 Return-Path: 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 D4E0E21F87BF; Mon, 4 Jun 2012 11:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, 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 q8n0oZOhIT6Y; Mon, 4 Jun 2012 11:35:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6647A21F87A3; Mon, 4 Jun 2012 11:35:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120604183532.20788.10190.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2012 11:35:32 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-key-pinning-02.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 04 Jun 2012 18:35:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IET= F. Title : Public Key Pinning Extension for HTTP Author(s) : Chris Evans Chris Palmer Filename : draft-ietf-websec-key-pinning-02.txt Pages : 17 Date : 2012-06-04 This memo describes an extension to the HTTP protocol allowing web host operators to instruct user agents (UAs) to remember ("pin") the hosts' cryptographic identities for a given period of time. During that time, UAs will require that the host present a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one or more of the pinned fingerprints for that host. By effectively reducing the scope of authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities and other authentication errors and attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ From Jeff.Hodges@KingsMountain.com Mon Jun 4 13:10:49 2012 Return-Path: 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 7667D11E80BA for ; Mon, 4 Jun 2012 13:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.346 X-Spam-Level: X-Spam-Status: No, score=-100.346 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 Ypa5rcyOgdT5 for ; Mon, 4 Jun 2012 13:10:45 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 21E5F11E80CC for ; Mon, 4 Jun 2012 13:10:44 -0700 (PDT) Received: (qmail 9474 invoked by uid 0); 4 Jun 2012 20:10:44 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 4 Jun 2012 20:10:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=1jOIswVUcNKleUoN4BJEM0Ks5pIGCxr1UH7U5QJqrAk=; b=HC3FMT/zHAb4kW8gC6l5nMOnIQmkbIuboV63lYjMdY3+CTDBEwX+VRBvbUd3dv6Bw5D+NUBC+A2Z1aHCeI+vtSVYS+GS8qdsbntCRom/LefyBdt2ygIK6nTUYI6nwu72; Received: from [216.113.168.128] (port=31192 helo=[10.244.136.116]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sbdbw-00075Q-74; Mon, 04 Jun 2012 14:10:44 -0600 Message-ID: <4FCD1645.3050700@KingsMountain.com> Date: Mon, 04 Jun 2012 13:10:45 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Julian Reschke Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] ignoring STS header fields with undefined directives (was: new rev: draft-ietf-websec-strict-transport-sec-08) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 04 Jun 2012 20:10:49 -0000 > On 2012-06-02 02:22, =JeffH wrote: >> > On 2012-06-01 20:32, =JeffH wrote: >> > >> >> Alexey wrote: >> >> >> >> > Most of my issues were addressed in the latest version, except for >> >> this one: >> >> > >> >> > > 6.1. Strict-Transport-Security HTTP Response Header Field >> >> > > >> >> > > 4. UAs MUST ignore any STS header fields containing directives, or >> >> > > other header field value data, that does not conform to the >> >> > > syntax defined in this specification. >> >> > >> >> > So this is saying that syntactically invalid STS header fields are >> >> > to be ignored. This still doesn't say if unrecognized directives >> are to >> >> > be ignored or not. (Because they can comply with the generic >> syntax for >> >> > directives, so they would be syntactically valid, albeit >> unrecognized). >> >> > So can you please add an explicit sentence about that? >> >> >> >> >> >> Here's the text in my working copy for that item.. >> >> >> >> >> >> UAs MUST ignore any STS header fields containing >> >> directives, or other header field value data, that does >> >> not conform to the syntax defined in this specification. >> >> UAs MUST also ignore any STS header fields containing >> >> undefined directives. >> >> >> >> >> >> Ok? >> >> ... >> > >> > That makes it basically impossible to add extensions; is that intended? >> >> No, that is not my intention, nor the WG's as far as I understand. >> >> >> Alexey follows up with: >> > >> > I agree with Julian: this will make the header field effectively non >> > extensible. And if you update the header field by adding new values, all >> > older implementations will start ignoring it, which is a deployment >> > headache. >> >> Ok, so the first proposal is broken, how about this.. >> >> >> UAs MUST ignore any STS header fields containing >> directives, or other header field value data, that does >> not conform to the syntax defined in this specification. >> >> >> UAs MUST ignore any directives they >> do not recognize, but MAY accept and >> process a STS header field containing an >> unrecognized directive but otherwise >> satisfying the other >> requirements (1 through 4) stated here. >> >> >> ..? >> >> Note that the paragraph following the above numbered list items states: >> >> Additional directives extending the semantic functionality of the STS >> header field can be defined in other specifications. > > "UAs MUST ignore any directives they do not recognize, ..." > > Yes. > > " ...but MAY accept and process a STS header field containing an > unrecognized directive but otherwise satisfying the other requirements > (1 through 4) stated here." > > Why "MAY accept" here? If the MUST ignore extension directives, doesn't > that mean that that "MAY" indeed is a "MUST"? thanks, yes, I believe that's correct. Here's what I have upon re-writing it (this is in S 6.1)... 4. UAs MUST ignore any STS header fields containing directives, or other header field value data, that does not conform to the syntax defined in this specification. 5. If an STS header field contains directive(s) not recognized by the UA, the UA MUST ignore the unrecognized directives and if the STS header field otherwise satisfies the above requirements (1 through 4), the UA MUST process the recognized directives. Additional directives extending the semantic functionality of the STS header field can be defined in other specifications. =JeffH From alexey.melnikov@isode.com Mon Jun 4 13:20:56 2012 Return-Path: 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 03FFA11E80EC for ; Mon, 4 Jun 2012 13:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, 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 no-w5siq99Sm for ; Mon, 4 Jun 2012 13:20:55 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id DF06C11E80C0 for ; Mon, 4 Jun 2012 13:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338841254; d=isode.com; s=selector; i=@isode.com; bh=7QRWotMbVTHH1uIleIp5gD/LmkKOvkMU3DC9bQ/Q0qs=; 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=DpdPjkjiXRUyTvKsfup2HajlVJNqZwalqHfY5qL+jzMlLDR0nBqpRfcWp2HkX9/M+qHm95 5T9D/ghWEzQ3MYxRbOzE0kDJkRxf9VrOiKdyKx3MB9jd+/RMt66gbqubGUU3jaQ06AwrVw zO7ruE6KcqylyRBGd1Dw/pi3iKd/HkU=; Received: from [172.20.10.2] ((unknown) [212.183.128.204]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 4 Jun 2012 21:20:46 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FCD1897.9040601@isode.com> Date: Mon, 04 Jun 2012 21:20:39 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: =JeffH References: <4FCD1645.3050700@KingsMountain.com> In-Reply-To: <4FCD1645.3050700@KingsMountain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , IETF WebSec WG Subject: Re: [websec] ignoring STS header fields with undefined directives (was: new rev: draft-ietf-websec-strict-transport-sec-08) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 04 Jun 2012 20:20:56 -0000 On 04/06/2012 21:10, =JeffH wrote: > > > On 2012-06-02 02:22, =JeffH wrote: > >> > On 2012-06-01 20:32, =JeffH wrote: > >> > > >> >> Alexey wrote: > >> >> > >> >> > Most of my issues were addressed in the latest version, except > for > >> >> this one: > >> >> > > >> >> > > 6.1. Strict-Transport-Security HTTP Response Header Field > >> >> > > > >> >> > > 4. UAs MUST ignore any STS header fields containing > directives, or > >> >> > > other header field value data, that does not conform to the > >> >> > > syntax defined in this specification. > >> >> > > >> >> > So this is saying that syntactically invalid STS header fields > are > >> >> > to be ignored. This still doesn't say if unrecognized directives > >> are to > >> >> > be ignored or not. (Because they can comply with the generic > >> syntax for > >> >> > directives, so they would be syntactically valid, albeit > >> unrecognized). > >> >> > So can you please add an explicit sentence about that? > >> >> > >> >> > >> >> Here's the text in my working copy for that item.. > >> >> > >> >> > >> >> UAs MUST ignore any STS header fields containing > >> >> directives, or other header field value data, that does > >> >> not conform to the syntax defined in this specification. > >> >> UAs MUST also ignore any STS header fields containing > >> >> undefined directives. > >> >> > >> >> > >> >> Ok? > >> >> ... > >> > > >> > That makes it basically impossible to add extensions; is that > intended? > >> > >> No, that is not my intention, nor the WG's as far as I understand. > >> > >> > >> Alexey follows up with: > >> > > >> > I agree with Julian: this will make the header field effectively non > >> > extensible. And if you update the header field by adding new > values, all > >> > older implementations will start ignoring it, which is a deployment > >> > headache. > >> > >> Ok, so the first proposal is broken, how about this.. > >> > >> > >> UAs MUST ignore any STS header fields containing > >> directives, or other header field value data, that does > >> not conform to the syntax defined in this specification. > >> > >> > >> UAs MUST ignore any directives they > >> do not recognize, but MAY accept and > >> process a STS header field containing an > >> unrecognized directive but otherwise > >> satisfying the other > >> requirements (1 through 4) stated here. > >> > >> > >> ..? > >> > >> Note that the paragraph following the above numbered list items > states: > >> > >> Additional directives extending the semantic functionality of the STS > >> header field can be defined in other specifications. > > > > "UAs MUST ignore any directives they do not recognize, ..." > > > > Yes. > > > > " ...but MAY accept and process a STS header field containing an > > unrecognized directive but otherwise satisfying the other requirements > > (1 through 4) stated here." > > > > Why "MAY accept" here? If the MUST ignore extension directives, doesn't > > that mean that that "MAY" indeed is a "MUST"? > > thanks, yes, I believe that's correct. Here's what I have upon > re-writing it (this is in S 6.1)... > > 4. UAs MUST ignore any STS header fields containing directives, or > other header field value data, that does not conform to the > syntax defined in this specification. > > 5. If an STS header field contains directive(s) not recognized by > the UA, the UA MUST ignore the unrecognized directives and if the > STS header field otherwise satisfies the above requirements (1 > through 4), the UA MUST process the recognized directives. > > Additional directives extending the semantic functionality of the STS > header field can be defined in other specifications. This looks good to me now. From stephen.farrell@cs.tcd.ie Mon Jun 4 13:56:49 2012 Return-Path: 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 1D1DA11E807F for ; Mon, 4 Jun 2012 13:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.58 X-Spam-Level: X-Spam-Status: No, score=-103.58 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, 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 LYjAYuJak1ov for ; Mon, 4 Jun 2012 13:56:48 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 367F221F867A for ; Mon, 4 Jun 2012 13:56:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A76F01714E0 for ; Mon, 4 Jun 2012 21:56:45 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338843404; bh=xVXRwDFkL8+9ak frZfDq/Ai23sZPU0wpb8/KpAoWXt0=; b=WCoQvnYbZ0WFQIgEp68+GoWaaJhOD/ M2+2Tsbc1un9nwe8Mf8ZpTRSCRWLq7J+Hw1oowM54orWJEdyM5tvYkNbrIKa8Ufm FXY5mu5Fs4efWDxvAIi0zZnyU4CL6U/atoBfiM3xJcNeeGEDq7S9OwIoJ7mgOn9y CCfW3jpxq97HF1KYuHkcf5mmvL3McIvYr7IZziGZoDBgwDAIjSy06i4jnNxlD0s6 Fk3nxghKG/hUTDSviI1lHaSU2leczNNP1R0CvYa5XLXYax1tyZpu/3TGddSxh0n4 r49Aen0oiJJ3Dh81GB4pubg6B/VpdIB+Ys+GUxyokrRLFZE8+69EjPyw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id h59dMSiLEdyb for ; Mon, 4 Jun 2012 21:56:44 +0100 (IST) Received: from [10.87.48.8] (unknown [86.41.6.142]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D63C71714DC for ; Mon, 4 Jun 2012 21:56:44 +0100 (IST) Message-ID: <4FCD210C.2080807@cs.tcd.ie> Date: Mon, 04 Jun 2012 21:56:44 +0100 From: Stephen Farrell 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: <20120604183532.20788.10190.idtracker@ietfa.amsl.com> In-Reply-To: <20120604183532.20788.10190.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [websec] I-D Action: draft-ietf-websec-key-pinning-02.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 04 Jun 2012 20:56:49 -0000 I asked this before back in December but got no takers. Now that our naming things I-D is in IETF LC, I thought I'd ask again, just in case, and then shut up:-) draft-farrell-decade-ni-07 [1] defines ways to name things with hashes that could be used here. I don't see a mega-benefit, but perhaps some small ones, e.g not having to define IANA processes for algorithm agility for this draft (needed, but not yet defined). It also seems odd to be defining loads of ways to hash public keys with trivial differences. If you did choose to adopt our thing then instead of: pin-sha1="4n972HfV354KP560yw4uqe/baXc="; you'd perhaps use: pin="ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q"; There'd maybe be a few other tweaks, e.g. we use base64url (but also over the SPKI). Not sure what else. So: any interest in that? If there is but it'd need changes to [1] then we're open to chatting about that. (And happy to get any other comments on our draft as well of course.) Cheers, S. [1] http://tools.ietf.org/html/draft-farrell-decade-ni On 06/04/2012 07:35 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Security Working Group of the IETF. > > Title : Public Key Pinning Extension for HTTP > Author(s) : Chris Evans > Chris Palmer > Filename : draft-ietf-websec-key-pinning-02.txt > Pages : 17 > Date : 2012-06-04 > > This memo describes an extension to the HTTP protocol allowing web > host operators to instruct user agents (UAs) to remember ("pin") the > hosts' cryptographic identities for a given period of time. During > that time, UAs will require that the host present a certificate chain > including at least one Subject Public Key Info structure whose > fingerprint matches one or more of the pinned fingerprints for that > host. By effectively reducing the scope of authorities who can > authenticate the domain during the lifetime of the pin, pinning may > reduce the incidence of man-in-the-middle attacks due to compromised > Certification Authorities and other authentication errors and > attacks. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-websec-key-pinning-02.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/ > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > From Jeff.Hodges@KingsMountain.com Mon Jun 4 15:57:57 2012 Return-Path: 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 C8F1621F8638 for ; Mon, 4 Jun 2012 15:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.784 X-Spam-Level: X-Spam-Status: No, score=-98.784 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 G8zVpfKIqWYX for ; Mon, 4 Jun 2012 15:57:57 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id E0D6221F8633 for ; Mon, 4 Jun 2012 15:57:56 -0700 (PDT) Received: (qmail 1169 invoked by uid 0); 4 Jun 2012 22:57:56 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 4 Jun 2012 22:57:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=vhkvePCjnsLg0H6lk5OUUQ+K0jSuzNKSWHFDbz+2zPI=; b=NlGxGk3afFXuIClWfdj+H9qu7ei97VVDQvJ/QqKAMmCbcHx7Q9MVXWCtZAfgyQnQ+bzu6tSfCtb2JISv8uhP8kPh9HkwJ8UV62FwU4vTTWouyYrCcc3VUtA4JbyyLIKg; Received: from [24.4.122.173] (port=34158 helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SbgDk-0000Es-6y; Mon, 04 Jun 2012 16:57:56 -0600 Message-ID: <4FCD3D73.6000509@KingsMountain.com> Date: Mon, 04 Jun 2012 15:57:55 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: draft-ietf-websec-strict-transport-sec@tools.ietf.org, IETF WebSec WG , Apps Discuss Subject: Re: [websec] [apps-discuss] AppsDir review of draft-ietf-websec-strict-transport-sec X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 04 Jun 2012 22:57:58 -0000 >>> Section 3: Are the latter two paragraphs really necessary? I only find >>> such >>> statements useful when minimum conformance is not the same thing as full >>> conformance. >> >> It's apparently helpful for readers with a strong W3C-style spec background. >> I'll leave them in. > > It might be a good idea, then, to put something like the following in > at the beginning of the section: > > [[IESG Note: This section is for readers with a background in W3C > specification style, of which we expect many. RFC Editor, please > remove this note before publication.]] > > This will avoid the same question/complaint from ADs during IESG evaluation. > > I also suggest that you move the 2119 paragraph to the end of the > section, to keep all three compliance-related paragraphs together. thx, the above is done in the -09 working copy. =JeffH From paul.hoffman@vpnc.org Tue Jun 5 13:47:56 2012 Return-Path: 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 40AE721F87DF; Tue, 5 Jun 2012 13:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 tPayI6bNg7oV; Tue, 5 Jun 2012 13:47:52 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 545AB21F8599; Tue, 5 Jun 2012 13:47:52 -0700 (PDT) Received: from [10.20.30.101] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97] (may be forged)) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q55KlnEv051095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Jun 2012 13:47:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 5 Jun 2012 13:47:49 -0700 References: <4FCE6431.6050808@ieca.com> To: IETF DANE WG list , IETF WebSec WG Message-Id: <6A359D3F-3ACD-4E47-9F24-96A103178048@vpnc.org> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [websec] Fwd: [saag] Pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2012 20:47:56 -0000 =46rom the SAAG mailing list, but appropriate here. I bet that Sean = would appreciate all discussion to go on on the SAAG mailing list... Begin forwarded message: > From: Sean Turner > Subject: [saag] Pinning > Date: June 5, 2012 12:55:29 PM PDT > To: saag@ietf.org >=20 > All, >=20 > There are many proposals for how to say which key or certificate or = trust anchor should be used by the client in a TLS session that it is = about to open. These proposals include making that decision in the DNS = (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the = application after TLS has happened once, to be remembered in the future = (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and = in the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin = tls-tack/). If more than one of these protocols are deployed, = operational mistakes could lead to a client getting conflicting = information. >=20 > Similarly, there are also proposals on how to say whether or not a = client should expect to see a particular service running under TLS. = These proposals include making that indication in the DNS (draft = hoffman-server-has-tls, expired but might be revived) and in the = application after TLS has happened once, to be remembered in the future = (https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport = sec/). If more than one of these protocols are deployed, operational = mistakes could lead to a client getting conflicting information. >=20 > Is a standards-track operations statement needed to describe the = choices that a TLS server administrator has, and to deal with conflicts = between the proposals? >=20 > spt > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From ynir@checkpoint.com Tue Jun 5 14:11:45 2012 Return-Path: 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 8EF3A21F877F for ; Tue, 5 Jun 2012 14:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 lEEc54jYvhYp for ; Tue, 5 Jun 2012 14:11:44 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E4CFE21F8790 for ; Tue, 5 Jun 2012 14:11:43 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (dlpgw.checkpoint.com [194.29.34.27]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q55LBdj5005820 for ; Wed, 6 Jun 2012 00:11:39 +0300 X-CheckPoint: {4FCE8204-1-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 6 Jun 2012 00:11:36 +0300 From: Yoav Nir To: IETF WebSec WG Date: Wed, 6 Jun 2012 00:11:37 +0300 Thread-Topic: Pinning Thread-Index: Ac1DX8p9p9nnInxWRYe1ZCiK1HFbaA== Message-ID: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> References: <4FCE6431.6050808@ieca.com> <6A359D3F-3ACD-4E47-9F24-96A103178048@vpnc.org> In-Reply-To: <6A359D3F-3ACD-4E47-9F24-96A103178048@vpnc.org> 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 x-cpdlp: 11531ffdc5932c5e6c6409c08c7d27a50c8a447b4b Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [websec] Pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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, 05 Jun 2012 21:11:45 -0000 Hi The similarity of pinning and DANE has been discussed before. DANE relies o= n DNSSEC being deployed, which key-pinning does not. Come to think of it, t= he draft needs a section comparing with DANE, but that's for another thread= . draft-perrin-tls-tack seems to tackle the same problem as key-pinning. Inst= ead of the pins getting attested to in HTTP headers, you have a special pub= lic/private key pair, that you use to sign the SPKI from the server certifi= cate within the a TLS extension. Like key-pinning there's a TOFU element he= re, because the client only learns about the special key when it encounters= it in a TLS handshake. The obvious question is why would we need both key-pinning and tack. It has= been asked on the TLS mailing list:=20 http://www.ietf.org/mail-archive/web/tls/current/msg08818.html An answer by the draft authors is here: http://www.ietf.org/mail-archive/web/tls/current/msg08830.html In the grand scheme of things, it's not good for the IETF to make >1 standa= rds, both of which need to be implemented in both servers and browsers, tha= t accomplish the same thing, and Sean is correct that implementing more tha= n one may lead to mismatching information. In a sense DANE is also doing th= e same thing, but DANE requires DNSSEC everywhere, so it's operational prof= ile is different. But Tack and cert pinning both have no prerequisites and = accomplish the same thing, so what if one's at the HTTP layer, while the ot= her is at the TLS layer. I don't think the TLS WG is very excited about TACK (see the mailing list) = but regardless, I think it's up to us to look at both options and decide if= we would like to go on with cert-pinning, or whether we thing TACK is bett= er. Yoav On Jun 5, 2012, at 11:47 PM, Paul Hoffman wrote: > From the SAAG mailing list, but appropriate here. I bet that Sean would a= ppreciate all discussion to go on on the SAAG mailing list... >=20 > Begin forwarded message: >=20 >> From: Sean Turner >> Subject: [saag] Pinning >> Date: June 5, 2012 12:55:29 PM PDT >> To: saag@ietf.org >>=20 >> All, >>=20 >> There are many proposals for how to say which key or certificate or trus= t anchor should be used by the client in a TLS session that it is about to = open. These proposals include making that decision in the DNS (https://data= tracker.ietf.org/doc/draft-ietf-dane-protocol/), in the application after T= LS has happened once, to be remembered in the future (https://datatracker.i= etf.org/doc/draft-ietf-websec-key-pinning/), and in the TLS handshake (http= s://datatracker.ietf.org/doc/draft-perrin tls-tack/). If more than one of t= hese protocols are deployed, operational mistakes could lead to a client ge= tting conflicting information. >>=20 >> Similarly, there are also proposals on how to say whether or not a clien= t should expect to see a particular service running under TLS. These propos= als include making that indication in the DNS (draft hoffman-server-has-tls= , expired but might be revived) and in the application after TLS has happen= ed once, to be remembered in the future (https://datatracker.ietf.org/doc/d= raft-ietf-websec-strict-transport sec/). If more than one of these protocol= s are deployed, operational mistakes could lead to a client getting conflic= ting information. >>=20 >> Is a standards-track operations statement needed to describe the choices= that a TLS server administrator has, and to deal with conflicts between th= e proposals? >>=20 >> spt From tobias.gondrom@gondrom.org Wed Jun 6 09:46:21 2012 Return-Path: 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 779EA21F86B5 for ; Wed, 6 Jun 2012 09:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.778 X-Spam-Level: X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 FOZxaKUqUb4L for ; Wed, 6 Jun 2012 09:46:21 -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 CD83921F8718 for ; Wed, 6 Jun 2012 09:46:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=cnxEZrk3HfqFHoJsXYYRgtdHcSxkG+7/7vZ35VgtazUVPdxd7RofFS3pgZMnCTHfT1IIW+LfkdgOmbp0rAA4w9OaAsTunL/Uyps2Vc3Gy8t68WqWe1nd6NP6Cllkf2sc; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 3983 invoked from network); 6 Jun 2012 18:46:04 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.69?) (94.194.102.93) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Jun 2012 18:46:04 +0200 Message-ID: <4FCF894B.8080002@gondrom.org> Date: Wed, 06 Jun 2012 17:46:03 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: paul.hoffman@vpnc.org, ynir@checkpoint.com, turners@ieca.com References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> In-Reply-To: <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: websec@ietf.org, saag@ietf.org Subject: Re: [websec] [saag] Pinning X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jun 2012 16:46:21 -0000 Sean et al., I agree with Paul and Yoav and think the coordination between dane and websec on HSTS and key-pinning is ok. Both WGs are aware of potential coordination issues when mechanisms in both (DNSSEC and HTTP header) will be implemented eventually. I don't think we need an operations statement yet. Maybe at some point in the future an informational Best Practice or if you wish a Std Track can help. With regards to draft-perrin-tls-tack and draft-ietf-websec-key-pinning, I am not so sure about potential conflicts here and whether we need or want both. Best regards, Tobias Ps.: And on a personal note, one thing I am not so happy about is that I can see from the tls-tack draft, that the authors are aware of key-pinning (which is nice) and perceive that there would be flaws, yet they chose to not post their comments on it to websec nor inform the WG about their new draft. To make it easier in the future to coordinate the two drafts and possibly discuss and decide whether to boil down to one, it might make sense to inform websec about draft-perrin-tls-tack and have a discussion about it at some point there. Just my 5cents. On 05/06/12 23:01, Paul Hoffman wrote: > On Jun 5, 2012, at 2:46 PM, Yoav Nir wrote: > >>> The similarity of pinning and DANE has been discussed before. DANE relies on DNSSEC being deployed, which key-pinning does not. > Correct. Further, key-pinning in HTTP only applies to HTTP and relies on the client being able to establish a TLS session using non-key-pinning semantics. Key-pinning in TLS relies works with any lower-layer protocol and relies on the client being able to establish a TLS session using non-key-pinning semantics. > >>> Come to think of it, the draft needs a section comparing with DANE, but that's for another thread. >>> >>> draft-perrin-tls-tack seems to tackle the same problem as key-pinning. Instead of the pins getting attested to in HTTP headers, you have a special public/private key pair, that you use to sign the SPKI from the server certificate within the a TLS extension. Like key-pinning there's a TOFU element here, because the client only learns about the special key when it encounters it in a TLS handshake. >>> >>> The obvious question is why would we need both key-pinning and tack. > It would be clearer if you said "both key-pinning in HTTP and key-pinning in TLS (tack)". > > --Paul Hoffman > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From internet-drafts@ietf.org Wed Jun 6 18:03:59 2012 Return-Path: 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 47D8B11E80AF; Wed, 6 Jun 2012 18:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, 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 7hGR1X8TWoWL; Wed, 6 Jun 2012 18:03:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C37C311E809F; Wed, 6 Jun 2012 18:03:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120607010358.10731.9194.idtracker@ietfa.amsl.com> Date: Wed, 06 Jun 2012 18:03:58 -0700 Cc: websec@ietf.org Subject: [websec] I-D Action: draft-ietf-websec-strict-transport-sec-09.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Thu, 07 Jun 2012 01:03:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Security Working Group of the IET= F. Title : HTTP Strict Transport Security (HSTS) Author(s) : Jeff Hodges Collin Jackson Adam Barth Filename : draft-ietf-websec-strict-transport-sec-09.txt Pages : 47 Date : 2012-06-06 This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections, and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field, and/or by other means, such as user agent configuration, for example. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-= 09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-websec-strict-transport-sec-0= 9.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport-sec/ From wwwrun@rfc-editor.org Fri Jun 8 06:01:13 2012 Return-Path: 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 3FF1621F889B for ; Fri, 8 Jun 2012 06:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 fcgiTyvtwWj6 for ; Fri, 8 Jun 2012 06:01:12 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C734221F8872 for ; Fri, 8 Jun 2012 06:01:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9F43C621A0; Fri, 8 Jun 2012 05:59:55 -0700 (PDT) To: ietf@adambarth.com, barryleiba@computer.org, presnick@qualcomm.com, tobias.gondrom@gondrom.org, alexey.melnikov@isode.com From: RFC Errata System Message-Id: <20120608125956.9F43C621A0@rfc-editor.org> Date: Fri, 8 Jun 2012 05:59:55 -0700 (PDT) Cc: annevk@annevk.nl, websec@ietf.org, rfc-editor@rfc-editor.org Subject: [websec] [Technical Errata Reported] RFC6454 (3249) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 08 Jun 2012 13:01:13 -0000 The following errata report has been submitted for RFC6454, "The Web Origin Concept". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6454&eid=3249 -------------------------------------- Type: Technical Reported by: Anne van Kesteren Section: 7.1. Syntax Original Text ------------- origin = "Origin:" OWS origin-list-or-null OWS origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list origin-list = serialized-origin *( SP serialized-origin ) Corrected Text -------------- origin = "Origin:" OWS origin-or-null OWS origin-or-null = %x6E %x75 %x6C %x6C / serialized-origin Notes ----- Rationale: List of origins was added for CORS http://www.w3.org/TR/cors/ but CORS does not require it and we should leave this as a choice. This syntax restriction also has limited impact on 7.2. and 7.3. See also: http://lists.w3.org/Archives/Public/www-archive/2012Jun/thread.html#msg1 Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6454 (draft-ietf-websec-origin-06) -------------------------------------- Title : The Web Origin Concept Publication Date : December 2011 Author(s) : A. Barth Category : PROPOSED STANDARD Source : Web Security Area : Applications Stream : IETF Verifying Party : IESG From Jeff.Hodges@KingsMountain.com Fri Jun 8 11:34:54 2012 Return-Path: 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 703AC21F8499 for ; Fri, 8 Jun 2012 11:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.371 X-Spam-Level: X-Spam-Status: No, score=-100.371 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 KiAPddafLhAS for ; Fri, 8 Jun 2012 11:34:53 -0700 (PDT) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 70E8921F8497 for ; Fri, 8 Jun 2012 11:34:53 -0700 (PDT) Received: (qmail 24217 invoked by uid 0); 8 Jun 2012 18:34:52 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy8.bluehost.com with SMTP; 8 Jun 2012 18:34:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=lo7FC3lBTyp+bfHMGE1amIrvlTX4h8LKXg4zDnoUkDw=; b=I/rmvJVZfnY5+d0fGRg4lSkGmQEWFUSNXzqXxlEx/sFnYWUuvRhcnWXoYd8PC0V1io6jru/peH0TPiNaaCBf+GmQ1Jp1btfvnyaEF1ZXwVl60DUbd1mmNKFjO+4ogWWw; Received: from [216.113.168.128] (port=36214 helo=[10.244.136.79]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Sd41M-0006Qn-Hz for websec@ietf.org; Fri, 08 Jun 2012 12:34:52 -0600 Message-ID: <4FD24634.10509@KingsMountain.com> Date: Fri, 08 Jun 2012 11:36:36 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] new rev: draft-ietf-websec-strict-transport-sec-09 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 08 Jun 2012 18:34:54 -0000 Howdy again, Please note that there are a fair number of non-trivial and/or nuanced changes in several places in draft-ietf-websec-strict-transport-sec-09 (relative to rev -06) in response to various folks' [1] reviews (thx! And thx to PaulH for his ack on -08 recently). It'd be great to get some acknowledgement that the changes meet expectations, especially those in these sections.. 6.1. Strict-Transport-Security HTTP Response Header Field 6.1.1. The max-age Directive 6.1.2. The includeSubDomains Directive 8.1. Strict-Transport-Security Response Header Field Processing 8.1.1. Noting a HSTS Host 8.2. Known HSTS Host Domain Name Matching 8.3. URI Loading and Port Mapping 9. Domain Name IDNA-Canonicalization 10.1. HSTS Policy expiration time considerations 10.2. Using HSTS in conjunction with self-signed public-key certificates 11.4. Disallow Mixed Security Context Loads 14. Security Considerations (just the new intro paragraphs) 14.6. Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack Appendix A. Design Decision Notes There are also (editorial) changes in several other sections. I believe these changes address issue tickets #s: 33, 37, 39, 40, 43, 44, 45, and 46. I'll be closing these tickets soon unless issues are raised. Please also see the change log below. This URI will get you a side-by-side diff between -06 and -09.. https://tools.ietf.org/rfcdiff?url1=draft-ietf-websec-strict-transport-sec-06.txt&url2=draft-ietf-websec-strict-transport-sec-09.txt thanks, =JeffH [1] Alexey M. Julian R. Murray K. Paul Hoffman Peter StA Tobias G. Barry L. ============================================================== Appendix D. Change Log [RFCEditor: please remove this section upon publication as an RFC.] Changes are grouped by spec revision listed in reverse issuance order. D.1. For draft-ietf-websec-strict-transport-sec Changes from -08 to -09: 1. Added IESG Note to Section 3 "Conformance Criteria" per Barry Leiba's suggestion on the mailing list. 2. Added additional requirement #5 to requirements for STS header field directives in Section 6.1 per Alexey's review. This completes the addressing of issue ticket #45. 3. Addressed editorial feedback in Murray's AppsDir review of -06. Most all of these changes were addressing detailed/small editorial items, however note the addition of a couple of introductory paragraphs in the Security Considerations section, as well as a re-written and expanded Section 14.6 "Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack", as well the new item #5 to Appendix A "Design Decision Notes". This addresses issue ticket #46. Changes from -07 to -08: 1. Clarified requirement #4 for STS header field directives in Section 6.1, and removed "(which "update" this specification)". Also added explicit "max-age=0" to Section 6.1.1. Reworked final sentence in 2nd para of Section 13. This addresses issue ticket #45. Changes from -06 to -07: 1. Various minor/modest editorial tweaks throughout as I went through it pursuing the below issue tickets. Viewing a visual diff against -06 revision recommended. 2. fixed some minor editorial issues noted in review by Alexey, fixes noted in here: 3. Addressed ABNF exposition issues, specifically inclusion of quoted-string syntax for directive values. Fix STS header ABNF such that a leading ";" isn't required. Add example of quoted-string-encoded max-age-value. This addresses (re- opened) issue ticket #33. 4. Reworked sections 8.1 through 8.3 to ensure matching algorithm and resultant HSTS Policy application is more clear, and that it is explicitly stipulated to not muck with attributes of superdomain matching Known HSTS Hosts. This addresses issue ticket #37. 5. Added reference to [I-D.ietf-dane-protocol], pared back extraneous discussion in section 2.2, and updated discussion in 10.2 to accomodate TLSA (nee DANE). This addresses issue ticket #39. 6. Addressed various editorial items from issue ticket #40. 7. Loosened up the language regarding redirecting "http" requests to "https" in section 7.2 such that future flavors of permanent redirects are accommodated. This addresses issue ticket #43. 8. Reworked the terminology and language in Section 9, in particular defining the term "putative domain name string" to replace "valid Unicode-encoded string-serialized domain name". This addresses issue ticket #44. Changes from -05 to -06: . . . . --- end From palmer@google.com Fri Jun 8 16:00:23 2012 Return-Path: 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 6D7F611E80AA for ; Fri, 8 Jun 2012 16:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 fPa4e4+bCVnL for ; Fri, 8 Jun 2012 16:00:22 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4404411E8091 for ; Fri, 8 Jun 2012 16:00:21 -0700 (PDT) Received: by lagv3 with SMTP id v3so2143966lag.31 for ; Fri, 08 Jun 2012 16:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=zCbeuP8+8eC/mRQQdf6+EtGsv2n1fNI1SKtAn4SBVZY=; b=UhrzPyyuyydimCtsWvSuom9wpf6zrOwH10FeX1pQwSulyyFIJIov5Yy0Q/ExgiR2OD pVNc42VtDdijOvfEOQo4efpwX3TXk4Y3QvY4NDHonKWqbRmcG5g9O0+TnVC1C75CaXDK tvmjdhNoe29cbP3nXWw9rrx0r/OHQktDF5fciPxxZhOPVmH/U5RF8RGQXb637ZJobzut yeTW/CSvN1K7I+SE5/pbH0D5rwOb1+AnhzGMThqF+kTW3Iac6KYvvxoIJzDwckDBdPU3 jvAVoU9IjK4bPWjDSQqTL/88l/t7p5yygZYVzelJnvZDm3l8j94ddHkpmM9CYrjGhWZ4 zxkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=zCbeuP8+8eC/mRQQdf6+EtGsv2n1fNI1SKtAn4SBVZY=; b=KTCSU0b7zkvqRFfCUd71y29yxOF01CfUxrm1j3B1z9WK++S3Z9Nne8hn73wgQtTRsR juhqO7Sgqm/xD/5B6plpko+XOQmR892igE3jpJpnYBWMc94CGUE4IQEXRZt8Y0e6O+Kz igxeGOhIbVNT+wTaBYEgewi2zUkMDhFS2NZAU4BlYN1Rcfq+mFcBRT/LHdP0nOUsWJHb U4RfWpuK8gAmZYKwNggFwr7kGgWvuuE92WpZnPJHgqn8Nq6pey4gA6uCML4PX+U8vgSy zuDNqija/ua+YGJqkdBwHWd1SLPCdHh5p5bje+bOZ/l8EVD8MnvSkd5zFfan5bMx7Ngf 1glw== Received: by 10.152.112.138 with SMTP id iq10mr10082592lab.13.1339196421131; Fri, 08 Jun 2012 16:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.112.138 with SMTP id iq10mr10082585lab.13.1339196421017; Fri, 08 Jun 2012 16:00:21 -0700 (PDT) Received: by 10.112.36.69 with HTTP; Fri, 8 Jun 2012 16:00:20 -0700 (PDT) In-Reply-To: <4FCD210C.2080807@cs.tcd.ie> References: <20120604183532.20788.10190.idtracker@ietfa.amsl.com> <4FCD210C.2080807@cs.tcd.ie> Date: Fri, 8 Jun 2012 16:00:20 -0700 Message-ID: From: Chris Palmer To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmp7y8EwNLMLELTs2QSOlQ53htEeKoBep4a9l6xlBNXJf8t/RGZHAY7LAH5ajaudkUvP3WewnSHqkbjbwMmfH8E6Y+bGTEOrru4IC9mCDgYl+FKZbXbwM7SSTo7PB9DVvgcBcXT Cc: websec@ietf.org Subject: Re: [websec] I-D Action: draft-ietf-websec-key-pinning-02.txt X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 08 Jun 2012 23:00:23 -0000 On Mon, Jun 4, 2012 at 1:56 PM, Stephen Farrell wrote: > draft-farrell-decade-ni-07 [1] defines ways to name things with > hashes that could be used here. [...] > > So: any interest in that? I'm not ignoring you, it's just that I've been busy with other things this week. I'll read your draft and think about it! From Jeff.Hodges@KingsMountain.com Tue Jun 12 00:00:46 2012 Return-Path: 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 87F3921F8513 for ; Tue, 12 Jun 2012 00:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.081 X-Spam-Level: X-Spam-Status: No, score=-98.081 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 kDKmLjLrjrl9 for ; Tue, 12 Jun 2012 00:00:45 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id A2E1C21F8512 for ; Tue, 12 Jun 2012 00:00:45 -0700 (PDT) Received: (qmail 24161 invoked by uid 0); 12 Jun 2012 07:00:45 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 12 Jun 2012 07:00:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=QuSbn4348meQRBA+WMF75zlemHknLVSKeAp0WUNrrfo=; b=N1lrz42wuTebevURJyxFtrgpDLkKbt7tPhfTkUzI8SkW+Ym3FPAPYcOcRO27AM1U+THvw/gqCvIQSO9n0ScwycX0ZGHugf2KyyFSViML77DskUtYffb6uKrr9oilZcyM; Received: from [24.4.122.173] (port=50809 helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SeL5o-0002VV-PO; Tue, 12 Jun 2012 01:00:44 -0600 Message-ID: <4FD6E91B.2000602@KingsMountain.com> Date: Tue, 12 Jun 2012 00:00:43 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yoav Nir , IETF WebSec WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] Issue #41 add parameter indicating whether to hardfail or not X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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, 12 Jun 2012 07:00:46 -0000 Hi, thanks for your thoughts Yoav, apologies for latency, > I guess my issue with this.. ..where "this" is denying the user the capability to "click-through" TLS/SSL errors/warnings in all error cases.. > ..is because when I read the draft for the first > time, I thought this would be a good idea for websites that only do HTTPS and > do not do HTTP except to redirect to HTTPS. I thought it would allow them to > signal this information, and allow them to defeat HTTP-based MiTM attacks. Yes, that is exactly the benefit the spec provides. > The > draft as it stands is not a good fit for this use case, because it requires > more of the administrator than is currently reasonable to expect. If an admin is uncertain about their keeping their TLS/SSL certificate deployment up-to-date, then they shouldn't declare themselves as an HSTS Host. And, they shouldn't have themselves listed on Chrome's HSTS pre-loaded list, nor the upcoming Firefox one. > I could propose an "HSTS-light" header for this use case, but I don't think > anybody would like to have that. Yeah, I'm not sure that's necessary, because what we're talking about here really is whether the user is offered obvious recourse to proceed with loading the web app in the face of TLS/SSL errors -- i.e., to be allowed to "click through" -- and in most (all?) browsers, the user is allowed to recourse to click through many TLS/SSL errors. So in some sense it is the status quo for a plain old non-HSTS web app. In the Paris WG session, the discussion of the above morphed to thinking about having a new "this site is testing HSTS" directive. In thinking about this, we don't think it is really necessary because if one declares one's web app as being HSTS, one can watch server logs to see if any requests come in over plain http, and then go track those issues down. You don't really need the user agent's help to figure out what is happening. It's just going to mechanically transform all http URIs pointing to your site into https ones, and try to load them, and if they 404, you'll know it (via your logs). It's arguably different with Content Security Policy (CSP) -- which is where the discussed notion came from ("report-only") -- because in CSP, the user agent is enforcing policy on loaded content within itself and there may be no other way to figure out what it's doing. HTH, =JeffH From trac+websec@trac.tools.ietf.org Tue Jun 12 11:15:26 2012 Return-Path: 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 8C03C21F859A for ; Tue, 12 Jun 2012 11:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_66=0.6, 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 JUxuHpowezZp for ; Tue, 12 Jun 2012 11:15:24 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED6021F858A for ; Tue, 12 Jun 2012 11:15:24 -0700 (PDT) Received: from localhost ([127.0.0.1]:43714 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SeVcG-0007y3-6K; Tue, 12 Jun 2012 20:14:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, julian.reschke@gmx.de X-Trac-Project: websec Date: Tue, 12 Jun 2012 18:14:56 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/33#comment:6 Message-ID: <085.016a4ed00e0a50cfce8be874d879979e@trac.tools.ietf.org> References: <070.dc46fc06c043a8103369b4b2f8b4d471@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <070.dc46fc06c043a8103369b4b2f8b4d471@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, julian.reschke@gmx.de, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120612181524.9ED6021F858A@ietfa.amsl.com> Resent-Date: Tue, 12 Jun 2012 11:15:24 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #33: HSTS: quoted-string grammar in (extension) directives ? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:15:26 -0000 #33: HSTS: quoted-string grammar in (extension) directives ? #choose ticket.new #when True (extension) directives are defined having this grammar.. token [ "=" ( token | quoted-string ) ] There is an argument against having quoted-string as part of the grammar. Justification is presented primarily in these messages.. https://www.ietf.org/mail-archive/web/websec/current/msg00781.html (Adam Barth) https://www.ietf.org/mail-archive/web/websec/current/msg00920.html (Adam Barth) ..but also in other messages in the same thread. Nominal summary of argument against inclusion of quoted-string is.. * presently-defined STS header directives don't employ quoted-string syntax * supporting use of quoted-string syntax raises questions of handling error conditions such as unbalanced quotation marks. * present HSTS implementations don't parse quoted-string STS directive values (e.g. max-age="13425") Argument for having quoted-string as a part of the grammar is.. * centered around HTTP header field consistency -- the generic header field syntax in RFC2616 (as well as in the in-progress httpbis update) incorporates quoted-string syntax as a part of header field value components. * because the HSTS header field grammar is extensible, and new directives can be defined in the future which may (need to) use quoted-string syntax. ..as noted here.. https://www.ietf.org/mail-archive/web/websec/current/msg00774.html (Julian Reschke) https://www.ietf.org/mail-archive/web/websec/current/msg00933.html (Julian Reschke) #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: reopened => closed * resolution: => fixed * severity: Active WG Document => In WG Last Call #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in =07 #end #end #end -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: major | Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Jun 12 11:21:19 2012 Return-Path: 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 C556921F864C for ; Tue, 12 Jun 2012 11:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_66=0.6, 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 7oz+VgYIpEUJ for ; Tue, 12 Jun 2012 11:21:19 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id CA60921F8643 for ; Tue, 12 Jun 2012 11:21:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:45839 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SeViF-00027l-OU; Tue, 12 Jun 2012 20:21:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 12 Jun 2012 18:21:07 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/39#comment:1 Message-ID: <085.3093691674eb980aec6693c340df227d@trac.tools.ietf.org> References: <070.8c5375186013134e689ba7b15f8ec943@trac.tools.ietf.org> X-Trac-Ticket-ID: 39 In-Reply-To: <070.8c5375186013134e689ba7b15f8ec943@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120612182118.CA60921F8643@ietfa.amsl.com> Resent-Date: Tue, 12 Jun 2012 11:21:18 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #39: appropriately acknowlege and accommodate DANE X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:21:19 -0000 #39: appropriately acknowlege and accommodate DANE #choose ticket.new #when True see.. Re: [websec] WG Last Call on draft-ietf-websec-strict-transport-sec-06 until April-9 (paul hoffman) https://www.ietf.org/mail-archive/web/websec/current/msg01092.html This document pretends that the TLSA protocol from the DANE WG will not exist. This is a tad odd, given that TLSA is likely to be published a few weeks before HSTS. In specific, bullet 2 of section 2.2 and all of section 10.2 are written as if self-signed certificates will always cause HTST- compliant browsers to fail, even if those certificates cause matching when used with TLSA. Proposed replacements: 2. The UA terminates any secure transport connection attempts upon any and all secure transport errors or warnings, including those caused by a web application presenting a certificate that does chain to a trusted root or match a trusted certificate association from the TLSA protocol [I-D.draft-ietf-dane-protocol]. . . . If a web site/organization/enterprise is generating their own secure transport public-key certificates for web sites, and that organization's root certification authority (CA) certificate is not typically embedded by default in browser CA certificate stores, and if HSTS Policy is enabled on a site identifying itself using a self- signed certificate, and the certificate presented by the TLS server does not match a trusted certificate association from the TLSA protocol [I-D.draft-ietf-dane-protocol], then secure connections to that site will fail, per the HSTS design. This is to protect against various active attacks, as discussed above. However, if said organization strongly wishes to employ self-signed certificates, and their own CA in concert with HSTS, they can do so by deploying their root CA certificate to their users' browsers. They can also, in addition or instead, distribute to their users' browsers the end-entity certificate(s) for specific hosts. There are various ways in which this can be accomplished (details are out of scope for this specification). Once their root CA certificate is installed in the browsers, they may employ HSTS Policy on their site(s). Alternately, that organization can deploy the TLSA protocol; all browsers that also use TLSA will then be able to trust the self-signed certificates if it announced through TLSA. Note: Interactively distributing root CA certificates to users, e.g., via email, and having the users install them, is arguably training the users to be susceptible to a possible form of phishing attack, see Section 14.6 "Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack". #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new => closed * resolution: => fixed #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -07 #end #end #end -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: major | Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Jun 12 11:24:39 2012 Return-Path: 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 8F4A421F864A for ; Tue, 12 Jun 2012 11:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_66=0.6, 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 aKEExEDFEg93 for ; Tue, 12 Jun 2012 11:24:39 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E264C21F85C6 for ; Tue, 12 Jun 2012 11:24:38 -0700 (PDT) Received: from localhost ([127.0.0.1]:47104 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SeVlW-0005c2-H5; Tue, 12 Jun 2012 20:24:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 12 Jun 2012 18:24:30 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/37#comment:1 Message-ID: <082.d8f57bd071bc0cc49d717772feaf72e2@trac.tools.ietf.org> References: <067.4afd58f6d675d5bdb2f19d83a8c1d99a@trac.tools.ietf.org> X-Trac-Ticket-ID: 37 In-Reply-To: <067.4afd58f6d675d5bdb2f19d83a8c1d99a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120612182438.E264C21F85C6@ietfa.amsl.com> Resent-Date: Tue, 12 Jun 2012 11:24:38 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #37: Clarify that superdomain HSTS flag does not update max-age of subdomain's HSTS max-age and vice versa X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:24:39 -0000 #37: Clarify that superdomain HSTS flag does not update max-age of subdomain's HSTS max-age and vice versa #choose ticket.new #when True The case is the following: A UA notes a superdomain e.g. example.com as a Known HSTS Host, with "includeSubDomains". Then after that the UA also receives a HSTS header from subdomain foo.example.com (with or without "includeSubDomains") and new max-age (longer or shorter time). The point is in that case the HSTS timer of the superdomain (example.com) MUST NOT be changed (extended or shortened) to the timer used in the subdomain. In fact the UA MUST keep both timers in cache independently and if at some point either one of them is removed (be due to expiry or because of an update setting max-age=0), the second remaining HSTS value MUST still be kept intact and applied. This is mainly to prevent that a subdomain can invalidate the HSTS flag of the superdomain or make it expire and vice versa. #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new => closed * resolution: => fixed * severity: - => In WG Last Call #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -07 #end #end #end -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- tobias.gondrom@… | transport-sec@… Type: enhancement | Status: closed Priority: major | Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Jun 12 11:27:53 2012 Return-Path: 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 0B3AC21F845B for ; Tue, 12 Jun 2012 11:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_66=0.6, 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 FXVAdx2W0lCZ for ; Tue, 12 Jun 2012 11:27:52 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 0A48D21F8458 for ; Tue, 12 Jun 2012 11:27:52 -0700 (PDT) Received: from localhost ([127.0.0.1]:48446 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SeVod-0007mR-EP; Tue, 12 Jun 2012 20:27:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 12 Jun 2012 18:27:43 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/websec/trac/ticket/40#comment:2 Message-ID: <085.21e9b19aa328e6b29670a989b46f7960@trac.tools.ietf.org> References: <070.2b15f3c9acfbd2014856105820738ee9@trac.tools.ietf.org> X-Trac-Ticket-ID: 40 In-Reply-To: <070.2b15f3c9acfbd2014856105820738ee9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120612182752.0A48D21F8458@ietfa.amsl.com> Resent-Date: Tue, 12 Jun 2012 11:27:52 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #40: Various editorial comments on -06 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:27:53 -0000 #40: Various editorial comments on -06 #choose ticket.new #when True https://www.ietf.org/mail-archive/web/websec/current/msg01092.html - paul hoffman Editorial: "annunciate" (used a few times) is a fancy word for "announce". Maybe use the far more common word instead. In section 3.1, "suboptimal downside" is unclear. Is there an optimal downside? I suggest replacing it with "negative". The lead sentences in sections 11.2, 11.4, and 11.5 lack verbs; verbs are used in 11.1 and 11.3. This should be an easy fix. https://www.ietf.org/mail-archive/web/websec/current/msg01093.html - yoav nir Editorial: In the introduction 2nd paragraph it says "(although modulo other rules)". s/modulo/subject to/. Also, replace "annunciate" with "announce" or "indicate". Both the introduction and section 8.2 say the policy applies to "all TCP ports". Hosts have multiple TCP ports: for SSH as an example. I suggest we change to "all HTTP(S) ports" In the title of section 8.5, I think we can do without the word "Interstitially". Section 10.1 begins with "Server implementations and deploying web sites need to consider whether they are setting…". Searching for the alternative (because an implied "or not" doesn't work for this sentence) took me to the 4th paragraph of this section, and the top of page 21, which begins with "Or, whether they are setting". This won't make it past the RFC editor, but I think it should be rephrased earlier. Section 14.1 discusses a UA behind an SSL proxy and implies that such a connection will cause warning screens (without HSTS) or hard failures. Such a deployment would be considered a wrong deployment of an SSL proxy. Administrators usually configure the UAs that are managed, and give detailed instructions to the owners of UAs that are not managed, so that the CA used by the proxy is trusted. There should be no warnings and no hard failures. https://www.ietf.org/mail-archive/web/websec/current/msg01108.html StPeter Section 1: This specification also incorporates notions from [JacksonBarth2008] in that policy is applied on an "entire-host" basis: it applies to all TCP ports of the issuing host. Please make it clear that all TCP ports does not mean all application protocols, only HTTP on all ports where it might be offered (not only the ports registered with the IANA). Section 7.2 Does is make sense to mention that status code 308 might be appropriate in certain circumstances? See draft-reschke-http-status-308. Section 8.4 The HTTP-Equiv Element Attribute is defined in the HTML specification, so a reference would be helpful. Section 9 The phrase "valid Unicode-encoded string-serialized domain name" seems a bit strange, because we don't typically refer to Unicode as an encoding scheme. See RFC 6365 regarding such terminology. Section 11.1 I think the text about "no user recourse" conflates two things: showing a warning, and allowing the user to click through: "the user should not be presented with an explanatory dialog giving her the option to proceed." Would it be OK for a user agent to show an explanatory dialog but not provide an option to proceed? Is there a security reason to fail the connection without any explanation? Section 11.5 The note it worded a bit oddly (e.g., "it shouldn't be possible for an attacker to inject script..." might be better worded along the lines of "implementations need to guard against alowing an attacker to inject script..."). #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new => closed * resolution: => fixed #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -07 #end #end #end -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: minor | Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Jun 12 11:28:58 2012 Return-Path: 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 E0CAD21F84CD for ; Tue, 12 Jun 2012 11:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_66=0.6, 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 QECYltROzKV3 for ; Tue, 12 Jun 2012 11:28:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 62DCB21F84A2 for ; Tue, 12 Jun 2012 11:28:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:48962 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SeVpj-0003PP-Id; Tue, 12 Jun 2012 20:28:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, julian.reschke@gmx.de, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 12 Jun 2012 18:28:51 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/43#comment:2 Message-ID: <085.29501251e34db1229d624b96046557a0@trac.tools.ietf.org> References: <070.a272a1155a8eb877ff88d2ef3522188e@trac.tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <070.a272a1155a8eb877ff88d2ef3522188e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, julian.reschke@gmx.de, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120612182858.62DCB21F84A2@ietfa.amsl.com> Resent-Date: Tue, 12 Jun 2012 11:28:58 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #43: HSTS: cite draft-reschke-http-status-308 and mention HTTP status code 308 ? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:28:59 -0000 #43: HSTS: cite draft-reschke-http-status-308 and mention HTTP status code 308 ? #choose ticket.new #when True [ this issue is forked from http://trac.tools.ietf.org/wg/websec/trac/ticket/40 ] > https://www.ietf.org/mail-archive/web/websec/current/msg01108.html StPeter > > Section 7.2 > > Does is make sense to mention that status code 308 might be > appropriate in certain circumstances? See draft-reschke-http-status-308. #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new => closed * resolution: => fixed #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -07 #end #end #end -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: enhancement | Status: closed Priority: minor | Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Jun 12 11:30:40 2012 Return-Path: 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 8DB1921F8535 for ; Tue, 12 Jun 2012 11:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_66=0.6, 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 xz3457GD85Wl for ; Tue, 12 Jun 2012 11:30:39 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 93DCE21F84D8 for ; Tue, 12 Jun 2012 11:30:39 -0700 (PDT) Received: from localhost ([127.0.0.1]:49641 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SeVr9-0001Z3-DA; Tue, 12 Jun 2012 20:30:21 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 12 Jun 2012 18:30:19 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/44#comment:1 Message-ID: <085.87857f8376778c5b392a20575e850399@trac.tools.ietf.org> References: <070.91ab9f8dc677f5c51032c93d6182c32d@trac.tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <070.91ab9f8dc677f5c51032c93d6182c32d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120612183039.93DCE21F84D8@ietfa.amsl.com> Resent-Date: Tue, 12 Jun 2012 11:30:39 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #44: terminology for referring to complete domain name (FQDN) possibly containing IDN labels X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 18:30:40 -0000 #44: terminology for referring to complete domain name (FQDN) possibly containing IDN labels #choose ticket.new #when True [ this issue is forked from http://trac.tools.ietf.org/wg/websec/trac/ticket/40 ] https://www.ietf.org/mail-archive/web/websec/current/msg01108.html StPeter > Section 9 > > The phrase "valid Unicode-encoded string-serialized domain name" seems > a bit strange, because we don't typically refer to Unicode as an > encoding scheme. See RFC 6365 regarding such terminology. #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new => closed * resolution: => fixed #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -07 #end #end #end -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: major | Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Jun 12 12:42:50 2012 Return-Path: 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 6415D21F8592 for ; Tue, 12 Jun 2012 12:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_66=0.6, 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 us3guU6apfhr for ; Tue, 12 Jun 2012 12:42:50 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7302521F8587 for ; Tue, 12 Jun 2012 12:42:49 -0700 (PDT) Received: from localhost ([127.0.0.1]:55592 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SeWyy-0000uo-11; Tue, 12 Jun 2012 21:42:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 12 Jun 2012 19:42:27 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/45#comment:3 Message-ID: <085.4ef878b210f2bd72d9caedf8e5a5ed81@trac.tools.ietf.org> References: <070.9239929b63486d786104bf07dca8f63e@trac.tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <070.9239929b63486d786104bf07dca8f63e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120612194249.7302521F8587@ietfa.amsl.com> Resent-Date: Tue, 12 Jun 2012 12:42:49 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #45: HSTS: Alexey's editorial comments on -06 X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 19:42:50 -0000 #45: HSTS: Alexey's editorial comments on -06 #choose ticket.new #when True See.. Re: [websec] Review of draft-ietf-websec-strict-transport-sec-06.txt https://www.ietf.org/mail-archive/web/websec/current/msg01173.html #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new => closed * resolution: => fixed #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -08 & -09 #end #end #end -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: minor | Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From trac+websec@trac.tools.ietf.org Tue Jun 12 12:49:44 2012 Return-Path: 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 1646721F86F0 for ; Tue, 12 Jun 2012 12:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.399 X-Spam-Level: X-Spam-Status: No, score=-101.399 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_66=0.6, 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 mzFUgN56nDZB for ; Tue, 12 Jun 2012 12:49:43 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 566B321F86D8 for ; Tue, 12 Jun 2012 12:49:43 -0700 (PDT) Received: from localhost ([127.0.0.1]:55853 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SeX5q-0008L9-DW; Tue, 12 Jun 2012 21:49:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "websec issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com X-Trac-Project: websec Date: Tue, 12 Jun 2012 19:49:34 -0000 X-URL: http://tools.ietf.org/websec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/46#comment:1 Message-ID: <085.61cdc2eece9f7995c90e556450fbedbf@trac.tools.ietf.org> References: <070.4eddcfcdc5893029bfcf92fdbf76a8f2@trac.tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <070.4eddcfcdc5893029bfcf92fdbf76a8f2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120612194943.566B321F86D8@ietfa.amsl.com> Resent-Date: Tue, 12 Jun 2012 12:49:43 -0700 (PDT) Resent-From: trac+websec@trac.tools.ietf.org Cc: websec@ietf.org Subject: Re: [websec] #46: HSTS: AppsDir Editorial comments X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 19:49:44 -0000 #46: HSTS: AppsDir Editorial comments #choose ticket.new #when True Editorial ("minor issues") noted in Murray Kucherawy's AppsDir review.. [websec] AppsDir review of draft-ietf-websec-strict-transport-sec https://www.ietf.org/mail-archive/web/websec/current/msg01147.html #end #otherwise #if changes_body Changes (by jeff.hodges@…): * status: new => closed * resolution: => fixed #end #if changes_descr #if not changes_body and not change.comment and change.author Description changed by jeff.hodges@…: #end -- #end #if change.comment Comment: fixed in -09 #end #end #end -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict- jeff.hodges@… | transport-sec@… Type: defect | Status: closed Priority: minor | Milestone: Component: strict- | Version: transport-sec | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: websec From Jeff.Hodges@KingsMountain.com Thu Jun 14 18:06:48 2012 Return-Path: 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 561B021F847F for ; Thu, 14 Jun 2012 18:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.081 X-Spam-Level: X-Spam-Status: No, score=-98.081 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 zwZqftZc11Gl for ; Thu, 14 Jun 2012 18:06:47 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 5B34121F847C for ; Thu, 14 Jun 2012 18:06:47 -0700 (PDT) Received: (qmail 32017 invoked by uid 0); 15 Jun 2012 01:06:46 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 15 Jun 2012 01:06:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=9D34MOr02shvmckerP6MJoCVZApCM6Ksy3rkF9QKLA4=; b=rdcZ6+8Zeju1Nsv+82zqGAh5EwUbzUuJwBoHM4Kq3Dxbif1BSVod5rY5XUAkZrWTR/5qLffi5pDF+Yf4Bjkb659TOKKt9RgEE6CuFYTTrIeKlweuzIYYsbPMWdhTLg46; Received: from [24.4.122.173] (port=38945 helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SfKzu-00054b-5L; Thu, 14 Jun 2012 19:06:46 -0600 Message-ID: <4FDA8AA4.5060205@KingsMountain.com> Date: Thu, 14 Jun 2012 18:06:44 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 01:06:48 -0000 > 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 From tobias.gondrom@gondrom.org Sat Jun 16 12:19:20 2012 Return-Path: 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 ; 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 ; 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 ; 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 19:19:20 -0000 +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 From alexey.melnikov@isode.com Sun Jun 17 02:46:37 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 Date: Sun, 17 Jun 2012 10:46:27 +0100 To: Tobias Gondrom MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2012 09:46:37 -0000 On 16 Jun 2012, at 20:19, Tobias Gondrom wrote:= > 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 b= est answer here. Exceptions are bad (hard to handle properly). >=20 > Best regards, Tobias >=20 > On 15/06/12 02:06, =3DJeffH wrote: >> > This is about fetching CRLs from a domain that happens to be the same a= s >> > 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. Differe= nt >> > resources from the same domain should all be protected by TLS. But we d= on't >> > expect this to affect things that are outside the browser, like email o= r >> > system updates. IMO the fetching of CRLs or OCSP responses is not part o= f >> > the browsing, but part of the HTTPS handshake. The fact that some brows= ers >> > implement both is besides the point. Internet Explorer uses an OS libra= ry to >> > do the TLS handshake, including any checking of revocation. In fact get= ting >> > the CRL fetch function to apply the HSTS policy would require extra eff= ort >> > 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 shou= ld >> > not apply to it. >>=20 >> Unfortunately, we would then have to define what comprises "content", and= that's a huge rathole I think we should unequivocally avoid. >>=20 >> I've taken a (ad-hoc, limited, unscientific) look at the AIA and CDP in s= ome existing certificates (from major CAs), and all of the ones I checked us= ed a dedicated subdomain for their OCSP responder, e.g... >>=20 >> evsecure-crl.verisign.com >> evsecure-ocsp.verisign.com >> SVRSecure-G3-crl.verisign.com >> ocsp.verisign.com >> ocsp.thawte.com >> crl.thawte.com >>=20 >>=20 >> So in order not to cause themselves and their customers problems, CAs sim= ply 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 t= he HSTS draft. >>=20 >> HTH, >>=20 >> =3DJeffH From tobias.gondrom@gondrom.org Mon Jun 18 10:41:27 2012 Return-Path: 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 B8BB621F86C1 for ; Mon, 18 Jun 2012 10:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.715 X-Spam-Level: X-Spam-Status: No, score=-100.715 tagged_above=-999 required=5 tests=[AWL=-3.937, BAYES_00=-2.599, 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 3wY6MlRBgXaw for ; Mon, 18 Jun 2012 10:41:27 -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 B492321F86B4 for ; Mon, 18 Jun 2012 10:41:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=nRLKaXneKJ0Jw9qXG8H34BWwaCaNroRtDT3PYJ62iqBvPe3cCL+vPcmnB0O8h/cdVWKshwz9umrQUmoX5+e6q+P2I7t/I/Rmw8DmR5WZovoBFv2d/xlj5/JhAMV7yRBr; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 22455 invoked from network); 18 Jun 2012 19:41:12 +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; 18 Jun 2012 19:41:12 +0200 Message-ID: <4FDF6837.1090401@gondrom.org> Date: Mon, 18 Jun 2012 18:41:11 +0100 From: Tobias Gondrom 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 X-Priority: 2 (High) References: <4FB5608E.60409@KingsMountain.com> In-Reply-To: <4FB5608E.60409@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] draft-ietf-websec-strict-transport-sec-09 - 2nd WGLC to close on June-25 18:00 UTC X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 18 Jun 2012 17:41:30 -0000 Hello dear websec fellows, after our meeting in Paris, there was very good activity and comments and it seems most of them have been closed and the previous WGLC on the draft finished. To my understanding only #41 and #42 are still open to be discussed: http://trac.tools.ietf.org/wg/websec/trac/query?status=!closed&component=strict-transport-sec As from version -07 to -09, the draft received editorial changes and some changes to the ABNF and we still have these two issues open, I would like to encourage all to raise and discuss their issues now, so we can progress to IETF Last Call. Latest version of the draft is here: http://trac.tools.ietf.org/html/draft-ietf-websec-strict-transport-sec-09 I hereby initiate the second Working Group Last Call on this draft to be closed by June-25, 18:00 UTC. Please raise any still outstanding issues ASAP and discuss them until that date. If we can resolve all open issues by then, I will progress the draft to IESG for IETF LC. Best regards, Tobias From tobias.gondrom@gondrom.org Mon Jun 18 11:01:33 2012 Return-Path: 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 AE1FB21F86E5 for ; Mon, 18 Jun 2012 11:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.153 X-Spam-Level: X-Spam-Status: No, score=-101.153 tagged_above=-999 required=5 tests=[AWL=-2.375, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, GB_I_INVITATION=-2, 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 H114c4BxM24D for ; Mon, 18 Jun 2012 11:01:33 -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 80ED821F86EB for ; Mon, 18 Jun 2012 11:01:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=dDz3iayGazq7VGTkk7MQkyhwxKDpL5uQ71VPxIEzWEg0fsGkxHAPluDWMyehdjMH5FbMuxPQ2i4Ate38umLr+0xWXZjX/VxKPSwy5zY/bbss75lgTFkMX+9xgBghkk0e; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 23562 invoked from network); 18 Jun 2012 20:01:31 +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; 18 Jun 2012 20:01:31 +0200 Message-ID: <4FDF6CFA.3090705@gondrom.org> Date: Mon, 18 Jun 2012 19:01:30 +0100 From: Tobias Gondrom 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 X-Priority: 2 (High) References: <4FD6E91B.2000602@KingsMountain.com> In-Reply-To: <4FD6E91B.2000602@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [websec] Comments on "I am testing HSTS"-directive and Issue #41 add parameter "hardfail=no"? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Mon, 18 Jun 2012 18:01:33 -0000 Hello all, I would like to ask for feedback/opinions from the WG on this draft regarding the following open issue: - in Paris we had a discussion about whether HSTS header should specify a "I am testing HSTS" directive. There was some support for this in the room but no consensus. I would like to make a final invitation for comments/views/opinions on this? - And as this is somehow related: the still open #41: should HSTS have an option like "hardfail=no"? Our meeting discussion in Paris did not show consensus in support of this. and just in case anyone wants to read up on our meeting minutes from Paris: http://www.ietf.org/proceedings/83/minutes/minutes-83-websec.txt Best regards, Tobias On 12/06/12 08:00, =JeffH wrote: > Hi, thanks for your thoughts Yoav, apologies for latency, > > > I guess my issue with this.. > > ..where "this" is denying the user the capability to "click-through" > TLS/SSL errors/warnings in all error cases.. > > > ..is because when I read the draft for the first > > time, I thought this would be a good idea for websites that only do > HTTPS and > > do not do HTTP except to redirect to HTTPS. I thought it would allow > them to > > signal this information, and allow them to defeat HTTP-based MiTM > attacks. > > Yes, that is exactly the benefit the spec provides. > > > > The > > draft as it stands is not a good fit for this use case, because it > requires > > more of the administrator than is currently reasonable to expect. > > If an admin is uncertain about their keeping their TLS/SSL certificate > deployment up-to-date, then they shouldn't declare themselves as an > HSTS Host. > > And, they shouldn't have themselves listed on Chrome's HSTS pre-loaded > list, nor the upcoming Firefox one. > > > > I could propose an "HSTS-light" header for this use case, but I > don't think > > anybody would like to have that. > > Yeah, I'm not sure that's necessary, because what we're talking about > here really is whether the user is offered obvious recourse to proceed > with loading the web app in the face of TLS/SSL errors -- i.e., to be > allowed to "click through" -- and in most (all?) browsers, the user is > allowed to recourse to click through many TLS/SSL errors. So in some > sense it is the status quo for a plain old non-HSTS web app. > > > In the Paris WG session, the discussion of the above morphed to > thinking about having a new "this site is testing HSTS" directive. > > In thinking about this, we don't think it is really necessary because > if one declares one's web app as being HSTS, one can watch server logs > to see if any requests come in over plain http, and then go track > those issues down. You don't really need the user agent's help to > figure out what is happening. It's just going to mechanically > transform all http URIs pointing to your site into https ones, and try > to load them, and if they 404, you'll know it (via your logs). > > It's arguably different with Content Security Policy (CSP) -- which is > where the discussed notion came from ("report-only") -- because in > CSP, the user agent is enforcing policy on loaded content within > itself and there may be no other way to figure out what it's doing. > > HTH, > > =JeffH > > > > > > > > > > > > > > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From Jeff.Hodges@KingsMountain.com Wed Jun 20 10:53:16 2012 Return-Path: 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 D44C121F870F for ; Wed, 20 Jun 2012 10:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 uMhFmsrWQ79I for ; Wed, 20 Jun 2012 10:53:16 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 16AD421F86F0 for ; Wed, 20 Jun 2012 10:53:15 -0700 (PDT) Received: (qmail 6526 invoked by uid 0); 20 Jun 2012 17:53:15 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 20 Jun 2012 17:53:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=HjQ7P5fzMxZEgrdlM7K5YgMe637JDHh/fXppejvw7Xs=; b=ScBFM/ySu+5IdvFT8Qdp369kf3i86p6xrLYxNRkI+cCBVc3TZISuD/CyYbv8gQ9LGUHGp4M7b0uWOfQAJwMIUJLomvSn2Rm7tATC56RCw/HBLP/hTxcJn5jW8nEssou6; Received: from [216.113.168.128] (port=11047 helo=[10.244.136.109]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1ShP5e-0001sr-Uw for websec@ietf.org; Wed, 20 Jun 2012 11:53:14 -0600 Message-ID: <4FE20E0A.8030603@KingsMountain.com> Date: Wed, 20 Jun 2012 10:53:14 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] Comments on "I am testing HSTS"-directive and Issue #41 add parameter "hardfail=no"? X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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, 20 Jun 2012 17:53:17 -0000 Hi, Tobias wrote.. > > I would like to ask for feedback/opinions from the WG on this draft > regarding the following open issue: > > - in Paris we had a discussion about whether HSTS header should specify > a "I am testing HSTS" directive. There was some support for this in the > room but no consensus. ptr to meeting minutes below at [1]. > I would like to make a final invitation for comments/views/opinions on this? Please also note that I comment on this near the end of this recent message.. Re: [websec] Issue #41 add parameter indicating whether to hardfail or not https://www.ietf.org/mail-archive/web/websec/current/msg01213.html Here's what I wrote in that msg: In the Paris WG session, the discussion of the above morphed to thinking about having a new "this site is testing HSTS" directive. In thinking about this, we don't think it is really necessary because if one declares one's web app as being HSTS, one can watch server logs to see if any requests come in over plain http, and then go track those issues down. You don't really need the user agent's help to figure out what is happening. It's just going to mechanically transform all http URIs pointing to your site into https ones, and try to load them, and if they 404, you'll know it (via your logs). It's arguably different with Content Security Policy (CSP) -- which is where the discussed notion came from ("report-only") -- because in CSP, the user agent is enforcing policy on loaded content within itself and there may be no other way to figure out what it's doing. > - And as this is somehow related: > the still open #41: should HSTS have an option like "hardfail=no"? > Our meeting discussion in Paris did not show consensus in support of this. And I commented on that in the beginning of the above-mentioned message. HTH, =JeffH [1] > and just in case anyone wants to read up on our meeting minutes from Paris: > http://www.ietf.org/proceedings/83/minutes/minutes-83-websec.txt From alexey.melnikov@isode.com Fri Jun 29 05:20:17 2012 Return-Path: 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 5FFBF21F8712 for ; Fri, 29 Jun 2012 05:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.887 X-Spam-Level: X-Spam-Status: No, score=-102.887 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, 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 JZZdAr+xhbkL for ; Fri, 29 Jun 2012 05:20:16 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id EF3DD21F86FD for ; Fri, 29 Jun 2012 05:20:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340972399; d=isode.com; s=selector; i=@isode.com; bh=fHLEuKmW+7mLSG4cCozVxhQiYsskZ9LG+2VZij/Od3k=; 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=mAX8TxAmYo+t/sGad5d5mYFhS/YJqo9gbPEQQZYiHkix4AMFfHwiuRE9WRj/Om9j/o0/9d YEw6rEU59JgedtXx3hKX4c+jeM3TOvrRGVkKr5aunWZJvjwOgkzb9fbDo8DvCQ/tzR2uRT sT+WzZD70nBpSZYp0VCmoxfjD1ADDk8=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 29 Jun 2012 13:19:59 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FED9D7C.6010207@isode.com> Date: Fri, 29 Jun 2012 13:20:12 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: =JeffH References: <4FD6E91B.2000602@KingsMountain.com> In-Reply-To: <4FD6E91B.2000602@KingsMountain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: [websec] "This site is testing HSTS" directive (was Issue #41 add parameter indicating whether to hardfail or not) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Jun 2012 12:20:17 -0000 Hi Jeff, Sorry for even slower response. On 12/06/2012 08:00, =JeffH wrote: [...] > > I could propose an "HSTS-light" header for this use case, but I > don't think > > anybody would like to have that. > > Yeah, I'm not sure that's necessary, because what we're talking about > here really is whether the user is offered obvious recourse to proceed > with loading the web app in the face of TLS/SSL errors -- i.e., to be > allowed to "click through" -- and in most (all?) browsers, the user is > allowed to recourse to click through many TLS/SSL errors. So in some > sense it is the status quo for a plain old non-HSTS web app. > > > In the Paris WG session, the discussion of the above morphed to > thinking about having a new "this site is testing HSTS" directive. > > In thinking about this, we don't think it is really necessary because > if one declares one's web app as being HSTS, one can watch server logs > to see if any requests come in over plain http, and then go track > those issues down. You don't really need the user agent's help to > figure out what is happening. It's just going to mechanically > transform all http URIs pointing to your site into https ones, and try > to load them, and if they 404, you'll know it (via your logs). (Speaking as a WG participant, not as a co-chair.) I don't think relying just on server side logs is actually a good idea. You are effectively limiting who is able to debug the problem, which sometimes can be caused by things outside of direct webserver administrator control. Existence of "I am testing HSTS" directive would allow browsers to present debug information on HSTS succeeding/failing in some form (browser logs, additional debug frame, etc.) > It's arguably different with Content Security Policy (CSP) -- which is > where the discussed notion came from ("report-only") -- because in > CSP, the user agent is enforcing policy on loaded content within > itself and there may be no other way to figure out what it's doing. From ekr@rtfm.com Fri Jun 29 07:30:15 2012 Return-Path: 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 8AEC721F86F6 for ; Fri, 29 Jun 2012 07:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 vBDomWZ6Z-x8 for ; Fri, 29 Jun 2012 07:30:14 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9850E21F86E3 for ; Fri, 29 Jun 2012 07:30:14 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2566682vbb.31 for ; Fri, 29 Jun 2012 07:30:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=LMNtFKiHPuTgKwvWTpSs/MkHHQYLotfVlwx4ccL0TMk=; b=mwjF4tyWdjRazwG9cBs5Zh3j1mOigCPxRZI2bcjOTR8a3IhF9qPitqLWX6nt9dYZTo ZXN6Cf+AfjD9s3zBvWclk/xGVlY2U/Pys/SoTs+MKbHTfxgQP7jDs+PcJ3pGyMMgiWjd SeB9kYccoVUul2ULqEUYnYOtGOKfr/sknr6My7G5Ki3kgFbCFpglWt10GgBCBmhKil+O gWDHrfnMdMRXSCpVTDL54mSqr4lg1IyWO4Q4hqhHd67sPNYxiZfsrKF24mRevHXITZvi sbQWpu9XL7d4q4tBYEB/l5423AxljW5eTb7AJm7e60/a9Peg4rV1zASj9RKJz6IG313I iOuQ== Received: by 10.52.30.2 with SMTP id o2mr945218vdh.132.1340980214095; Fri, 29 Jun 2012 07:30:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 29 Jun 2012 07:29:28 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <4FD6E91B.2000602@KingsMountain.com> References: <4FD6E91B.2000602@KingsMountain.com> From: Eric Rescorla Date: Fri, 29 Jun 2012 07:29:28 -0700 Message-ID: To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlfw5CRBuh7ypdYtnA7D8z905DmXYWwl4ksM8MD/1CJmBVjd8dbduykAqjXRlTbFjsmxoSQ Cc: IETF WebSec WG Subject: Re: [websec] Issue #41 add parameter indicating whether to hardfail or not X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Jun 2012 14:30:15 -0000 On Tue, Jun 12, 2012 at 12:00 AM, =JeffH wrote: > Hi, thanks for your thoughts Yoav, apologies for latency, > >> I guess my issue with this.. > > ..where "this" is denying the user the capability to "click-through" TLS/SSL > errors/warnings in all error cases.. > >> ..is because when I read the draft for the first >> time, I thought this would be a good idea for websites that only do HTTPS >> and >> do not do HTTP except to redirect to HTTPS. I thought it would allow them >> to >> signal this information, and allow them to defeat HTTP-based MiTM attacks. > > Yes, that is exactly the benefit the spec provides. > > >> The >> draft as it stands is not a good fit for this use case, because it >> requires >> more of the administrator than is currently reasonable to expect. > > If an admin is uncertain about their keeping their TLS/SSL certificate > deployment up-to-date, then they shouldn't declare themselves as an HSTS > Host. > > And, they shouldn't have themselves listed on Chrome's HSTS pre-loaded list, > nor the upcoming Firefox one. > > >> I could propose an "HSTS-light" header for this use case, but I don't >> think >> anybody would like to have that. > > Yeah, I'm not sure that's necessary, because what we're talking about here > really is whether the user is offered obvious recourse to proceed with > loading the web app in the face of TLS/SSL errors -- i.e., to be allowed to > "click through" -- and in most (all?) browsers, the user is allowed to > recourse to click through many TLS/SSL errors. So in some sense it is the > status quo for a plain old non-HSTS web app. > > > In the Paris WG session, the discussion of the above morphed to thinking > about having a new "this site is testing HSTS" directive. > > In thinking about this, we don't think it is really necessary because if one > declares one's web app as being HSTS, one can watch server logs to see if > any requests come in over plain http, and then go track those issues down. The point of "this is testing" is the opposite: people who can't talk to you because you've configured HSTS in a way inconsistent with your actual site posture. -Ekr From asteingruebl@paypal-inc.com Fri Jun 29 08:10:57 2012 Return-Path: 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 89CAD21F86A6 for ; Fri, 29 Jun 2012 08:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 qtixvk6fJ-ZP for ; Fri, 29 Jun 2012 08:10:49 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id AD7C121F8615 for ; Fri, 29 Jun 2012 08:10:49 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=KyeGTPskRlC/JtvSmFPbL8JlqNWPFPkKGOo1h/GnxO+XyqeDp7icLb64 U2H0q/sRAhCB53cwhTHDsY0N1zRiE9i9s3+DeLfCB+3kEV2RjT3cdgkzJ GqKYINTmhtL8B11; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1340982650; x=1372518650; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BrKeWLaEvoaFJkD+ipZH8/Y7ADCWLzqdGaCQIwu2kEc=; b=UmI0+z+TfCtnRsebZQLuq6MhoCIWWhay/4hLO/cdZh99NpBj+Gr6bPgF d7zjPrH5gkn7XzG9tsBJaZLWaN6sI+xq7d/sJyP8Il7ux/juV5OmWNH5x WpyKW//elS7J3LA; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.77,498,1336374000"; d="scan'208";a="8389034" Received: from den-vtenf-001.corp.ebay.com (HELO DEN-EXMHT-004.corp.ebay.com) ([10.101.112.212]) by den-mipot-001.corp.ebay.com with ESMTP; 29 Jun 2012 08:10:49 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-004.corp.ebay.com ([fe80::a487:c570:9abc:bb59%14]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 09:10:42 -0600 From: "Steingruebl, Andy" To: Eric Rescorla , =JeffH Thread-Topic: [websec] Issue #41 add parameter indicating whether to hardfail or not Thread-Index: AQHNSGkgYOV2ID/j0kWG8soUgCgtdpcR2vAA//+l9xA= Date: Fri, 29 Jun 2012 15:10:42 +0000 Message-ID: <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com> References: <4FD6E91B.2000602@KingsMountain.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.19.245] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: Y2Ln0gToo+qeHmM0WHRC5Q== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: IETF WebSec WG Subject: Re: [websec] Issue #41 add parameter indicating whether to hardfail or not X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Jun 2012 15:10:57 -0000 > The point of "this is testing" is the opposite: people who can't talk to= you because you've configured HSTS in a way inconsistent with your=20 > actual site posture. > -Ekr Can you give us an example of how/where you think this could occur and how = it is distinct from other ways you could using existing technology kill you= r site? =20 As an admittedly snarky example you could easily public a bad A record in D= NS and you'd never see any traffic at all, but there isn't a "test new A re= cord flag" or "test new MX server" flag in the DNS. =20 We assume that as part of deploying HSTS people do some basic checks like m= ake sure their website actually responds over HTTPS and generates webserver= logs, and they know which domain they are publishing HSTS records for. Some specifics would help me a lot to understand the concerns. - Andy From alexey.melnikov@isode.com Fri Jun 29 09:24:58 2012 Return-Path: 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 C407421F877E for ; Fri, 29 Jun 2012 09:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.014 X-Spam-Level: X-Spam-Status: No, score=-103.014 tagged_above=-999 required=5 tests=[AWL=-0.415, BAYES_00=-2.599, 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 aLoMQOryEhbt for ; Fri, 29 Jun 2012 09:24:57 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 99E3121F8781 for ; Fri, 29 Jun 2012 09:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340987096; d=isode.com; s=selector; i=@isode.com; bh=vGAUQ+NzIgstrd2/vqMCdfyvSiAMJlQ73XxJJDAPLAU=; 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=QJTCFkzysUCifjWNsVLSfD2OYfL6RJm8dOhnOlnMNsJKjfy/jInDP84MoExblqDSwRYOJV yPhn9dcB1siMf1vrFVZw1UGLO/7jGPvLRTu5x0N6E7NT92whpSYvggncuoZe3zLS2kdoXo 0U0Kn87SdxtDr4N10BIQgAWvXyUD0h8=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 29 Jun 2012 17:24:56 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FEDD6D6.3070803@isode.com> Date: Fri, 29 Jun 2012 17:24:54 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "Steingruebl, Andy" References: <4FD6E91B.2000602@KingsMountain.com> <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] Issue #41 add parameter indicating whether to hardfail or not X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Jun 2012 16:24:58 -0000 On 29/06/2012 16:10, Steingruebl, Andy wrote: >> The point of "this is testing" is the opposite: people who can't talk to you because you've configured HSTS in a way inconsistent with your >> actual site posture. >> -Ekr > Can you give us an example of how/where you think this could occur and how it is distinct from other ways you could using existing technology kill your site? Maybe this is not a good example, but I am thinking that something like OCSP retrieval failing on the client side is not something that would show up in the webserver logs. > As an admittedly snarky example you could easily public a bad A record in DNS and you'd never see any traffic at all, but there isn't a "test new A record flag" or "test new MX server" flag in the DNS. There is however "I am testing DKIM" flag published in DNS. > We assume that as part of deploying HSTS people do some basic checks like make sure their website actually responds over HTTPS and generates webserver logs, and they know which domain they are publishing HSTS records for. > > Some specifics would help me a lot to understand the concerns. From asteingruebl@paypal-inc.com Fri Jun 29 09:45:50 2012 Return-Path: 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 A4A9221F87CB for ; Fri, 29 Jun 2012 09:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.117 X-Spam-Level: X-Spam-Status: No, score=-9.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, 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 AatPJFCQIlis for ; Fri, 29 Jun 2012 09:45:49 -0700 (PDT) Received: from den-mipot-001.corp.ebay.com (den-mipot-001.corp.ebay.com [216.113.175.152]) by ietfa.amsl.com (Postfix) with ESMTP id 83A8321F87C0 for ; Fri, 29 Jun 2012 09:45:39 -0700 (PDT) DomainKey-Signature: s=ppinc; d=paypal-inc.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: x-ems-proccessed:x-ems-stamp:Content-Type: Content-Transfer-Encoding:MIME-Version:X-CFilter; b=T7W4IBv4PxHlSaDoWloxDncgfLsaZzxGrmBAxf8IUmOHhf08JyUphR9N 0c4/HKN7NtmTY4PZEsqinZJLKAa/jmt9PoTAEuGMajqG5k8HVuHd9UBIV 60BMvZAMLzU0TGj; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paypal-inc.com; i=asteingruebl@paypal-inc.com; q=dns/txt; s=ppinc; t=1340988339; x=1372524339; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TwkpmLY05OEi0HqEOeGzn8fpbiVyiv/FXnjDLj4G8tE=; b=SYqgHFcgACoFhzJrGASJYt01yrGdTzGDob+YuEBNftmvn0Fr01462KR4 tMwYYRsd+Ho6jmcC6lbYdel5dCXlH4UY4dMN6/jxk3+9F0jiFu29N/hrv cwbJ6EbWsgYUjPM; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.77,498,1336374000"; d="scan'208";a="8391682" Received: from den-vtenf-002.corp.ebay.com (HELO DEN-EXMHT-003.corp.ebay.com) ([10.101.112.213]) by den-mipot-001.corp.ebay.com with ESMTP; 29 Jun 2012 09:45:38 -0700 Received: from DEN-EXDDA-S12.corp.ebay.com ([fe80::40c1:9cf7:d21e:46c]) by DEN-EXMHT-003.corp.ebay.com ([fe80::55d3:9d86:3fc8:dbf4%14]) with mapi id 14.02.0298.004; Fri, 29 Jun 2012 10:45:00 -0600 From: "Steingruebl, Andy" To: Alexey Melnikov Thread-Topic: [websec] Issue #41 add parameter indicating whether to hardfail or not Thread-Index: AQHNVhPrj0PSF/XP90aTde9APV917ZcRf6lQ Date: Fri, 29 Jun 2012 16:45:00 +0000 Message-ID: <1DFCCAFE421024488073B74EEA0173E1171F86@DEN-EXDDA-S12.corp.ebay.com> References: <4FD6E91B.2000602@KingsMountain.com> <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com> <4FEDD6D6.3070803@isode.com> In-Reply-To: <4FEDD6D6.3070803@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.241.19.245] x-ems-proccessed: 10SqDH0iR7ekR7SRpKqm5A== x-ems-stamp: iAWF6aytdvla/uPP3X/K1A== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter: Scanned Cc: IETF WebSec WG Subject: Re: [websec] Issue #41 add parameter indicating whether to hardfail or not X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Jun 2012 16:45:50 -0000 > -----Original Message----- > From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >=20 > Maybe this is not a good example, but I am thinking that something like > OCSP retrieval failing on the client side is not something that would > show up in the webserver logs. Sure, but doesn't the OCSP site know whether it has set HSTS? >=20 > There is however "I am testing DKIM" flag published in DNS. Yep, but here you may not know all your sources of email, all of the domain= s, senders, etc. you could have an outsourcer sending mail on your behalf= that you don't know about, haven't inventoried, etc. =20 For HSTS that can't be the case. For HSTS you do know exactly what domain/= host you're applying HSTS to. You don't necessarily know all of the inboun= d links, but you don't know that before HSTS an so you watch your weblogs f= or 404's for example to see typo'd links, inbound errors, etc. My contention is we already have this problem solved, and don't need a test= ing mode for it like this as there aren't any cases where the browser won't= at least try to connect, and you can have an endpoint there ready/willing/= able to listen to the request that is made. If nothing else you could put = up a packet sniffer. - Andy From ekr@rtfm.com Fri Jun 29 11:13:45 2012 Return-Path: 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 89CA821F8809 for ; Fri, 29 Jun 2012 11:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 oXDGZUABecmh for ; Fri, 29 Jun 2012 11:13:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F52A21F8714 for ; Fri, 29 Jun 2012 11:13:44 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2735533vbb.31 for ; Fri, 29 Jun 2012 11:13:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=V02W/vsHw8ubw0VPoWcgtYLUZHtKuCCCuDJ55PT+SP4=; b=MMhTMFFzk9HeihSguMMOtr6DmiBXkERj1EYJZF0V/7X5KNKHBD73i8uqSxui58Dgi4 blVCi77ha3QXhvOWG6BKZW0OOg21pyaAUnuSWoHe9YvFtszZE8Dg9l/AFmvNL4liwVYG kLkhZG+Ieou9xe34o3y28SxDCEccpRP9aawyBxKnYu0BCpokfj4ougRqPeQ2tGC7sj+/ dr2+yCUhqRNuPRagNs2Of/D+bQ9j7mKv4GtB9TaeyK4lZesHat3w7TLprXoTh8seijl2 eKG/EbmH7RHGc0FUVLGD2sX2rs86tWiomoYcnuv+jVPNXq5Ds7FuoaXOnkI0LsXiRwaL bz6Q== Received: by 10.52.100.229 with SMTP id fb5mr1308885vdb.102.1340993624092; Fri, 29 Jun 2012 11:13:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.209 with HTTP; Fri, 29 Jun 2012 11:13:03 -0700 (PDT) X-Originating-IP: [216.239.55.138] In-Reply-To: <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com> References: <4FD6E91B.2000602@KingsMountain.com> <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com> From: Eric Rescorla Date: Fri, 29 Jun 2012 11:13:03 -0700 Message-ID: To: "Steingruebl, Andy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmmrzsQ2USmxZtysWRWE+R6n2gkPOygUTC0u+OfvPM+z1X81nN+31VP8RvDfnW3IBzuoE1Q Cc: IETF WebSec WG Subject: Re: [websec] Issue #41 add parameter indicating whether to hardfail or not X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Jun 2012 18:13:45 -0000 On Fri, Jun 29, 2012 at 8:10 AM, Steingruebl, Andy wrote: >> The point of "this is testing" is =A0the opposite: people who can't talk= to you because you've configured HSTS in a way inconsistent with your >> actual site posture. >> -Ekr > > Can you give us an example of how/where you think this could occur and ho= w it is distinct from other ways you could using existing technology kill y= our site? > > As an admittedly snarky example you could easily public a bad A record in= DNS and you'd never see any traffic at all, but there isn't a "test new A = record flag" or "test new MX server" flag in the DNS. > > We assume that as part of deploying HSTS people do some basic checks like= make sure their website actually responds over HTTPS and generates webserv= er logs, and they know which domain they are publishing HSTS records for. > > Some specifics would help me a lot to understand the concerns. The primary concern is that HSTS is intended to have a very long lifetime and that is a security tradeoff, not just an operational cost tradeoff like DNS TTL. It's not so much with existing HSTS as with something like draft-evans-palmer-hsts-pinning. Consider the case where I operate a site that load balances between two certs, A and B but I inadvertantly advertise a pin for A only. If I understand S 2.1 correctly, any client who goes to A will get pinned and any client who goes to B will reject the pin (regardless of whether it's served.) If the client comes back and gets = B later, they will reject the cert. This is not easy to detect with the kind of testing you describe. -Ekr From alexey.melnikov@isode.com Fri Jun 29 11:37:45 2012 Return-Path: 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 9121F21F8680 for ; Fri, 29 Jun 2012 11:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, 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 weZ6Lg+xMwex for ; Fri, 29 Jun 2012 11:37:44 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9D87421F867D for ; Fri, 29 Jun 2012 11:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1340995049; d=isode.com; s=selector; i=@isode.com; bh=LB+DXEqGW73ec0umQm9NZWP7kGJiMTyVCszRXzJPRfo=; 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=Gy9Tx2QYpWqYy2zC5I2dUIYuFVrYp6Z2mint/zuYyWmJ2YJGIzXVSRSjkBpKclGoK8GQHV tyPBIYL63q5gdA3ur9hoBB2beIIr2vOS54BBTQRd2d3uLATMjOi+3/sK9r9hpAcZCa8Jb1 GxRCaMUapEVYcAvLJU/rMXESnqrC73o=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 29 Jun 2012 19:37:29 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FEDF5F3.7020403@isode.com> Date: Fri, 29 Jun 2012 19:37:39 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: "Steingruebl, Andy" References: <4FD6E91B.2000602@KingsMountain.com> <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com> <4FEDD6D6.3070803@isode.com> <1DFCCAFE421024488073B74EEA0173E1171F86@DEN-EXDDA-S12.corp.ebay.com> In-Reply-To: <1DFCCAFE421024488073B74EEA0173E1171F86@DEN-EXDDA-S12.corp.ebay.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF WebSec WG Subject: Re: [websec] Issue #41 add parameter indicating whether to hardfail or not X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Jun 2012 18:37:45 -0000 On 29/06/2012 17:45, Steingruebl, Andy wrote: >> -----Original Message----- >> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >> >> Maybe this is not a good example, but I am thinking that something like >> OCSP retrieval failing on the client side is not something that would >> show up in the webserver logs. > Sure, but doesn't the OCSP site know whether it has set HSTS? You might be thinking of a different usage of OCSP. I was thinking about: a browsers gets certificate from TLS. It tries to verify it using OCSP against a third party OCSP server. The OCSP server is down. Now the website the browser is trying to access is effectively down with HSTS enabled. From ietf@adambarth.com Fri Jun 29 13:10:50 2012 Return-Path: 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 6A1A221F8895 for ; Fri, 29 Jun 2012 13:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] 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 NcpG8Ug80L3u for ; Fri, 29 Jun 2012 13:10:49 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B80A321F859E for ; Fri, 29 Jun 2012 13:10:49 -0700 (PDT) Received: by yenq13 with SMTP id q13so3468917yen.31 for ; Fri, 29 Jun 2012 13:10:49 -0700 (PDT) Received: by 10.236.181.229 with SMTP id l65mr4871890yhm.116.1341000649307; Fri, 29 Jun 2012 13:10:49 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by mx.google.com with ESMTPS id c13sm4199744anm.13.2012.06.29.13.10.47 (version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 13:10:48 -0700 (PDT) Received: by qcac10 with SMTP id c10so1045131qca.31 for ; Fri, 29 Jun 2012 13:10:46 -0700 (PDT) Received: by 10.224.205.195 with SMTP id fr3mr6440625qab.68.1341000646724; Fri, 29 Jun 2012 13:10:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.94.75 with HTTP; Fri, 29 Jun 2012 13:10:16 -0700 (PDT) In-Reply-To: <4FEDF5F3.7020403@isode.com> References: <4FD6E91B.2000602@KingsMountain.com> <1DFCCAFE421024488073B74EEA0173E1170859@DEN-EXDDA-S12.corp.ebay.com> <4FEDD6D6.3070803@isode.com> <1DFCCAFE421024488073B74EEA0173E1171F86@DEN-EXDDA-S12.corp.ebay.com> <4FEDF5F3.7020403@isode.com> From: Adam Barth Date: Fri, 29 Jun 2012 13:10:16 -0700 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF WebSec WG Subject: Re: [websec] Issue #41 add parameter indicating whether to hardfail or not X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Jun 2012 20:10:50 -0000 On Fri, Jun 29, 2012 at 11:37 AM, Alexey Melnikov wrote: > On 29/06/2012 17:45, Steingruebl, Andy wrote: >>> >>> -----Original Message----- >>> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com] >>> >>> Maybe this is not a good example, but I am thinking that something like >>> OCSP retrieval failing on the client side is not something that would >>> show up in the webserver logs. >> >> Sure, but doesn't the OCSP site know whether it has set HSTS? > > You might be thinking of a different usage of OCSP. > > I was thinking about: a browsers gets certificate from TLS. It tries to > verify it using OCSP against a third party OCSP server. The OCSP server is > down. Now the website the browser is trying to access is effectively down > with HSTS enabled. Right, this is why browsers don't use OCSP. The problem here is OCSP, not HSTS. Adam From Jeff.Hodges@KingsMountain.com Fri Jun 29 13:43:09 2012 Return-Path: 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 9F22811E8072 for ; Fri, 29 Jun 2012 13:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.495 X-Spam-Level: X-Spam-Status: No, score=-101.495 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 NCUB4EBqgJ95 for ; Fri, 29 Jun 2012 13:43:09 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id C04C121F8483 for ; Fri, 29 Jun 2012 13:43:01 -0700 (PDT) Received: (qmail 1644 invoked by uid 0); 29 Jun 2012 20:43:01 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 29 Jun 2012 20:43:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Xjs7Gv1jJZxfRnSfSkrm6ixKP/XysiYxtcfl/yZYjxA=; b=S4DR4Qp5OVTbv7woMXVz33N/2hj43v8deQX7ISuPS/01KPkSk0nL6cjMyS3Zy+n8OHe+yUmIYb8KyJAbx4Nt7Qn7aTO6G58ULjXB7snIGlu9n085rmRS3M5z+WqRLcP+; Received: from [216.113.168.128] (port=37582 helo=[10.244.136.119]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Ski1s-0001OA-My; Fri, 29 Jun 2012 14:43:00 -0600 Message-ID: <4FEE1353.2070506@KingsMountain.com> Date: Fri, 29 Jun 2012 13:42:59 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: Eric Rescorla Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF WebSec WG Subject: Re: [websec] "This site is testing HSTS" directive (was Issue #41 add parameter indicating whether to hardfail or not) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Jun 2012 20:43:10 -0000 [ updated subject ] > It's not so much with existing HSTS as with something like > draft-evans-palmer-hsts-pinning. > Consider the case where I operate a site that load balances between > two certs, A and B > but I inadvertantly advertise a pin for A only. If I understand S 2.1 > correctly, ... just fyi on a meta level, note that draft-evans-palmer-hsts-pinning is superseded by draft-ietf-websec-key-pinning, and no longer is an extension to the STS header field. =JeffH From Jeff.Hodges@KingsMountain.com Fri Jun 29 13:56:13 2012 Return-Path: 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 8B88C11E8080 for ; Fri, 29 Jun 2012 13:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.995 X-Spam-Level: X-Spam-Status: No, score=-100.995 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, 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 LXDpNmvNQWks for ; Fri, 29 Jun 2012 13:56:13 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id D670A11E807F for ; Fri, 29 Jun 2012 13:56:12 -0700 (PDT) Received: (qmail 7271 invoked by uid 0); 29 Jun 2012 20:56:12 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 29 Jun 2012 20:56:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=T73RvSP1Stxv430SLojW80+bbg1BLoZgzDMFjM4s+GQ=; b=7cLC7GsFDLFUNQLAWc2vsqPvHIjjwlK5bo93NVOwLnz7f2M3diUPp2HL4I8dfDwdA+s5z5aOo8ZAJprqm2l6FGdY2YurnVCA8m0j0rszAE4n5NQoPAMCk+uXLNOHS7id; Received: from [216.113.168.128] (port=20906 helo=[10.244.136.119]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1SkiEe-0005pl-Fc for websec@ietf.org; Fri, 29 Jun 2012 14:56:12 -0600 Message-ID: <4FEE166B.3070007@KingsMountain.com> Date: Fri, 29 Jun 2012 13:56:11 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: IETF WebSec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [websec] "This site is testing HSTS" directive (was Issue #41 add parameter indicating whether to hardfail or not) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Fri, 29 Jun 2012 20:56:13 -0000 > Existence of "I am testing HSTS" directive would > allow browsers to present debug information on HSTS succeeding/failing > in some form (browser logs, additional debug frame, etc.) This "report-only"/"testing" mode notion came up in WG discussion in Paris, inspired in part on the "report-only" functionality in the Content Security Policy spec. The way CSP handles signaling "report-only" is via a separate header field ("Content-Security-Policy-Report-Only"), rather than as a directive. Given that HSTS as presently specified is implemented in several browsers (Chrome, Firefox, Opera12beta), and deployed by a number of sites, we suggest finishing up the HSTS spec as is. Then, if there's interest and energy to define a "report-only"/"testing" mode, a fairly simple follow-on spec could be written leveraging the original HSTS spec and defining just what's needed for this. =JeffH From tobias.gondrom@gondrom.org Sat Jun 30 08:22:44 2012 Return-Path: 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 BBC5021F8499 for ; Sat, 30 Jun 2012 08:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.514 X-Spam-Level: X-Spam-Status: No, score=-99.514 tagged_above=-999 required=5 tests=[AWL=-2.736, BAYES_00=-2.599, 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 jt8EizMgwxPA for ; Sat, 30 Jun 2012 08:22:43 -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 E5BEC21F8484 for ; Sat, 30 Jun 2012 08:22:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=vzZh5X2iirgloAqVNG9PB1Tt4vnwDO4pOSv8WpSEe+lxsFG85IIoPPmKvUqm1fyrvp90CjoZUKyLIki31u8kQRJ55x8lP2Duecy3b0sEZs+hvnbV2a4Vq7AdqBQwZSns; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 21883 invoked from network); 30 Jun 2012 17:22:39 +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; 30 Jun 2012 17:22:39 +0200 Message-ID: <4FEF19BF.9050203@gondrom.org> Date: Sat, 30 Jun 2012 16:22:39 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: websec@ietf.org References: <4FEE166B.3070007@KingsMountain.com> In-Reply-To: <4FEE166B.3070007@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] "This site is testing HSTS" directive (was Issue #41 add parameter indicating whether to hardfail or not) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 30 Jun 2012 15:22:44 -0000 I tend to agree with Jeff and Andy's comments. The real use case / need for "report-only" is not fully clear to me. Yes, it could always be nice to have one more test-case to run before going life with a system, but IMHO I am having a hard time seeing where this flag would really add value. And we should not add features (and complexity) as for "report-only" to an I-D just for the sake of it and because they might one day be possibly help for an unclear or theoretical use-case. Just my 5cents. Best regards, Tobias On 29/06/12 21:56, =JeffH wrote: > > > Existence of "I am testing HSTS" directive would > > allow browsers to present debug information on HSTS succeeding/failing > > in some form (browser logs, additional debug frame, etc.) > > > This "report-only"/"testing" mode notion came up in WG discussion in > Paris, inspired in part on the "report-only" functionality in the > Content Security Policy spec. > > The way CSP handles signaling "report-only" is via a separate header > field ("Content-Security-Policy-Report-Only"), rather than as a > directive. > > Given that HSTS as presently specified is implemented in several > browsers (Chrome, Firefox, Opera12beta), and deployed by a number of > sites, we suggest finishing up the HSTS spec as is. > > Then, if there's interest and energy to define a > "report-only"/"testing" mode, a fairly simple follow-on spec could be > written leveraging the original HSTS spec and defining just what's > needed for this. > > > =JeffH > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From tobias.gondrom@gondrom.org Sat Jun 30 08:23:15 2012 Return-Path: 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 6E4D621F85A0 for ; Sat, 30 Jun 2012 08:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.514 X-Spam-Level: X-Spam-Status: No, score=-99.514 tagged_above=-999 required=5 tests=[AWL=-2.736, BAYES_00=-2.599, 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 jWVq9Imn67zX for ; Sat, 30 Jun 2012 08:23:15 -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 CAA3C21F859E for ; Sat, 30 Jun 2012 08:23:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=nPYfwutcrA+8LJN5jz2yNsKel0v15KBLP+Pc9d8+bvuLu156IjhXGxuZ3/Ch3OusUgTLjyRPx3ZpyoS5VHj5ClevMYyA+ubc/nkPh4r5XnZyd2V8Da7BjU0/yIeKw8Bu; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Received: (qmail 21904 invoked from network); 30 Jun 2012 17:23:14 +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; 30 Jun 2012 17:23:14 +0200 Message-ID: <4FEF19E1.6050007@gondrom.org> Date: Sat, 30 Jun 2012 16:23:13 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: websec@ietf.org References: <4FEE166B.3070007@KingsMountain.com> In-Reply-To: <4FEE166B.3070007@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [websec] "This site is testing HSTS" directive (was Issue #41 add parameter indicating whether to hardfail or not) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.12 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: Sat, 30 Jun 2012 15:23:15 -0000 I tend to agree with Jeff and Andy's comments. The real use case / need for "report-only" is not fully clear to me. Yes, it could always be nice to have one more test-case to run before going life with a system, but IMHO I am having a hard time seeing where this flag would really add value. And we should not add features (and complexity) as for "report-only" to an I-D just for the sake of it and because they might one day be possibly help for an unclear or theoretical use-case. Just my 5cents. Best regards, Tobias On 29/06/12 21:56, =JeffH wrote: > > > Existence of "I am testing HSTS" directive would > > allow browsers to present debug information on HSTS succeeding/failing > > in some form (browser logs, additional debug frame, etc.) > > > This "report-only"/"testing" mode notion came up in WG discussion in > Paris, inspired in part on the "report-only" functionality in the > Content Security Policy spec. > > The way CSP handles signaling "report-only" is via a separate header > field ("Content-Security-Policy-Report-Only"), rather than as a > directive. > > Given that HSTS as presently specified is implemented in several > browsers (Chrome, Firefox, Opera12beta), and deployed by a number of > sites, we suggest finishing up the HSTS spec as is. > > Then, if there's interest and energy to define a > "report-only"/"testing" mode, a fairly simple follow-on spec could be > written leveraging the original HSTS spec and defining just what's > needed for this. > > > =JeffH > > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec