From nobody Wed Apr 8 15:00:33 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB371A8F42 for ; Wed, 8 Apr 2015 15:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Rl42sh7fdS5 for ; Wed, 8 Apr 2015 15:00:30 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684631A8F43 for ; Wed, 8 Apr 2015 15:00:29 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so74148189lbb.2 for ; Wed, 08 Apr 2015 15:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=Dmzc9F4YQJTVMoynHp/rNBoZMUNpzuGILuSjsW+VLWE=; b=NdjEEIGNV5XlxtoP4XIysUms1UZ5t+Cy/W+p6TC51eU15Py/mK4mGeTeKisZXZeZxV H7Gk1GToUtwa8Zuyi5nlt/K5CvYcMLs2JuSXNLAWsrrR5htZ/1cnMTq4DdcM7119OR9n tpIrveJKfd0PozZQoMtccBF6elBOPe1KMEU5g0UxGb7rgUnqjRRDSm3zXAL5NSO1Xo6f FIzgynAa/CvaBz9XibK2uWBfGmoS+l5rvlVvgf9OBmUIfgqIvxauyNNyEsNcdNyr01mx ILlqLaoS3P0Gj3uk9h3/u7UdNLF3dYXdklkpYO42PJ4yK1j5KP9minfXouvwMJjCbIBp A8JQ== MIME-Version: 1.0 X-Received: by 10.112.13.7 with SMTP id d7mr25385175lbc.79.1428530427766; Wed, 08 Apr 2015 15:00:27 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 15:00:27 -0700 (PDT) Date: Wed, 8 Apr 2015 18:00:27 -0400 X-Google-Sender-Auth: sgTRyIcNojo1bd2G_HlIHfOZU5Y Message-ID: From: Phillip Hallam-Baker To: websec Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:00:31 -0000 http://tools.ietf.org/html/draft-hallambaker-webseccaa-00 It is a pretty straightforward proposal: * Use the CAA record with either the hsts or hpkp tag * Put the same text you would have put into the CAA record value field There are a few differences in interpretation. All we are trying to do here is to help people to close the 'secure after first use' hole, not replace. Given that we have quite a bit of use of HSTS headers, providing a mechanism for publishing this in the DNS looks like being the obvious approach. From nobody Wed Apr 8 15:19:02 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B671A9056 for ; Wed, 8 Apr 2015 15:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRDg-2lalg9x for ; Wed, 8 Apr 2015 15:18:58 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAF21A905C for ; Wed, 8 Apr 2015 15:18:57 -0700 (PDT) Received: by igblo3 with SMTP id lo3so50913026igb.0 for ; Wed, 08 Apr 2015 15:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hcT82Qo5aDD9qbIKrHPVQYeKCfaqu13TV2rBVF0wC58=; b=VchtAOtuvlKrl2Av4xO7YydJ0ut2vpotAx5zWv1ZfRM3ciPJHvdG0Y65rEweEn00U1 fyDp6W24zXsqWaOb3w29nNYXJ53VJXoe5d80LqR6Ls2l7796hyZ1eUU/azoKIdkgOYyW nniNBjlBQ0dbOohXu55KeOfJv0RgUjLqHGEJbXpmFp5KVsQBrNd5TlR6WrRAIW/mvRi4 7/Ofauf1PSgO/rwVL/r/fj0VrzKcEtUHf/bhfLKxxd4AmVt8m2AuNHJLHGcd359Z+smQ SjDz/GZjjaeJ0zzmSJPSr/G0c/q8p8AXMzmG7ue6njmG3SgpfwmnQpakoGQyTGG8bco1 WOrg== MIME-Version: 1.0 X-Received: by 10.42.20.197 with SMTP id h5mr471582icb.22.1428531536758; Wed, 08 Apr 2015 15:18:56 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Wed, 8 Apr 2015 15:18:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 8 Apr 2015 18:18:56 -0400 Message-ID: From: Jeffrey Walton To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:19:00 -0000 On Wed, Apr 8, 2015 at 6:00 PM, Phillip Hallam-Baker wrote: > http://tools.ietf.org/html/draft-hallambaker-webseccaa-00 > > It is a pretty straightforward proposal: > > * Use the CAA record with either the hsts or hpkp tag > * Put the same text you would have put into the CAA record value field > > There are a few differences in interpretation. All we are trying to do > here is to help people to close the 'secure after first use' hole, not > replace. > > Given that we have quite a bit of use of HSTS headers, providing a > mechanism for publishing this in the DNS looks like being the obvious > approach. > A quick question.... > * Use the CAA record with either the hsts or hpkp tag > * Put the same text you would have put into the CAA record value field This is obviously predicated on an online app and DNS. Is there any interest in Installable Web Apps delivered over a trusted distribution channel? Installable Web Apps are simply web apps with a manifest that are packaged and installed like more traditional apps. They still use the same technologies, like HTML, CSS and JavaScript. The trusted distribution channel ensures the app is not tampered during delivery. The class of app is supported by both Firefox and Chrome. In the case of installable apps, the information like HSTS and HPKP can be placed in the app manifest. Even better, standards like HPKP won't need to provide the override because its confused about which pinset is the right one to use. Because the HSTS and HPKP information was in the manifest during delivery, there will be no question about which policy or key to use. Jeff From nobody Wed Apr 8 15:35:12 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C460F1A909F for ; Wed, 8 Apr 2015 15:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCvub3FcGmzy for ; Wed, 8 Apr 2015 15:35:09 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C6FCC1A909D for ; Wed, 8 Apr 2015 15:35:09 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 8754520058DAC; Wed, 8 Apr 2015 15:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=nNWXdzHZ420wm/ArWxSp4R9c3w8=; b=WztvxfU+ATo+DDCE0 XMf7gtmCatiY1NQGCIXdGf3VmPeg4YjRS8AwyrA6CI35OEZrIwy9gwP8YnPQX2Df vTyTItaVz+N0/2Ww69QXZkgd8WFd5mA0KFzcDpmWxe/WrlSRmEy4ovSzkyw3KrQc IeiZ7Yx+e7SSd94r2QJNgwORbk= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id 4C39820058DAB; Wed, 8 Apr 2015 15:35:09 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 8 Apr 2015 15:35:10 -0700 Message-ID: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> In-Reply-To: References: Date: Wed, 8 Apr 2015 15:35:10 -0700 From: "Ryan Sleevi" To: "Phillip Hallam-Baker" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:35:10 -0000 On Wed, April 8, 2015 3:00 pm, Phillip Hallam-Baker wrote: > http://tools.ietf.org/html/draft-hallambaker-webseccaa-00 > > It is a pretty straightforward proposal: > > * Use the CAA record with either the hsts or hpkp tag > * Put the same text you would have put into the CAA record value field > > There are a few differences in interpretation. All we are trying to do > here is to help people to close the 'secure after first use' hole, not > replace. > > Given that we have quite a bit of use of HSTS headers, providing a > mechanism for publishing this in the DNS looks like being the obvious > approach. I believe it was so obvious that the IETF has already beat you to the punch - RFC 6698. If it is, as you claim, to close the "secure after first use" hole - whic= h is the first time I've heard it called that, versus the "trust on first use hole", since "secure after first use" isn't so much a "hole" as a "nice thing to have" - then it requires secure DNS, which is back to the DNSSEC problem, and if you have DNSSEC and the ability to query arbitrary records on the client, well, you might as well just use DANE. Of course, you might mean this as a "How do I discover support" (e.g. for building preloaded lists), in which case, that problem already has a myriad of solutions. In either event, I see no reason to standardize Yet Another Way to do the same thing. From nobody Wed Apr 8 15:39:01 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BAD01A90B1 for ; Wed, 8 Apr 2015 15:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXuUdUUiAYLg for ; Wed, 8 Apr 2015 15:38:58 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 493401A90AE for ; Wed, 8 Apr 2015 15:38:58 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 10E7B2005E62B; Wed, 8 Apr 2015 15:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=1/B0nd5B8RLTpIG2P1RCh7Pa2Go=; b=h4oxJBq4Lac9/i4FD zUCnIz3FVfpDfVW2stfp4H2heIYx9Jrv8yz6QZGZvyo6Rb+aNl7QIWDOWAnVSo2i XDuK/Opjn7M5w4d83LSq77IwAgJ30Tgjqd3UgFJ/sHSpspFY+rwaws50En1xHEIX qwUJcy9LGLYPI9m1QEfMBRgH20= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id D0FAE2005E62A; Wed, 8 Apr 2015 15:38:57 -0700 (PDT) Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 8 Apr 2015 15:38:58 -0700 Message-ID: <10738ee1c985e6bd43ec26ae10cb5a16.squirrel@webmail.dreamhost.com> In-Reply-To: References: Date: Wed, 8 Apr 2015 15:38:58 -0700 From: "Ryan Sleevi" To: noloader@gmail.com User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Phillip Hallam-Baker , websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:38:59 -0000 On Wed, April 8, 2015 3:18 pm, Jeffrey Walton wrote: > This is obviously predicated on an online app and DNS. Is there any > interest in Installable Web Apps delivered over a trusted distribution > channel? That's a question for the W3C, not the IETF. > Installable Web Apps are simply web apps with a manifest that are > packaged and installed like more traditional apps. They still use the > same technologies, like HTML, CSS and JavaScript. The trusted > distribution channel ensures the app is not tampered during delivery. > The class of app is supported by both Firefox and Chrome. The summary doesn't match what is supported, but that's a question for th= e W3C. > In the case of installable apps, the information like HSTS and HPKP > can be placed in the app manifest. Even better, standards like HPKP > won't need to provide the override because its confused about which > pinset is the right one to use. Because the HSTS and HPKP information > was in the manifest during delivery, there will be no question about > which policy or key to use. By "the override", I presume you mean "the ability for a duly authorized user with administrative access over the machine they own to set policies for the applications they install", which you've objected to in the past, in which case, there's no reason at all to assume that the respect for a user's wishes over that of the developer's would somehow be inverted. The W3C is quite nice in spelling this out - http://www.w3.org/TR/html-design-principles/#priority-of-constituencies In either event, it sounds very much like a question for the W3C and the format application manifests take and are extended, and nothing to do wit= h this WG. From nobody Wed Apr 8 15:48:17 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9AB1A90DE for ; Wed, 8 Apr 2015 15:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxLpkZk258dl for ; Wed, 8 Apr 2015 15:48:14 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEF5C1A90DD for ; Wed, 8 Apr 2015 15:48:13 -0700 (PDT) Received: by iggg4 with SMTP id g4so52839280igg.0 for ; Wed, 08 Apr 2015 15:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ekpkcQS8AeUs//JRixOOwH8eJjPlOxkW/ex8CC3qWO0=; b=y7piXs/dACjExlbBDZwxI2/axE8M1gkNeu/CZTzU5M+w8KvXNjyLHOvF5FXOQ9NpcB jqFxdZAiWyuQ+QDxnOntae+/99VfT4S4Bi/f/n2TFAc+vArd3t8KfVd9JSVGApurFJPK CZFcp9j2BexA8aPPhEMmmkEWfjcYCDEsr2oH7zg7cZYsQKkBp0l4wI3ECP8/GnU+ZKVD W+mpQvZBET98bFGvkyt3mVScdBTYakuxPIws4dc7t6UXd7jW6YKx2W2gJQk74URrfBbc 1k7QUDbHw/nWzTYAZYuKBqst9NT1fFwvvlU3gd+ciw+MKNZqQk0dmxBztz9CaaVO8hFW n6pA== MIME-Version: 1.0 X-Received: by 10.107.19.2 with SMTP id b2mr43211845ioj.9.1428533293463; Wed, 08 Apr 2015 15:48:13 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Wed, 8 Apr 2015 15:48:13 -0700 (PDT) In-Reply-To: <10738ee1c985e6bd43ec26ae10cb5a16.squirrel@webmail.dreamhost.com> References: <10738ee1c985e6bd43ec26ae10cb5a16.squirrel@webmail.dreamhost.com> Date: Wed, 8 Apr 2015 18:48:13 -0400 Message-ID: From: Jeffrey Walton To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:48:15 -0000 >> In the case of installable apps, the information like HSTS and HPKP >> can be placed in the app manifest. Even better, standards like HPKP >> won't need to provide the override because its confused about which >> pinset is the right one to use. Because the HSTS and HPKP information >> was in the manifest during delivery, there will be no question about >> which policy or key to use. > > By "the override", I presume you mean "the ability for a duly authorized > user with administrative access over the machine they own to set policies > for the applications they install", which you've objected to in the past, > in which case, there's no reason at all to assume that the respect for a > user's wishes over that of the developer's would somehow be inverted. How did I know you would object to an effective security measure that minimized the ability to intercept communications :) I'd also cite the same document and claim that when the user installed the application with the preloaded and *known secure* settings, they would not want them arbitrarily overridden because a standard was confused about which pinset was the right one to use. As you succinctly said, its a Priorities of Constituencies. Jeff From nobody Wed Apr 8 16:38:51 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41F51B2AF7 for ; Wed, 8 Apr 2015 16:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxUilrOsURUE for ; Wed, 8 Apr 2015 16:38:48 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C790E1ACD3F for ; Wed, 8 Apr 2015 16:38:47 -0700 (PDT) Received: by laat2 with SMTP id t2so70532327laa.1 for ; Wed, 08 Apr 2015 16:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JY9DFSlgldeYYPnf8hMKTrWnQNEv5OYEW3WjkWS/KTg=; b=eklZPWu5pHSuGZmcuubRv7EfHP3D60bgdDgu1Zo7CWX4crASprI3iQtgE59gtjInFN gfVbApiCYxVWPcBKBHQazGo/bnZ0SiBRcQSHUb2SRypsxUzswXQhnByUtJyKOKTEuy6R QVOWHK0t62zPOA/XPINq4taPEl4QLnijUNRP45IJ2/gXPE4f0tLncfm8J//AHgzFBHAB V14XcTLocuCQ8reUWZdO/NeR3c5PiBztcR2NQO2mxXzYvDFkfQV0D6+Pq3HGo9YQCj1O ZMztmGWpXdI8hx25IlGNMgaCczMnZftk4+dJGbwfhkO/An0JhLjlBrNe2SnoV3VfymHc Ithg== X-Received: by 10.152.2.105 with SMTP id 9mr1764053lat.16.1428536326068; Wed, 08 Apr 2015 16:38:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.241.75 with HTTP; Wed, 8 Apr 2015 16:38:25 -0700 (PDT) In-Reply-To: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> References: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> From: Joseph Bonneau Date: Wed, 8 Apr 2015 16:38:25 -0700 Message-ID: To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Phillip Hallam-Baker , websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 23:38:49 -0000 On Wed, Apr 8, 2015 at 3:35 PM, Ryan Sleevi wrote: > On Wed, April 8, 2015 3:00 pm, Phillip Hallam-Baker wrote: >> http://tools.ietf.org/html/draft-hallambaker-webseccaa-00 >> >> It is a pretty straightforward proposal. > I believe it was so obvious that the IETF has already beat you to the > punch - RFC 6698. > > In either event, I see no reason to standardize Yet Another Way to do the > same thing. I do. Not all Ways to Do The Same Thing are equal in practice, even if they're equal in theory. DANE is complicated and has a completely different syntax. It is a 37 page long. Philip's proposal is 6 pages long. There is probably more to be added but that is still telling. If a busy site admin asks "how can I close the trust-on-first-use hole for my site?" Would we rather reply with: 1) Copy your HSTS and HPKP headers into a DNS record or 2) Go read up on how DANE works, come up with a DANE policy that's compatible with your HSTS/HPKP preferences (which may not be precisely possible), and keep the two policies compatible as they evolve. Perhaps DANE offers sufficiently extra expressive power for some super-energetic admins will prefer approach 2, but I think 9 of 10 developers (at least) would rather only have to learn and manage one syntax. My recent research on HSTS and HPKP deployment in practice has convinced me that much more attention needs to be paid to making developer's lives easier. From nobody Wed Apr 8 16:40:39 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6D41B359B for ; Wed, 8 Apr 2015 16:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Paf8my9X1H3 for ; Wed, 8 Apr 2015 16:40:37 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9491B3497 for ; Wed, 8 Apr 2015 16:40:36 -0700 (PDT) Received: by labbd9 with SMTP id bd9so66214780lab.2 for ; Wed, 08 Apr 2015 16:40:35 -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:message-id:subject :from:to:cc:content-type; bh=1PMaXeJYLq6RVQfxW+jih4g8OWdvnxN2VnuYbGdhPyE=; b=k7OP6O+oc2xAQ/Gv6dQi2Y3g+87TdXTOLdYz3GmW9Vmxtt5jRwjDBGbgMqPLLxwklU OCKknA2uYTfnxC1+9THCvTnGe7RovSJf3zqCnrTP9viLfuShF4jCOLpJDpTqPcqGfJV7 GKSS3TV/eQ1DjkZhK0VXzZjrcR3JpmDBu9jYnJ2ISOWg6cBw88cfWaL/OWyDIGsM40fp 7J7PSgUSSAN0hYUGpS1Y65sx4yMZwFE94EvQT2hSDBlQ2JOa45afF6pqOSu0OF/yITcF Z4XDcjJ9biYbA5+4Nxeyn7KKTihUTI267v7o2bODq3YevmKmRBu3kjC27sie+l5Xqs5q u9/Q== MIME-Version: 1.0 X-Received: by 10.152.120.8 with SMTP id ky8mr1815040lab.118.1428536435316; Wed, 08 Apr 2015 16:40:35 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 16:40:35 -0700 (PDT) In-Reply-To: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> References: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> Date: Wed, 8 Apr 2015 19:40:35 -0400 X-Google-Sender-Auth: Fo08cGKE3NWIcaEnQg4VVLI20jU Message-ID: From: Phillip Hallam-Baker To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 23:40:38 -0000 On Wed, Apr 8, 2015 at 6:35 PM, Ryan Sleevi wrote: > On Wed, April 8, 2015 3:00 pm, Phillip Hallam-Baker wrote: >> http://tools.ietf.org/html/draft-hallambaker-webseccaa-00 >> >> It is a pretty straightforward proposal: >> >> * Use the CAA record with either the hsts or hpkp tag >> * Put the same text you would have put into the CAA record value field >> >> There are a few differences in interpretation. All we are trying to do >> here is to help people to close the 'secure after first use' hole, not >> replace. >> >> Given that we have quite a bit of use of HSTS headers, providing a >> mechanism for publishing this in the DNS looks like being the obvious >> approach. > > I believe it was so obvious that the IETF has already beat you to the > punch - RFC 6698. > > If it is, as you claim, to close the "secure after first use" hole - which > is the first time I've heard it called that, versus the "trust on first > use hole", since "secure after first use" isn't so much a "hole" as a > "nice thing to have" - then it requires secure DNS, which is back to the > DNSSEC problem, and if you have DNSSEC and the ability to query arbitrary > records on the client, well, you might as well just use DANE. Who said anything about DNSSEC being required? DANE has totally different syntax and semantics. Adding this mechanism is very straightforward, just post the same parameters that would be presented in the HTTP headers in DNS. The mechanism can even work both ways, a server can use this for discovery. People in WebSec and DANE decided on different approaches. I see no reason to foist the inability of the two groups to agree on one approach onto users of the specs and certainly no reason to hobble WebSec which is now widely used to make space for an experimental protocol that has failed. > Of course, you might mean this as a "How do I discover support" (e.g. for > building preloaded lists), in which case, that problem already has a > myriad of solutions. Having more than one solution for a problem is usually a good reason to pick one. From nobody Wed Apr 8 17:00:29 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85B71B3711 for ; Wed, 8 Apr 2015 17:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRoXpc12Zwaw for ; Wed, 8 Apr 2015 17:00:25 -0700 (PDT) Received: from APAC01-SG1-obe.outbound.protection.outlook.com (mail-sg1on0147.outbound.protection.outlook.com [134.170.132.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6DC1B3714 for ; Wed, 8 Apr 2015 17:00:19 -0700 (PDT) Received: from [133.2.210.64] (133.2.210.64) by OS1PR01MB0133.jpnprd01.prod.outlook.com (25.161.228.149) with Microsoft SMTP Server (TLS) id 15.1.130.23; Thu, 9 Apr 2015 00:00:10 +0000 Message-ID: <5525C105.3010307@it.aoyama.ac.jp> Date: Thu, 9 Apr 2015 09:00:05 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , websec References: In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OS2PR01CA0007.jpnprd01.prod.outlook.com (25.161.74.145) To OS1PR01MB0133.jpnprd01.prod.outlook.com (25.161.228.149) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:OS1PR01MB0133; X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6049001)(6009001)(51704005)(479174004)(24454002)(50466002)(76176999)(65816999)(65806001)(47776003)(86362001)(107886001)(85202003)(2950100001)(50986999)(66066001)(33656002)(54356999)(65956001)(59896002)(85182001)(83506001)(1720100001)(40100003)(23676002)(92566002)(74482002)(46102003)(62966003)(77156002)(87976001)(19580395003)(561944003)(42186005)(15975445007)(122386002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:OS1PR01MB0133; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(5002010)(5005006); SRVR:OS1PR01MB0133; BCL:0; PCL:0; RULEID:; SRVR:OS1PR01MB0133; X-Forefront-PRVS: 0541031FF6 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2015 00:00:10.3633 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS1PR01MB0133 Archived-At: Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 00:00:27 -0000 On 2015/04/09 07:00, Phillip Hallam-Baker wrote: > http://tools.ietf.org/html/draft-hallambaker-webseccaa-00 > > It is a pretty straightforward proposal: I haven't gotten further than the title. That indeed looks extremely straightforward, but probably a bit too simple :-). It's just "Title". Regards, Martin. From nobody Wed Apr 8 17:41:26 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27861AC3D3 for ; Wed, 8 Apr 2015 17:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SM04n0bIM5kE for ; Wed, 8 Apr 2015 17:41:23 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 894251AC3D8 for ; Wed, 8 Apr 2015 17:41:21 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 4E12E28606F; Wed, 8 Apr 2015 17:41:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=YOBe8jfJgKbGHtsKDkUsrVJLdSc=; b=T/cbNSLTCtIw1O3eS bapxQyqoC4BAaVaSgQUDnUsV9eHYReI2TQXlDmwlnFIbvuc+rDdS7SoyZF2LyRPq Vleqvz0K3kllqUHqmT5GXgOPrs8L1utErVXh/w8kfKfHfHr9v4o5VPxPancU5qUJ W2yo3MV7coWvIDwA1J7vb1hJ5c= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPA id 1ABB6286057; Wed, 8 Apr 2015 17:41:21 -0700 (PDT) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 8 Apr 2015 17:41:19 -0700 Message-ID: <3debce5114a44d5027f437c4c481addb.squirrel@webmail.dreamhost.com> In-Reply-To: References: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> Date: Wed, 8 Apr 2015 17:41:19 -0700 From: "Ryan Sleevi" To: "Phillip Hallam-Baker" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 00:41:23 -0000 On Wed, April 8, 2015 4:40 pm, Phillip Hallam-Baker wrote: > Who said anything about DNSSEC being required? If it isn't, then it's not equivalent. HSTS requires an error free connection - in part to ensure the policy is securely delivered. HPKP requires an error free connection that is consistent with the policy expressed - in part to ensure the policy is securely delivered and correctly formed. If you don't require secure delivery of that, then you're not developing = a secure solution. If you're doing it for out of band discovery, then it would help to say that. But I very much doubt you are. > Having more than one solution for a problem is usually a good reason > to pick one. http://xkcd.com/927/ From nobody Wed Apr 8 17:48:32 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047A71AC44A for ; Wed, 8 Apr 2015 17:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgQXUL6KsKZk for ; Wed, 8 Apr 2015 17:48:29 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E6E421AC447 for ; Wed, 8 Apr 2015 17:48:29 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id C6B672005E809; Wed, 8 Apr 2015 17:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=NtpGQlpZiPswzs0I2uapRpIO+NE=; b=kwmx8z6cOPxIHeQ3X pkHtt3UVZQjxcG7t6AcSxfOy1WGAgXUO93TcNPA8RP7bhp/b87svrf/7GJOsMkuD /zy2Nc44F3U5BcNzdIm8EA5ArYxxmLhGaKHasvYMSk4yrL2bDo/Ld7OeHix+5xwd noalpkgOwAN8KB01nv5MB1zvO4= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id 2C0DB2005D807; Wed, 8 Apr 2015 17:48:29 -0700 (PDT) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 8 Apr 2015 17:48:28 -0700 Message-ID: <5c572eea7036599f2cc96f454cb99375.squirrel@webmail.dreamhost.com> In-Reply-To: References: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> Date: Wed, 8 Apr 2015 17:48:28 -0700 From: "Ryan Sleevi" To: "Joseph Bonneau" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Phillip Hallam-Baker , websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 00:48:31 -0000 On Wed, April 8, 2015 4:38 pm, Joseph Bonneau wrote: > My recent research on HSTS and HPKP deployment in practice has > convinced me that much more attention needs to be paid to making > developer's lives easier. I certainly agree with this. >From a UA perspective, does this address any of the concerns that DANE/DNSSEC suffer from? No, not really. So is this an improvement over DANE/DNSSEC? Only in syntax, not in deployability. Respectfully, this is a solution in search of a problem space. That Phillip suggests it's deployable without DNSSEC is itself telling that it's not meant to be an apples:apples conversion for the client. If we assume it's for discoverability for reploads, then it's ill-defined who the discovering actors are and whether or not they're interested in it, but is a question worth having in the "Is this a problem" side before a "= I have a solution" side is broached. When I look at this from the "What problem does it solve" and "In doing so, does it introduce new problems" perspective, I'm not sure I agree wit= h the first question, and even if I did, the answers to the second question are rightfully concerning. From nobody Wed Apr 8 17:58:04 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F571ACD25 for ; Wed, 8 Apr 2015 17:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DGw25V3-KkE for ; Wed, 8 Apr 2015 17:58:01 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74041ACCE5 for ; Wed, 8 Apr 2015 17:57:58 -0700 (PDT) Received: by lbbzk7 with SMTP id zk7so79838143lbb.0 for ; Wed, 08 Apr 2015 17:57:57 -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:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=vAFKJZE22ZxXJ+LQ54NevoqbrZMTPCDkLa6ddP0VhsA=; b=yWYg7DiJ5cfMwcCn9JV9lMPudn+6xjjhsVOCr+SDlatY4/VG+4cyC1M5lxCw+KITLa KmhlM7EIKSqGDsGSSOQ2wYHCs8GwL2sKxQIGJqobMVXv0QEltG9VZSvq4Ex57bIY48qp 9b9UVCzuZtDCPMf4vRjO07ltvOfKP8dWWrv41Bl/7ZlLYmZVySJBzUjnuamUvQxnNzIi 7T1MDJmDr/lWjfxBZkG9bMl35WZLSm8Pe5Mk/arY64yBB6BOaqYIpwg9Vm2xf2XfjBSB W1Lg5rPZ6mSm14XUhaTlAzL1uTT98IIQZsbPrtpWG9iiC6f19nFA+44h8rnkP+58zXSp W2+Q== MIME-Version: 1.0 X-Received: by 10.152.18.225 with SMTP id z1mr2111999lad.124.1428541077272; Wed, 08 Apr 2015 17:57:57 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 17:57:57 -0700 (PDT) In-Reply-To: <5525C105.3010307@it.aoyama.ac.jp> References: <5525C105.3010307@it.aoyama.ac.jp> Date: Wed, 8 Apr 2015 20:57:57 -0400 X-Google-Sender-Auth: z8q5nM66unSjcTstKNtYaxJw5kQ Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 00:58:02 -0000 On Wed, Apr 8, 2015 at 8:00 PM, "Martin J. D=C3=BCrst" wrote: > On 2015/04/09 07:00, Phillip Hallam-Baker wrote: >> >> http://tools.ietf.org/html/draft-hallambaker-webseccaa-00 >> >> It is a pretty straightforward proposal: > > > I haven't gotten further than the title. That indeed looks extremely > straightforward, but probably a bit too simple :-). > > > It's just "Title". Yeah, its a bug in a new feature I added into my word->RFC processor. From nobody Wed Apr 8 18:27:26 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BE41ACD9F for ; Wed, 8 Apr 2015 18:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1zOBH8qAJ1m for ; Wed, 8 Apr 2015 18:27:24 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3137A1ACD9C for ; Wed, 8 Apr 2015 18:27:24 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so71477343lbb.3 for ; Wed, 08 Apr 2015 18:27:22 -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:message-id:subject :from:to:cc:content-type; bh=AtrtRPEXHpqx2ErC76NMv14OuhRsgR7RHR6nm9sZSZk=; b=Wn9BEVl27EoIWeFom1k6JsHbvUJIouc6HQddG0YGUDisM3vzm+kl7LbIrORoSSv+C9 wBLM1DGamsYH86rSoNjKY0WRYC4nb1vmlmqsNUVRRf4JBOT6yA2BsSe+rq5oaNirq2FC aFtaK7qM0JKvm+IXy+8FgC3djAVx0SizjLBIuPd6bGtDBW3PR/pLawiOfVU7sH+AVG6W RxgGt6+weAxE5sy+LO8e3e2pO4hyTDmEZPezwt75XUx79AkT/y0B1+50QV4Bcs3+I2fb sVAk/gdVgIEN4X7Py+Tt0vZmUlk5yxp+nbwUZ2dTL3NotOENQFCpw3scPjp00kHSn9hr hYcw== MIME-Version: 1.0 X-Received: by 10.152.88.1 with SMTP id bc1mr2365346lab.79.1428542842731; Wed, 08 Apr 2015 18:27:22 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 18:27:22 -0700 (PDT) In-Reply-To: <3debce5114a44d5027f437c4c481addb.squirrel@webmail.dreamhost.com> References: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> <3debce5114a44d5027f437c4c481addb.squirrel@webmail.dreamhost.com> Date: Wed, 8 Apr 2015 21:27:22 -0400 X-Google-Sender-Auth: BcXA524QI_tAWnn3g6339FB4pJ4 Message-ID: From: Phillip Hallam-Baker To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 01:27:25 -0000 On Wed, Apr 8, 2015 at 8:41 PM, Ryan Sleevi wrote: > On Wed, April 8, 2015 4:40 pm, Phillip Hallam-Baker wrote: >> Who said anything about DNSSEC being required? > > If it isn't, then it's not equivalent. > > HSTS requires an error free connection - in part to ensure the policy is > securely delivered. No it is required to know that the policy is consistent. Which you certainly want to do if a security policy is going to be cached for 6 months. The security considerations of security policy mechanisms are all about not shooting yourself in the foot. That is why I propose to not consider the record valid for any longer than its DNS time to live. > HPKP requires an error free connection that is consistent with the policy > expressed - in part to ensure the policy is securely delivered and > correctly formed. > > If you don't require secure delivery of that, then you're not developing a > secure solution. I am not delivering a perfectly secure solution but neither is DANE. All I am looking to do is to improve on the status quo with as little extra work as possible. If DNSSEC is ever deployed AND it becomes visible to clients then it could be relevant to this spec. But right now DNSSEC is not a viable mechanism for authenticating DNS RRs at the client. There are other mechanisms that work just fine for the client-resolver link, including our own proprietary protocols and the proposal we have made to DPRIV. From nobody Wed Apr 8 19:03:55 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1661ACDE8 for ; Wed, 8 Apr 2015 18:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXlB-bxKxRSV for ; Wed, 8 Apr 2015 18:52:06 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6D61ACDE6 for ; Wed, 8 Apr 2015 18:52:06 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 64B6C286058; Wed, 8 Apr 2015 18:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=YEYwHI/Zgq13VCvQQNm2++LBLaE=; b=rSORxBCGosknDfu7d m6slgNhQwgohf6DRvJI7pmmRTHgFecfSms+mKgCM4pz6tiYP5ogx3raZukpKi9cs CcQKfN3c2cWGYJc6Eo+Pq9i37WpqyjwX5hW03jtW841wdM6AKGRgbFh8/Y/NAIxN vokWM477Ip6tcly21UbM3K+1sg= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPA id 35494286074; Wed, 8 Apr 2015 18:52:06 -0700 (PDT) Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Wed, 8 Apr 2015 18:52:04 -0700 Message-ID: <3c6e1d6242b4bbc31d5020cf24770cb4.squirrel@webmail.dreamhost.com> In-Reply-To: References: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> <3debce5114a44d5027f437c4c481addb.squirrel@webmail.dreamhost.com> Date: Wed, 8 Apr 2015 18:52:04 -0700 From: "Ryan Sleevi" To: "Phillip Hallam-Baker" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Wed, 08 Apr 2015 19:03:54 -0700 Cc: websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietfhasmat@sleevi.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 01:52:07 -0000 On Wed, April 8, 2015 6:27 pm, Phillip Hallam-Baker wrote: > The security considerations of security policy mechanisms are all > about not shooting yourself in the foot. No, they aren't. They're also about mitigating the worst that an "attacker" could do. > That is why I propose to not consider the record valid for any longer than its DNS time to live. And now your TTL and the client caching policy of that TTL becomes part o= f your security considerations. > I am not delivering a perfectly secure solution but neither is DANE. > All I am looking to do is to improve on the status quo with as little > extra work as possible. All I see are negatives here compared with "the status quo". > > If DNSSEC is ever deployed AND it becomes visible to clients then it > could be relevant to this spec. But right now DNSSEC is not a viable > mechanism for authenticating DNS RRs at the client. Agreed. And so how are you going to bootstrap security over an insecure connection, without dealing with all of the threat scenarios explicitly and implicitly addressed by the documents you're trying to supplant/augment? I would encourage you to consider the exercise of "What is the worst that an attacker could do with this policy", as well as "What's the strongest level of security I could achieve", and hopefully in both cases you'll se= e that the flaws are somewhat fundamental if delivered over an insecure transport. And if you had a secure transport (which you don't, but we'll assume the IETF will fix all this in good time), then you *could* use DANE, and the only issue becomes one of syntax. Which is not an intrinsicly good argument - and in fact, generally a bad one (syntax can be hidden by tools, but specs - and bad specs - live forever) From nobody Wed Apr 8 19:37:05 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699791B2AB7 for ; Wed, 8 Apr 2015 19:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkcqEPzwBkAt for ; Wed, 8 Apr 2015 19:37:02 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FF31B372B for ; Wed, 8 Apr 2015 19:37:02 -0700 (PDT) Received: by lagv1 with SMTP id v1so79645090lag.3 for ; Wed, 08 Apr 2015 19:37:00 -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:message-id:subject :from:to:cc:content-type; bh=nNLJglZVPupB2M/l7+8dMdXlT5MAAjTNALv3uv2XIB0=; b=zLmx3fJHwKqToLXoO7c9VDdOiSZqBIRLq9oDrFJ40FkkHB348VHoLsUoD9ejmQLTo/ FcNhHluWTaVA2T8sFFO99rUfEW6t44bcrl0BjHtmw1zHH+hIoCssnPd4NX2r4gkuLrcp jP8cHqUHswcc6NU8hvPpEksoYyXOOsG46Zj/p/ZeeGyiHcRKeu3efIVdHLOLo0m5LRMA W/KUOAOm7piBkQ4ibq0hltkc2enjnw3gU/RHDpwKjRjPSavGl7lcDwpaLRkMmz/4ok9H EPP3WWUNWE6etjgS16qFl7+nNTnIPOuO8F4gm+qur1PFBULEDMJnhsmfHSH+QqZtKqJo KWNA== MIME-Version: 1.0 X-Received: by 10.152.87.162 with SMTP id az2mr2356884lab.58.1428547020422; Wed, 08 Apr 2015 19:37:00 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.147.165 with HTTP; Wed, 8 Apr 2015 19:37:00 -0700 (PDT) In-Reply-To: <3c6e1d6242b4bbc31d5020cf24770cb4.squirrel@webmail.dreamhost.com> References: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> <3debce5114a44d5027f437c4c481addb.squirrel@webmail.dreamhost.com> <3c6e1d6242b4bbc31d5020cf24770cb4.squirrel@webmail.dreamhost.com> Date: Wed, 8 Apr 2015 22:37:00 -0400 X-Google-Sender-Auth: TpgOubIfZk3NEwQmav2zoFcnSr8 Message-ID: From: Phillip Hallam-Baker To: ryan-ietfhasmat@sleevi.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 02:37:03 -0000 On Wed, Apr 8, 2015 at 9:52 PM, Ryan Sleevi wrote: > On Wed, April 8, 2015 6:27 pm, Phillip Hallam-Baker wrote: >> If DNSSEC is ever deployed AND it becomes visible to clients then it >> could be relevant to this spec. But right now DNSSEC is not a viable >> mechanism for authenticating DNS RRs at the client. > > Agreed. And so how are you going to bootstrap security over an insecure > connection, without dealing with all of the threat scenarios explicitly > and implicitly addressed by the documents you're trying to > supplant/augment? We are agreed that the utility of DNSSEC is limited to authoritative name resolvers, if that. So rather than trying to build further on a dead end, I propose to work in the opposite direction. We have a deployed scheme that already works inband in HTTP, extending it to DNS publication is the logical next step to extend the scheme further. Once that is in place there is an incentive to deal with authenticating the DNS client-resolver connection. We can argue about the security benefits achieved through this particular proposal, but what do you expect from two pages? What I propose is that we take the low hanging fruit now and let folk who have complicated boil the ocean approaches continue to fend for themselves. From nobody Tue Apr 14 08:44:20 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3F51B2D3B for ; Tue, 14 Apr 2015 08:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.913 X-Spam-Level: * X-Spam-Status: No, score=1.913 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBeZwLQq5Zgk for ; Tue, 14 Apr 2015 08:44:17 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [67.18.59.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145171B2D2B for ; Tue, 14 Apr 2015 08:44:17 -0700 (PDT) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 217BFD664493D; Tue, 14 Apr 2015 10:44:16 -0500 (CDT) Received: from pathfinder.websitewelcome.com (pathfinder.websitewelcome.com [192.185.2.47]) by gateway04.websitewelcome.com (Postfix) with ESMTP id 11E43D66448D3 for ; Tue, 14 Apr 2015 10:44:16 -0500 (CDT) Received: from isoccam by pathfinder.websitewelcome.com with local (Exim 4.82) (envelope-from ) id 1Yi30Y-0000s4-EL; Tue, 14 Apr 2015 10:44:15 -0500 Received: from 41.204.94.222 ([41.204.94.222]) (SquirrelMail authenticated user ngnoulaye@isoc-cameroon.org) by isoc-cameroon.org with HTTP; Tue, 14 Apr 2015 10:44:15 -0500 Message-ID: <6dad50f3fa3cf566611afd2f73ebfc89.squirrel@isoc-cameroon.org> In-Reply-To: References: <8b60de39fde39644fcc43150c41ba978.squirrel@webmail.dreamhost.com> <3debce5114a44d5027f437c4c481addb.squirrel@webmail.dreamhost.com> <3c6e1d6242b4bbc31d5020cf24770cb4.squirrel@webmail.dreamhost.com> Date: Tue, 14 Apr 2015 10:44:15 -0500 From: ngnoulaye@isoc-cameroon.org To: "Phillip Hallam-Baker" User-Agent: SquirrelMail/1.5.2 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - pathfinder.websitewelcome.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [804 32002] / [47 12] X-AntiAbuse: Sender Address Domain - isoc-cameroon.org X-BWhitelist: no X-Source-IP: X-Exim-ID: 1Yi30Y-0000s4-EL X-Source: /usr/local/cpanel/3rdparty/php/54/bin/php-cgi X-Source-Args: /usr/local/cpanel/3rdparty/php/54/bin/php-cgi /usr/local/cpanel/base/3rdparty/squirrelmail/src/compose.php X-Source-Dir: :/base/3rdparty/squirrelmail/src X-Source-Sender: X-Source-Auth: isoccam X-Email-Count: 6 X-Source-Cap: aXNvY2NhbTtuZG9ubmFuZztwYXRoZmluZGVyLndlYnNpdGV3ZWxjb21lLmNvbQ== Archived-At: Cc: ryan-ietfhasmat@sleevi.com, websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2015 15:44:18 -0000 I support Hallam-Baker views on this. Regards, /Janvier Ngnoulaye Le Mer 8 avril 2015 21:37, Phillip Hallam-Baker a écrit : > On Wed, Apr 8, 2015 at 9:52 PM, Ryan Sleevi > wrote: > >> On Wed, April 8, 2015 6:27 pm, Phillip Hallam-Baker wrote: >> > >>> If DNSSEC is ever deployed AND it becomes visible to clients then it >>> could be relevant to this spec. But right now DNSSEC is not a viable >>> mechanism for authenticating DNS RRs at the client. >> >> Agreed. And so how are you going to bootstrap security over an insecure >> connection, without dealing with all of the threat scenarios >> explicitly and implicitly addressed by the documents you're trying to >> supplant/augment? > > We are agreed that the utility of DNSSEC is limited to authoritative > name resolvers, if that. > > So rather than trying to build further on a dead end, I propose to > work in the opposite direction. We have a deployed scheme that already > works inband in HTTP, extending it to DNS publication is the logical next > step to extend the scheme further. Once that is in place there is an > incentive to deal with authenticating the DNS client-resolver connection. > > We can argue about the security benefits achieved through this > particular proposal, but what do you expect from two pages? > > What I propose is that we take the low hanging fruit now and let folk > who have complicated boil the ocean approaches continue to fend for > themselves. > > _______________________________________________ > websec mailing list websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > > From nobody Wed Apr 15 08:22:41 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1687A1B35DE for ; Wed, 15 Apr 2015 08:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.965 X-Spam-Level: X-Spam-Status: No, score=-93.965 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vf2MrO6qBhWs for ; Wed, 15 Apr 2015 08:22:38 -0700 (PDT) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F1E1B35E9 for ; Wed, 15 Apr 2015 08:22:31 -0700 (PDT) Received: from [172.29.13.45] (host81-149-121-102.in-addr.btopenworld.com [81.149.121.102]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 57CBC63519 for ; Wed, 15 Apr 2015 17:22:29 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=FooE5yRQ/ge7mekJZ7IIIf3+/JpLnzVpk7g+5nBIwElpY2VwC5JgbwUi6pEmIW0IuPjUJxYMOp3sKD6rDZTLUVD7fvxLodHPHFAO/D8sesCCX4gLvPSFzxsHWkTQ+mBkJ518yNMCIuZMAFAVTUNifCMt5ODJVrfx2XdBTcUwiQI=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:Content-Type:Content-Transfer-Encoding; Message-ID: <552E8233.5060307@gondrom.org> Date: Wed, 15 Apr 2015 16:22:27 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: websec@ietf.org X-Priority: 4 (Low) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [websec] FYI: presentation about HSTS and key pinning adoption at last IETF 92 SAAG meeting X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 15:22:40 -0000 Hi guys, just fyi: there was 2 weeks ago an interesting presentation at the IETF 92 SAAG about HSTS and key pinning adoption. If you are interested you can watch it here: http://recordings.conf.meetecho.com/Playout/watch.jsp?recording=IETF92_SAAG&chapter=chapter_0 (you can jump to minute 24 and play). Best regards, Tobias From nobody Fri Apr 17 13:39:20 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBF51A8722; Fri, 17 Apr 2015 13:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GqoPfwvI7cZ; Fri, 17 Apr 2015 13:39:15 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id B190D1A871F; Fri, 17 Apr 2015 13:39:15 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0E15E180452; Fri, 17 Apr 2015 13:38:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150417203831.0E15E180452@rfc-editor.org> Date: Fri, 17 Apr 2015 13:38:31 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, websec@ietf.org, rfc-editor@rfc-editor.org Subject: [websec] RFC 7469 on Public Key Pinning Extension for HTTP X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 20:39:17 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7469 Title: Public Key Pinning Extension for HTTP Author: C. Evans, C. Palmer, R. Sleevi Status: Standards Track Stream: IETF Date: April 2015 Mailbox: cevans@google.com, palmer@google.com, sleevi@google.com Pages: 28 Characters: 61619 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-websec-key-pinning-21.txt URL: https://www.rfc-editor.org/info/rfc7469 This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted 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. This document is a product of the Web Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Apr 17 14:37:36 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8641B2DD2 for ; Fri, 17 Apr 2015 14:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hUPn8ATR5q2 for ; Fri, 17 Apr 2015 14:37:35 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBEC1A7008 for ; Fri, 17 Apr 2015 14:37:35 -0700 (PDT) Received: by igblo3 with SMTP id lo3so22509697igb.1 for ; Fri, 17 Apr 2015 14:37:34 -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:message-id:subject :from:to:content-type; bh=FfcpRNaVAzYAuK9X0zfTITqA/t5ndQok68KsG15SetU=; b=al2E6Owit6cgnAXm5tG2t3IUtaPZicnIPj4R7wMSwI12GlTiULtGlZxYfrOtzqf/tD sp/7nYS4l1t9M8Q0D9pMstzu79vf+cdg4XGk4P/1cavo/cmmrLQObBwTTNFSRxa+A+dz JnWrNuxn2ToHfHTT8JdIK6/LmnQ2LzVDQv9uonCqiUbz8fyPi+/C0Hq8wvoX226if061 dHHVYSxryrwywrtSkUy5YPuXhFusBP5qF5hfsWu+mRgOEQ4ZXznD9VOOfpYNpbLMaEFN 3V+ezaLKfP4x/R1bVtL8BYXQwU60+eKOT7+XVCIDvNh0a5KlNde3F8DqK+HWhNNqAdMY xHqg== MIME-Version: 1.0 X-Received: by 10.50.25.225 with SMTP id f1mr5625967igg.29.1429306654473; Fri, 17 Apr 2015 14:37:34 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.156.1 with HTTP; Fri, 17 Apr 2015 14:37:34 -0700 (PDT) In-Reply-To: <20150417203831.0E15E180452@rfc-editor.org> References: <20150417203831.0E15E180452@rfc-editor.org> Date: Fri, 17 Apr 2015 17:37:34 -0400 X-Google-Sender-Auth: mL-tLh4iGaxZjBYGn1Nxcxlk0KQ Message-ID: From: Barry Leiba To: IETF WebSec WG Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [websec] RFC 7469 on Public Key Pinning Extension for HTTP X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 21:37:36 -0000 The final websec document has been published today by the RFC Editor. With that, the websec working group has completed its work. Thanks very much to all the participants who spent their time and effort working on this, and especially to Tobias, Yoav, and Alexey, the current and past chairs. I will be asking the Secretariat to close the working group. The mailing list will remain open for related discussion. Barry, Applications AD On Fri, Apr 17, 2015 at 4:38 PM, wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 7469 > > Title: Public Key Pinning Extension for HTTP > Author: C. Evans, C. Palmer, R. Sleevi > Status: Standards Track > Stream: IETF > Date: April 2015 > Mailbox: cevans@google.com, > palmer@google.com, > sleevi@google.com > Pages: 28 > Characters: 61619 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-websec-key-pinning-21.txt > > URL: https://www.rfc-editor.org/info/rfc7469 > > This document defines a new HTTP header that allows web host > operators to instruct user agents to remember ("pin") the hosts' > cryptographic identities over a period of time. During that time, > user agents (UAs) will require that the host presents a certificate > chain including at least one Subject Public Key Info structure whose > fingerprint matches one of the pinned fingerprints for that host. By > effectively reducing the number of trusted 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. > > This document is a product of the Web Security Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > From nobody Fri Apr 17 15:29:28 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47951B30AC for ; Fri, 17 Apr 2015 15:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.665 X-Spam-Level: X-Spam-Status: No, score=-96.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXCahCz_DRks for ; Fri, 17 Apr 2015 15:29:25 -0700 (PDT) Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B7781B30A8 for ; Fri, 17 Apr 2015 15:29:25 -0700 (PDT) Received: from [163.119.49.41] (unknown [163.119.49.41]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 386236364C; Sat, 18 Apr 2015 00:29:23 +0200 (CEST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=ozdMsFykSf/iktYoqxu7ZkgMpFugwd9LMoqc25qZOii+xbaDAsQFPMRrLAAj852QLmV2zVEIbRNOKHnYOhIMDjmTV+C1dZ83Ytb9fEW6vgzPeYa41YW6PNC1lNtNK25ZnRm9VU2wimDqpFZJol5riDl8ZEfS/Q2H96vwpYne9o4=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; Message-ID: <55318942.4040901@gondrom.org> Date: Fri, 17 Apr 2015 23:29:22 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: websec@ietf.org References: <20150417203831.0E15E180452@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: barryleiba@computer.org Subject: [websec] closing of WEBSEC WG (was: Re: RFC 7469 on Public Key Pinning Extension for HTTP) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 22:29:28 -0000 Hurray! :-) :-) :-) And a big "thank you" from me as well to all the many participants, authors, contributors and my fellow co-chairs. I very much appreciate the hard work from all of you and the good and very productive discussions we had in the WG and I think we can be proud that our work items are already finding their way into main stream adoption and can help to make the Internet a little bit safer. With the last document released, we can now close our WEBSEC WG. Many thanks and many greetings, Tobias (websec co-chair) On 17/04/15 22:37, Barry Leiba wrote: > The final websec document has been published today by the RFC Editor. > With that, the websec working group has completed its work. Thanks > very much to all the participants who spent their time and effort > working on this, and especially to Tobias, Yoav, and Alexey, the > current and past chairs. > > I will be asking the Secretariat to close the working group. The > mailing list will remain open for related discussion. > > Barry, Applications AD > > > On Fri, Apr 17, 2015 at 4:38 PM, wrote: >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 7469 >> >> Title: Public Key Pinning Extension for HTTP >> Author: C. Evans, C. Palmer, R. Sleevi >> Status: Standards Track >> Stream: IETF >> Date: April 2015 >> Mailbox: cevans@google.com, >> palmer@google.com, >> sleevi@google.com >> Pages: 28 >> Characters: 61619 >> Updates/Obsoletes/SeeAlso: None >> >> I-D Tag: draft-ietf-websec-key-pinning-21.txt >> >> URL: https://www.rfc-editor.org/info/rfc7469 >> >> This document defines a new HTTP header that allows web host >> operators to instruct user agents to remember ("pin") the hosts' >> cryptographic identities over a period of time. During that time, >> user agents (UAs) will require that the host presents a certificate >> chain including at least one Subject Public Key Info structure whose >> fingerprint matches one of the pinned fingerprints for that host. By >> effectively reducing the number of trusted 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. >> >> This document is a product of the Web Security Working Group of the IETF. >> >> This is now a Proposed Standard. >> >> STANDARDS TRACK: This document specifies an Internet Standards Track >> protocol for the Internet community, and requests discussion and suggestions >> for improvements. Please refer to the current edition of the Official >> Internet Protocol Standards (https://www.rfc-editor.org/standards) for the >> standardization state and status of this protocol. Distribution of this >> memo is unlimited. >> >> This announcement is sent to the IETF-Announce and rfc-dist lists. >> To subscribe or unsubscribe, see >> https://www.ietf.org/mailman/listinfo/ietf-announce >> https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >> >> For searching the RFC series, see https://www.rfc-editor.org/search >> For downloading RFCs, see https://www.rfc-editor.org/rfc.html >> >> Requests for special distribution should be addressed to either the >> author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >> specifically noted otherwise on the RFC itself, all RFCs are for >> unlimited distribution. >> >> >> The RFC Editor Team >> Association Management Solutions, LLC >> >> > _______________________________________________ > websec mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec From alice@domblogger.net Mon Apr 20 10:02:33 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1797B1A87E9 for ; Mon, 20 Apr 2015 10:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5ppxPf-TKSG for ; Mon, 20 Apr 2015 10:02:30 -0700 (PDT) Received: from mail.domblogger.net (mail.domblogger.net [IPv6:2600:3c00::f03c:91ff:fe56:d6a2]) by ietfa.amsl.com (Postfix) with ESMTP id 529C51A87E7 for ; Mon, 20 Apr 2015 10:02:30 -0700 (PDT) Received: from new.domblogger.dev (97-94-132-133.dhcp.trlk.ca.charter.com [97.94.132.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.domblogger.net (Postfix) with ESMTPSA id B400D1178 for ; Mon, 20 Apr 2015 17:02:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=domblogger.net; s=default; t=1429549344; bh=XY6RZomKY5BJSOaM6OF+idJtoAyOjIBbcByLFTeE0ZU=; h=Date:From:To:Subject; b=HsYMAlBUkMUSuahZo3n2Y+v/ucqedxulLXvpbU4fVZJPCEK4N65COlgtYbYtsg+q5 yy0oRubqeCvY5b1VGyxzCvOJXbhrV9i8vNP3TKWwBNQJ6VJeQun7HRFhKQaIpqU76V R5+8nwyhsW3f8hWkFgeMJyozHMVE1vPFsAss8yAs= Message-ID: <5535311F.6020103@domblogger.net> Date: Mon, 20 Apr 2015 10:02:23 -0700 From: Alice Wonder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: websec@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [websec] Suggestions for Fixing PKI X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 17:03:03 -0000 Dear List, This is just for thought, I have neither the resources nor energy to push it through. I would use the existing DNS system to do the equivalent of OCSP stapling. ICANN creates a new TLD, we can call it pki. Only certificate authorities can register names in pki. The registry `Example Certificates, LTD.' would register example.pki Even though the system uses the DNS system, only a limited subset of RR types would be allowed in the pki. TLD. For example, MX and A and AAAA records etc. should not be allowed, it is a utility TLD intended to serve as infrastructure. For the serial number in the SOA record, seconds since UNIX epoch would be what I would suggest. As serial is 32-bit that will eventually wrap but DNS allows for serial to wrap. Whether it is seconds since UNIX epoch or something else doesn't matter but I do suggest the serial be standardized, and YYYYMMDDnn does not allow enough updates in a 24 hour period. BIND etc. probably shouldn't be used for the master, the master should probably be a custom server that talks to the CA's database and probably shouldn't have a public facing IP address, but bind / NSD / whatever could serve as slaves, there is no need for non-standard RR types to be used and they shouldn't be used. Each signed certificate will have a serial number assigned by the certificate authority. That may actually already exist. I would suggest they be ASCII characters <= 63 with existing DNS label limitations, but no need for hostname restrictions. For example d3we74ldqw1190 could be a valid serial number. The serial number should be included in the signed TLS certificate. For each valid certificate, the DNS server will respond as an authoritative DNS to a request for a TXT record of the serial number. For example: dig TXT d3we74ldqw1190.example.pki. +short would then get the rdata for that certificate, with a record that can be DNSSEC validated, if the certificate is valid. If the certificate is revoked, I *might* get a DNSSEC signed response. If the certificate was never issued then I would get a DNSSEC signed response stating is does not exist. NSEC is probably good enough for that, doesn't need the complexity of NSEC3 IMHO. For the rdata - it should include the OCSP uri, timestamp, and whether or not the certificate was valid at the time of the timestamp. TLS clients could then validate a certificate by doing a simple DNS query. If they don't get a DNSSEC validating response, they fall back to using the OCSP URI provided in the certificate. If they get a validating response stating the record does not exist, they reject the certificate. If they get a validating response stating the record does exist but the certificate has been revoked, they reject the certificate. If they get a validating response stating the record does exist and the certificate was not revoked, the client can then look at the timestamp and if it is recent enough - accept the certificate, otherwise do the OCSP lookup itself. This would solve the problem of certificate authorities having the ability to track users, because the client would be using their local recursive resolver to query for the information. It would also solve the problem of a sudden spike at a web site radically increasing traffic at the certificate OCSP server, because the local resolvers would cache the requests until the TTL expires. Obviously this solution needs more details and someone to take the idea to the appropriate powers, but that is how I would solve the revoked certificate problem if I was emperor of the Internet. I would personally limit the RR types to SOA, TXT, RP, and the DNSSEC RR types, and DNSSEC should be required. But there may be valid reasons for some other RR types. I would suggest that CAs push updates to the slaves every 5 to 10 minutes. For the TTL on TXT records, 1800 would be what I would use but it seems to me like a lot of resolvers ignore that and make up their own TTL. For the negative TTL I would suggest 120 seconds. But really until this is implemented those are just numbers, real usage will help refine them. Thank you for your time, Alice Wonder From nobody Mon Apr 20 11:43:11 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72E61B2CA2 for ; Mon, 20 Apr 2015 11:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THIPCojs38U0 for ; Mon, 20 Apr 2015 11:43:10 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBDA11A1A4C for ; Mon, 20 Apr 2015 11:43:09 -0700 (PDT) Received: by qcyk17 with SMTP id k17so63588496qcy.1 for ; Mon, 20 Apr 2015 11:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=zAmMYRLmMGXG+Oe7CfR1sDOXHLeWFZY3tC/b1q2q23U=; b=Hbav0qHVr7OWHhV6JQjbHx6wLsfG3x2tGRCpUyVahzFEUuy0dlFK6pl/vAbrRQ6r3F SgYsvyH6sfxf72SFTYl/4wyWUMYiK7NWaVwhDxcTCvFeDmVPjDhodza/ctLUSwU3G03d MuzLIECaa2g/Ik6AiRYgn9SNfDPkfRNNFpqkm+ANdGx/kCPNm9tGoMhy0qP4xYwPWeNE e7BR2C75115w2bdkgOdBkTm4Pc6KeXnzvQ7oVTLKViJt8Oe2c59e237ka9ibDo2Xv2+Z Cjqhm6U80ZRqNBQKLqxAGrbkVaXVlOnRAhP9hp5/g+hYsEvL+TBr9JBkFL5vGlU9LYOB oYjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=zAmMYRLmMGXG+Oe7CfR1sDOXHLeWFZY3tC/b1q2q23U=; b=lSBwqo3R8bN+f6MhNy/iM3tC/1K0J33BBQ4HsxPVb5Sq6Gcm1hT+zgmZtevpas6S1l S8Po8Lpu2g/6FWviLAF6icKKdVBtThT/OQTXd1rOFhlOt505nT63EPtN6Q4I8iK0zFEu q8UfT3/1r4WAwifM2y1cdOMM5rm80NSlsWWJLkkjoQnPEzBb+WzQSxEm1zyTK2lQqJmL EQeHgxIBKs16tZw5TfWfoECMj2o9+j2PPUHc1WjEI/fCjlb/WsFI0uXplBm7c0ZHqm6Q wcu0eUA5nsw6pC2w0ptGgtA99/+vcWPux5bcI/Xg9/irAED4wH3XvN+dy5nXSkVQ1Hp8 rRgw== X-Gm-Message-State: ALoCoQkXLe1U0sAXAzqJ53B8YDMVXpD5ut3aMDnFjG5AzMP9xlRP5TIkowVPhwU8U1QgJFZ2viDB X-Received: by 10.55.31.5 with SMTP id f5mr31148670qkf.42.1429555389137; Mon, 20 Apr 2015 11:43:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.130.69 with HTTP; Mon, 20 Apr 2015 11:42:48 -0700 (PDT) In-Reply-To: <5535311F.6020103@domblogger.net> References: <5535311F.6020103@domblogger.net> From: Adam Langley Date: Mon, 20 Apr 2015 11:42:48 -0700 Message-ID: To: Alice Wonder Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "websec@ietf.org" Subject: Re: [websec] Suggestions for Fixing PKI X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 18:43:10 -0000 On Mon, Apr 20, 2015 at 10:02 AM, Alice Wonder wrote= : > For each valid certificate, the DNS server will respond as an authoritati= ve > DNS to a request for a TXT record of the serial number. For example: > > dig TXT d3we74ldqw1190.example.pki. +short > > would then get the rdata for that certificate, with a record that can be > DNSSEC validated, if the certificate is valid. We experimented with this in Chrome, although the TXT record was planned to contain something similar to a signed, OCSP response. We found that ~3=E2=80=934% of users couldn't lookup TXT records. That rath= er sunk it since it would need to be hard-fail. Cheers AGL From nobody Tue Apr 21 13:27:54 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC6F1A8AE2; Tue, 21 Apr 2015 13:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF5an-SzTIYl; Tue, 21 Apr 2015 13:27:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B541A8ACF; Tue, 21 Apr 2015 13:27:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150421202749.29669.27395.idtracker@ietfa.amsl.com> Date: Tue, 21 Apr 2015 13:27:49 -0700 Archived-At: Cc: websec@ietf.org Subject: [websec] WG Action: Conclusion of Web Security (websec) X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 20:27:51 -0000 The Web Security (websec) working group in the Applications Area has completed its work and is now concluded. Thanks very much to all the participants who spent their time and effort working on this, and especially to Tobias, Yoav, and Alexey, the current and past chairs. The IESG contact person is Barry Leiba. The mailing list will remain open for related discussion. From nobody Mon Apr 27 04:13:21 2015 Return-Path: X-Original-To: websec@ietfa.amsl.com Delivered-To: websec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDAD1B30AF for ; Mon, 27 Apr 2015 04:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwr62ImcEbBk for ; Mon, 27 Apr 2015 04:13:19 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728061B30AE for ; Mon, 27 Apr 2015 04:13:19 -0700 (PDT) Received: by igbpi8 with SMTP id pi8so66572862igb.0 for ; Mon, 27 Apr 2015 04:13:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xvke7ozGPyd9L6KWIRi1bkQhC3S4ov7+XHJfpsW1rmE=; b=szIxByOb0MNJigREcj6FJWUgzFBmAl7dw7YUkhIhe0sLtXUTu5dUBmhc3CwxUmAkxa whpdWmbEhtg+2//2+s7TWsnkGjSULelzGESnKV82fKLVpwOOXkJFTfMrvQsH7IIiXHyK 7Bx9JcIRqlmDXjE+mdURcr1PcpwjCczsgXBKU8T4XdgwvoF3SglXgmEg4ItQr4bTdxAv T2+pvle8o7kRVziVTowPjy9kqLR730kbYdc+Nxm+gUI6TcbfOVzIT594lc5V+DjeoODA /K1wXeKnRZLqFDRoZNmIy5TpZxkJDrg5GH3Adg+638rHTUUa9hWownR7s8mBl9yq1Hg1 ycpA== MIME-Version: 1.0 X-Received: by 10.50.108.115 with SMTP id hj19mr12613463igb.34.1430133198971; Mon, 27 Apr 2015 04:13:18 -0700 (PDT) Received: by 10.36.77.15 with HTTP; Mon, 27 Apr 2015 04:13:18 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Apr 2015 07:13:18 -0400 Message-ID: From: Jeffrey Walton To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: websec Subject: Re: [websec] DNS publication of HSTS and PKP header data using CAA X-BeenThere: websec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: noloader@gmail.com List-Id: Web Application Security Minus Authentication and Transport List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 11:13:21 -0000 On Wed, Apr 8, 2015 at 6:00 PM, Phillip Hallam-Baker wrote: > http://tools.ietf.org/html/draft-hallambaker-webseccaa-00 > > It is a pretty straightforward proposal: > > * Use the CAA record with either the hsts or hpkp tag > * Put the same text you would have put into the CAA record value field > > There are a few differences in interpretation. All we are trying to do > here is to help people to close the 'secure after first use' hole, not > replace. > > Given that we have quite a bit of use of HSTS headers, providing a > mechanism for publishing this in the DNS looks like being the obvious > approach. > Off topic, but related: "Please add Pinning Pinsets and CSP to App Manifest," https://bugzilla.mozilla.org/show_bug.cgi?id=1158756. The more channels this information is available the better. Choice is always good. And context specific security information is even better.