From nobody Tue Nov 18 09:50:58 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF94C1A1C03 for ; Tue, 18 Nov 2014 09:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.498 X-Spam-Level: X-Spam-Status: No, score=0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_81=0.6, SPF_HELO_PASS=-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 gZcCx6wGAakP for ; Tue, 18 Nov 2014 09:50:50 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CB31A1BED for ; Tue, 18 Nov 2014 09:50:49 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from hypochilid-2.local ([199.119.118.21]) (authenticated user jhall@cdt.org) by mail.maclaboratory.net (using TLSv1 with cipher DHE-RSA-AES256-SHA (256 bits)) for perpass@ietf.org; Tue, 18 Nov 2014 12:50:48 -0500 Message-ID: <546B86F7.1010602@cdt.org> Date: Tue, 18 Nov 2014 12:50:47 -0500 From: Joseph Lorenzo Hall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: perpass Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/pW6IdzOuYIOcu4cKg7_PLJPDhcQ Subject: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 17:50:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 So cool I'll just shut my mouth and let the launch text speak for itself... (links in the original) - ---- https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web # Launching in 2015: A Certificate Authority to Encrypt the Entire Web Today EFF is pleased to announce Let?s Encrypt, a new certificate authority (CA) initiative that we have put together with Mozilla, Cisco, Akamai, Identrust, and researchers at the University of Michigan that aims to clear the remaining roadblocks to transition the Web from HTTP to HTTPS. Although the HTTP protocol has been hugely successful, it is inherently insecure. Whenever you use an HTTP website, you are always vulnerable to problems, including account hijacking and identity theft; surveillance and tracking by governments, companies, and both in concert; injection of malicious scripts into pages; and censorship that targets specific keywords or specific pages on sites. The HTTPS protocol, though it is not yet flawless, is a vast improvement on all of these fronts, and we need to move to a future where every website is HTTPS by default.With a launch scheduled for summer 2015, the Let?s Encrypt CA will automatically issue and manage free certificates for any website that needs them. Switching a webserver from HTTP to HTTPS with this CA will be as easy as issuing one command, or clicking one button. The biggest obstacle to HTTPS deployment has been the complexity, bureaucracy, and cost of the certificates that HTTPS requires. We?re all familiar with the warnings and error messages produced by misconfigured certificates. These warnings are a hint that HTTPS (and other uses of TLS/SSL) is dependent on a horrifyingly complex and often structurally dysfunctional bureaucracy for authentication. The need to obtain, install, and manage certificates from that bureaucracy is the largest reason that sites keep using HTTP instead of HTTPS. In our tests, it typically takes a web developer 1-3 hours to enable encryption for the first time. The Let?s Encrypt project is aiming to fix that by reducing setup time to 20-30 seconds. You can help test and hack on the developer preview of our Let's Encrypt agent software or watch a video of it in action here: Let?s Encrypt will employ a number of new technologies to manage secure automated verification of domains and issuance of certificates. We will use a protocol we?re developing called ACME between web servers and the CA, which includes support for new and stronger forms of domain validation. We will also employ Internet-wide datasets of certificates, such as EFF?s own Decentralized SSL Observatory, the University of Michigan?s scans.io, and Google's Certificate Transparency logs, to make higher-security decisions about when a certificate is safe to issue. The Let?s Encrypt CA will be operated by a new non-profit organization called the Internet Security Research Group (ISRG). EFF helped to put together this initiative with Mozilla and the University of Michigan, and it has been joined for launch by partners including Cisco, Akamai, and Identrust. The core team working on the Let's Encrypt CA and agent software includes James Kasten, Seth Schoen, and Peter Eckersley at EFF; Josh Aas, Richard Barnes, Kevin Dick and Eric Rescorla at Mozilla; Alex Halderman and James Kasten and the University of Michigan. - -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) iQIcBAEBCAAGBQJUa4b3AAoJEF+GaYdAqahx4cIQAMKfrDwarBKUHYK1EHuutF5+ vBOF/Bz9CYCVfSIhn3Re/Vze4xMF6ZRnKOnAsPdi2Im+I/KOkOKMG+W/n/z8EGht cQzow+HNKqRQ/BerieK8ziCWPy2vP/nEvJVha3KO3Oc2Y83MlxS+0KyvrT1JhkaI AG3sMm7MA0FyoGTV27wFbGsbgjGbGmqxZYPvn8MJeyIou1pZzWva1c3QqBGHWmLp aYiKQ2vMauawq5o9fmpqKa8hkS98jUS3I1kOhgE2aH7GEgudhESengr7Mb9655qY W265vk+FeT/T6GCFO4yzdzC+eey+22gumjVwKXuookSuKqTGP0kNCvCUP75o9abc yO4xkaQo3EL4R77IsqMxNtCOResBxqc8oY18JuOUzDeKhuKCwQEhWBi3l6tt9R8m GqEKJXYuedwznPFq2fpM4sL7TFSMzyV8Zx5VtyAuHlR5iyFSe+G5RVJNngHlJaOP 7RPQ4GTyHHpEqA7RDu6F7ekMJu1kJ9dGonZemR21Xdkto9xJ02nd4YSAajmJ9zdT 2eWcww2uUb0L9HhG6R2pa3gh3vECs3ShCjhzHZGSOsMxD8iAjcW62CfCRcvMii6X 7UQkvCT/eJZWpsdA0xBNxvukEJzIJFpUl7ouDZFxRYbEf9f6o6BoYfLMWcBfjif1 ej21nmdcC12JEIl5ecnH =yRrk -----END PGP SIGNATURE----- From nobody Tue Nov 18 09:54:32 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71C01A0469 for ; Tue, 18 Nov 2014 09:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_81=0.6, RP_MATCHES_RCVD=-0.594] 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 0YhaU9iAzRZl for ; Tue, 18 Nov 2014 09:54:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 393CD1A0235 for ; Tue, 18 Nov 2014 09:54:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0EF20BEC0; Tue, 18 Nov 2014 17:54:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J03-pHfSfqNo; Tue, 18 Nov 2014 17:54:24 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.46.20.163]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 067DABED8; Tue, 18 Nov 2014 17:54:24 +0000 (GMT) Message-ID: <546B87CF.8000300@cs.tcd.ie> Date: Tue, 18 Nov 2014 17:54:23 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Joseph Lorenzo Hall , perpass References: <546B86F7.1010602@cdt.org> In-Reply-To: <546B86F7.1010602@cdt.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/dxKEj9FuGAepcHJh6__VL9zV-Fc Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 17:54:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nice! Sounds extremely promising. S. On 18/11/14 17:50, Joseph Lorenzo Hall wrote: > > So cool I'll just shut my mouth and let the launch text speak for > itself... (links in the original) > > ---- > > https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web > > # Launching in 2015: A Certificate Authority to Encrypt the Entire > Web > > Today EFF is pleased to announce Let?s Encrypt, a new certificate > authority (CA) initiative that we have put together with Mozilla, > Cisco, Akamai, Identrust, and researchers at the University of > Michigan that aims to clear the remaining roadblocks to transition > the Web from HTTP to HTTPS. > > Although the HTTP protocol has been hugely successful, it is > inherently insecure. Whenever you use an HTTP website, you are > always vulnerable to problems, including account hijacking and > identity theft; surveillance and tracking by governments, > companies, and both in concert; injection of malicious scripts into > pages; and censorship that targets specific keywords or specific > pages on sites. The HTTPS protocol, though it is not yet flawless, > is a vast improvement on all of these fronts, and we need to move > to a future where every website is HTTPS by default.With a launch > scheduled for summer 2015, the Let?s Encrypt CA will automatically > issue and manage free certificates for any website that needs them. > Switching a webserver from HTTP to HTTPS with this CA will be as > easy as issuing one command, or clicking one button. > > The biggest obstacle to HTTPS deployment has been the complexity, > bureaucracy, and cost of the certificates that HTTPS requires. > We?re all familiar with the warnings and error messages produced > by misconfigured certificates. These warnings are a hint that HTTPS > (and other uses of TLS/SSL) is dependent on a horrifyingly complex > and often structurally dysfunctional bureaucracy for > authentication. > > The need to obtain, install, and manage certificates from that > bureaucracy is the largest reason that sites keep using HTTP > instead of HTTPS. In our tests, it typically takes a web developer > 1-3 hours to enable encryption for the first time. The Let?s > Encrypt project is aiming to fix that by reducing setup time to > 20-30 seconds. You can help test and hack on the developer preview > of our Let's Encrypt agent software or watch a video of it in > action here: > > Let?s Encrypt will employ a number of new technologies to manage > secure automated verification of domains and issuance of > certificates. We will use a protocol we?re developing called ACME > between web servers and the CA, which includes support for new and > stronger forms of domain validation. We will also employ > Internet-wide datasets of certificates, such as EFF?s own > Decentralized SSL Observatory, the University of Michigan?s > scans.io, and Google's Certificate Transparency logs, to make > higher-security decisions about when a certificate is safe to > issue. > > The Let?s Encrypt CA will be operated by a new non-profit > organization called the Internet Security Research Group (ISRG). > EFF helped to put together this initiative with Mozilla and the > University of Michigan, and it has been joined for launch by > partners including Cisco, Akamai, and Identrust. > > The core team working on the Let's Encrypt CA and agent software > includes James Kasten, Seth Schoen, and Peter Eckersley at EFF; > Josh Aas, Richard Barnes, Kevin Dick and Eric Rescorla at Mozilla; > Alex Halderman and James Kasten and the University of Michigan. > > > _______________________________________________ perpass mailing > list perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUa4fMAAoJEC88hzaAX42idrsH/1ESxXdSUtqFuE3Qea2neAs8 yECBMM44hIFI5Vqen/YtmNDsa8/L72mUkdaCkTEBCJdRQQt6pYigKNQZ+ZBIUUi7 VY9bhdugo/TqrszHhy+U3rCwvyBGbjBqQf4sVaNx6FOdqY0upnW8foetnYz2XbCI AO+N6SoNjxd5NkU3zY/mJ09a1tpY6/T0jeKdfoHAG1QG9DZs0bctCfwo07qV5vGv hiS1O3VrU9KRBaVcCm+IlacV1UsEc6U3n6WeXGxOG9wUTKGIvbVhyQvFUP/xgB+N D8QW5gTzf96Vc8oh/pc/LRdo3qwafarbCYHRENdKs2YciseK11OkjhK3cxdJlQI= =As8k -----END PGP SIGNATURE----- From nobody Tue Nov 18 11:07:57 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE511A6EFC for ; Tue, 18 Nov 2014 11:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, RP_MATCHES_RCVD=-0.594, 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 pYmqeSncO1k1 for ; Tue, 18 Nov 2014 11:07:48 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7AA1A1B67 for ; Tue, 18 Nov 2014 11:07:48 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 3B9B72002A; Tue, 18 Nov 2014 14:10:16 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id BE0A7637F5; Tue, 18 Nov 2014 14:07:47 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A7FE363745; Tue, 18 Nov 2014 14:07:47 -0500 (EST) From: Michael Richardson To: Joseph Lorenzo Hall In-Reply-To: <546B86F7.1010602@cdt.org> References: <546B86F7.1010602@cdt.org> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/7TitYJCQNgGLrPCLN3dUBy-DDOI Cc: perpass Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 19:07:50 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Joseph Lorenzo Hall wrote: > Let?s Encrypt will employ a number of new technologies to manage > secure automated verification of domains and issuance of certificates. > We will use a protocol we?re developing called ACME between web > servers and the CA, which includes support for new and stronger forms > of domain validation. We will also employ Internet-wide datasets of This is exciting; any interaction with cacert.org? So, some kind of online certificate enrollment. What protocols? What open source? I don't think this is is this going to help eliminate the invalid certificates that seem inevitable from things like ILOMs/iDRAC/etc. because the https interface to the service processor never knows what zone it will use. I'd love to find a way for such appliance uses of HTTPS to come up secure in some way. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVGuY/YCLcPvd0N1lAQIJcwgArlzQDELWqNG2BDaXQy+7xMJq1QD8bdvU hibZrBKlID3vPD7e7IgKBjDQuN2BMIpvdEkrcyzCR5Sy2g+kmhQZiH++7toi4Auk 4BPqZYi+WWlxTZIm/zo5r/4C88mw4S9fmZgB0l7SKEuhLpAyVGpRtxdBoXbxLaTF 7zuN3G6AvPA62a+S+BPk8otrDTzrhtzpDVZHcB+dze/pIVLfaOWcUdZPx+VRV/xY xP946re7WZYp0PLytqaOFYFmL5+TLpBGL7kyIwlWYUiyHWqh49nWEDN4ichnB2T0 k7qcJUNtYnsKnmjcpMqJrqsL3yk/tR/59CeMNW4tRu7jNJt5lrE+qA== =tbEN -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 18 11:13:43 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212091A049A for ; Tue, 18 Nov 2014 11:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.123 X-Spam-Level: * X-Spam-Status: No, score=1.123 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_81=0.6] 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 XMSbHoWm4Gai for ; Tue, 18 Nov 2014 11:13:34 -0800 (PST) Received: from linode64.ducksong.com (li629-102.members.linode.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id CA8EC1A0396 for ; Tue, 18 Nov 2014 11:13:33 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by linode64.ducksong.com (Postfix) with ESMTPSA id 683593A028 for ; Tue, 18 Nov 2014 14:13:32 -0500 (EST) Received: by mail-qc0-f176.google.com with SMTP id i17so4713628qcy.35 for ; Tue, 18 Nov 2014 11:13:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.224.74.194 with SMTP id v2mr44894689qaj.60.1416338012205; Tue, 18 Nov 2014 11:13:32 -0800 (PST) Received: by 10.140.109.70 with HTTP; Tue, 18 Nov 2014 11:13:32 -0800 (PST) In-Reply-To: <546B87CF.8000300@cs.tcd.ie> References: <546B86F7.1010602@cdt.org> <546B87CF.8000300@cs.tcd.ie> Date: Tue, 18 Nov 2014 14:13:32 -0500 Message-ID: From: Patrick McManus To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0158b34c197c39050826e42b Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/69Zlw2xkc9M0xBdDzIAA_Q6DlBY Cc: perpass , Joseph Lorenzo Hall Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 19:13:38 -0000 --089e0158b34c197c39050826e42b Content-Type: text/plain; charset=UTF-8 You can read more about the project at https://letsencrypt.org/ You can see (and participate in) the work in progress protocols (called ACME) around certificate management here: https://github.com/letsencrypt/acme-spec On Tue, Nov 18, 2014 at 12:54 PM, Stephen Farrell wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Nice! > > Sounds extremely promising. > > S. > > On 18/11/14 17:50, Joseph Lorenzo Hall wrote: > > > > So cool I'll just shut my mouth and let the launch text speak for > > itself... (links in the original) > > > > ---- > > > > > https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web > > > > # Launching in 2015: A Certificate Authority to Encrypt the Entire > > Web > > > > Today EFF is pleased to announce Let?s Encrypt, a new certificate > > authority (CA) initiative that we have put together with Mozilla, > > Cisco, Akamai, Identrust, and researchers at the University of > > Michigan that aims to clear the remaining roadblocks to transition > > the Web from HTTP to HTTPS. > > > > Although the HTTP protocol has been hugely successful, it is > > inherently insecure. Whenever you use an HTTP website, you are > > always vulnerable to problems, including account hijacking and > > identity theft; surveillance and tracking by governments, > > companies, and both in concert; injection of malicious scripts into > > pages; and censorship that targets specific keywords or specific > > pages on sites. The HTTPS protocol, though it is not yet flawless, > > is a vast improvement on all of these fronts, and we need to move > > to a future where every website is HTTPS by default.With a launch > > scheduled for summer 2015, the Let?s Encrypt CA will automatically > > issue and manage free certificates for any website that needs them. > > Switching a webserver from HTTP to HTTPS with this CA will be as > > easy as issuing one command, or clicking one button. > > > > The biggest obstacle to HTTPS deployment has been the complexity, > > bureaucracy, and cost of the certificates that HTTPS requires. > > We?re all familiar with the warnings and error messages produced > > by misconfigured certificates. These warnings are a hint that HTTPS > > (and other uses of TLS/SSL) is dependent on a horrifyingly complex > > and often structurally dysfunctional bureaucracy for > > authentication. > > > > The need to obtain, install, and manage certificates from that > > bureaucracy is the largest reason that sites keep using HTTP > > instead of HTTPS. In our tests, it typically takes a web developer > > 1-3 hours to enable encryption for the first time. The Let?s > > Encrypt project is aiming to fix that by reducing setup time to > > 20-30 seconds. You can help test and hack on the developer preview > > of our Let's Encrypt agent software or watch a video of it in > > action here: > > > > Let?s Encrypt will employ a number of new technologies to manage > > secure automated verification of domains and issuance of > > certificates. We will use a protocol we?re developing called ACME > > between web servers and the CA, which includes support for new and > > stronger forms of domain validation. We will also employ > > Internet-wide datasets of certificates, such as EFF?s own > > Decentralized SSL Observatory, the University of Michigan?s > > scans.io, and Google's Certificate Transparency logs, to make > > higher-security decisions about when a certificate is safe to > > issue. > > > > The Let?s Encrypt CA will be operated by a new non-profit > > organization called the Internet Security Research Group (ISRG). > > EFF helped to put together this initiative with Mozilla and the > > University of Michigan, and it has been joined for launch by > > partners including Cisco, Akamai, and Identrust. > > > > The core team working on the Let's Encrypt CA and agent software > > includes James Kasten, Seth Schoen, and Peter Eckersley at EFF; > > Josh Aas, Richard Barnes, Kevin Dick and Eric Rescorla at Mozilla; > > Alex Halderman and James Kasten and the University of Michigan. > > > > > > _______________________________________________ perpass mailing > > list perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUa4fMAAoJEC88hzaAX42idrsH/1ESxXdSUtqFuE3Qea2neAs8 > yECBMM44hIFI5Vqen/YtmNDsa8/L72mUkdaCkTEBCJdRQQt6pYigKNQZ+ZBIUUi7 > VY9bhdugo/TqrszHhy+U3rCwvyBGbjBqQf4sVaNx6FOdqY0upnW8foetnYz2XbCI > AO+N6SoNjxd5NkU3zY/mJ09a1tpY6/T0jeKdfoHAG1QG9DZs0bctCfwo07qV5vGv > hiS1O3VrU9KRBaVcCm+IlacV1UsEc6U3n6WeXGxOG9wUTKGIvbVhyQvFUP/xgB+N > D8QW5gTzf96Vc8oh/pc/LRdo3qwafarbCYHRENdKs2YciseK11OkjhK3cxdJlQI= > =As8k > -----END PGP SIGNATURE----- > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > --089e0158b34c197c39050826e42b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You can read more about the project at https://letsencrypt.org/
=C2=A0
You can se= e (and participate in) the work in progress protocols (called ACME) around = certificate management here: https://github.com/letsencrypt/acme-spec

On Tue, Nov 18, 2014 at 1= 2:54 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= wrote:
-----BEGIN PGP SIGNED MESSAGE----= -
Hash: SHA1


Nice!

Sounds extremely promising.

S.

On 18/11/14 17:50, Joseph Lorenzo Hall wrote:
>
> So cool I'll just shut my mouth and let the launch text speak for<= br> > itself... (links in the original)
>
> ----
>
> https://www.eff.org/deeplinks/2014/1= 1/certificate-authority-encrypt-entire-web
>
>=C2=A0 # Launching in 2015: A Certificate Authority to Encrypt the Enti= re
> Web
>
> Today EFF is pleased to announce Let?s Encrypt, a new certificate
> authority (CA) initiative that we have put together with Mozilla,
> Cisco, Akamai, Identrust, and researchers at the University of
> Michigan that aims to clear the remaining roadblocks to transition
> the Web from HTTP to HTTPS.
>
> Although the HTTP protocol has been hugely successful, it is
> inherently insecure. Whenever you use an HTTP website, you are
> always vulnerable to problems, including account hijacking and
> identity theft; surveillance and tracking by governments,
> companies, and both in concert; injection of malicious scripts into > pages; and censorship that targets specific keywords or specific
> pages on sites. The HTTPS protocol, though it is not yet flawless,
> is a vast improvement on all of these fronts, and we need to move
> to a future where every website is HTTPS by default.With a launch
> scheduled for summer 2015, the Let?s Encrypt CA will automatically
> issue and manage free certificates for any website that needs them. > Switching a webserver from HTTP to HTTPS with this CA will be as
> easy as issuing one command, or clicking one button.
>
> The biggest obstacle to HTTPS deployment has been the complexity,
> bureaucracy, and cost of the certificates that HTTPS requires.
> We?re all familiar with the warnings and error messages produced
> by misconfigured certificates. These warnings are a hint that HTTPS > (and other uses of TLS/SSL) is dependent on a horrifyingly complex
> and often structurally dysfunctional bureaucracy for
> authentication.
>
> The need to obtain, install, and manage certificates from that
> bureaucracy is the largest reason that sites keep using HTTP
> instead of HTTPS. In our tests, it typically takes a web developer
> 1-3 hours to enable encryption for the first time. The Let?s
> Encrypt project is aiming to fix that by reducing setup time to
> 20-30 seconds. You can help test and hack on the developer preview
> of our Let's Encrypt agent software or watch a video of it in
> action here:
>
> Let?s Encrypt will employ a number of new technologies to manage
> secure automated verification of domains and issuance of
> certificates. We will use a protocol we?re developing called ACME
> between web servers and the CA, which includes support for new and
> stronger forms of domain validation. We will also employ
> Internet-wide datasets of certificates, such as EFF?s own
> Decentralized SSL Observatory, the University of Michigan?s
> scans.io, and Google= 's Certificate Transparency logs, to make
> higher-security decisions about when a certificate is safe to
> issue.
>
> The Let?s Encrypt CA will be operated by a new non-profit
> organization called the Internet Security Research Group (ISRG).
> EFF helped to put together this initiative with Mozilla and the
> University of Michigan, and it has been joined for launch by
> partners including Cisco, Akamai, and Identrust.
>
> The core team working on the Let's Encrypt CA and agent software > includes James Kasten, Seth Schoen, and Peter Eckersley at EFF;
> Josh Aas, Richard Barnes, Kevin Dick and Eric Rescorla at Mozilla;
> Alex Halderman and James Kasten and the University of Michigan.
>
>
> _________________________________________= ______ perpass mailing
> list perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUa4fMAAoJEC88hzaAX42idrsH/1ESxXdSUtqFuE3Qea2neAs8
yECBMM44hIFI5Vqen/YtmNDsa8/L72mUkdaCkTEBCJdRQQt6pYigKNQZ+ZBIUUi7
VY9bhdugo/TqrszHhy+U3rCwvyBGbjBqQf4sVaNx6FOdqY0upnW8foetnYz2XbCI
AO+N6SoNjxd5NkU3zY/mJ09a1tpY6/T0jeKdfoHAG1QG9DZs0bctCfwo07qV5vGv
hiS1O3VrU9KRBaVcCm+IlacV1UsEc6U3n6WeXGxOG9wUTKGIvbVhyQvFUP/xgB+N
D8QW5gTzf96Vc8oh/pc/LRdo3qwafarbCYHRENdKs2YciseK11OkjhK3cxdJlQI=3D
=3DAs8k
-----END PGP SIGNATURE-----

_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass


--089e0158b34c197c39050826e42b-- From nobody Tue Nov 18 11:40:16 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57B11A802D for ; Tue, 18 Nov 2014 11:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594] 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 wp3amQemhvIP for ; Tue, 18 Nov 2014 11:40:12 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDED21A711A for ; Tue, 18 Nov 2014 11:40:11 -0800 (PST) Received: from [192.168.0.2] (cpe-23-240-123-116.socal.res.rr.com [23.240.123.116]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id sAIJcc28029884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 18 Nov 2014 11:38:48 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: manning bill In-Reply-To: Date: Tue, 18 Nov 2014 11:38:38 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <546B86F7.1010602@cdt.org> <546B87CF.8000300@cs.tcd.ie> To: Patrick McManus X-Mailer: Apple Mail (2.1878.6) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: bmanning@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/IyS6wxgGr1L5xSgN3x1lP_jP0EI Cc: perpass , Joseph Lorenzo Hall , Stephen Farrell Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 19:40:15 -0000 nothing more expensive than free=85 /bill PO Box 12317 Marina del Rey, CA 90295 310.322.8102 On 18November2014Tuesday, at 11:13, Patrick McManus = wrote: > You can read more about the project at https://letsencrypt.org/ > =20 > You can see (and participate in) the work in progress protocols = (called ACME) around certificate management here: = https://github.com/letsencrypt/acme-spec >=20 > On Tue, Nov 18, 2014 at 12:54 PM, Stephen Farrell = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > Nice! >=20 > Sounds extremely promising. >=20 > S. >=20 > On 18/11/14 17:50, Joseph Lorenzo Hall wrote: > > > > So cool I'll just shut my mouth and let the launch text speak for > > itself... (links in the original) > > > > ---- > > > > = https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire= -web > > > > # Launching in 2015: A Certificate Authority to Encrypt the Entire > > Web > > > > Today EFF is pleased to announce Let?s Encrypt, a new certificate > > authority (CA) initiative that we have put together with Mozilla, > > Cisco, Akamai, Identrust, and researchers at the University of > > Michigan that aims to clear the remaining roadblocks to transition > > the Web from HTTP to HTTPS. > > > > Although the HTTP protocol has been hugely successful, it is > > inherently insecure. Whenever you use an HTTP website, you are > > always vulnerable to problems, including account hijacking and > > identity theft; surveillance and tracking by governments, > > companies, and both in concert; injection of malicious scripts into > > pages; and censorship that targets specific keywords or specific > > pages on sites. The HTTPS protocol, though it is not yet flawless, > > is a vast improvement on all of these fronts, and we need to move > > to a future where every website is HTTPS by default.With a launch > > scheduled for summer 2015, the Let?s Encrypt CA will automatically > > issue and manage free certificates for any website that needs them. > > Switching a webserver from HTTP to HTTPS with this CA will be as > > easy as issuing one command, or clicking one button. > > > > The biggest obstacle to HTTPS deployment has been the complexity, > > bureaucracy, and cost of the certificates that HTTPS requires. > > We?re all familiar with the warnings and error messages produced > > by misconfigured certificates. These warnings are a hint that HTTPS > > (and other uses of TLS/SSL) is dependent on a horrifyingly complex > > and often structurally dysfunctional bureaucracy for > > authentication. > > > > The need to obtain, install, and manage certificates from that > > bureaucracy is the largest reason that sites keep using HTTP > > instead of HTTPS. In our tests, it typically takes a web developer > > 1-3 hours to enable encryption for the first time. The Let?s > > Encrypt project is aiming to fix that by reducing setup time to > > 20-30 seconds. You can help test and hack on the developer preview > > of our Let's Encrypt agent software or watch a video of it in > > action here: > > > > Let?s Encrypt will employ a number of new technologies to manage > > secure automated verification of domains and issuance of > > certificates. We will use a protocol we?re developing called ACME > > between web servers and the CA, which includes support for new and > > stronger forms of domain validation. We will also employ > > Internet-wide datasets of certificates, such as EFF?s own > > Decentralized SSL Observatory, the University of Michigan?s > > scans.io, and Google's Certificate Transparency logs, to make > > higher-security decisions about when a certificate is safe to > > issue. > > > > The Let?s Encrypt CA will be operated by a new non-profit > > organization called the Internet Security Research Group (ISRG). > > EFF helped to put together this initiative with Mozilla and the > > University of Michigan, and it has been joined for launch by > > partners including Cisco, Akamai, and Identrust. > > > > The core team working on the Let's Encrypt CA and agent software > > includes James Kasten, Seth Schoen, and Peter Eckersley at EFF; > > Josh Aas, Richard Barnes, Kevin Dick and Eric Rescorla at Mozilla; > > Alex Halderman and James Kasten and the University of Michigan. > > > > > > _______________________________________________ perpass mailing > > list perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 >=20 > iQEcBAEBAgAGBQJUa4fMAAoJEC88hzaAX42idrsH/1ESxXdSUtqFuE3Qea2neAs8 > yECBMM44hIFI5Vqen/YtmNDsa8/L72mUkdaCkTEBCJdRQQt6pYigKNQZ+ZBIUUi7 > VY9bhdugo/TqrszHhy+U3rCwvyBGbjBqQf4sVaNx6FOdqY0upnW8foetnYz2XbCI > AO+N6SoNjxd5NkU3zY/mJ09a1tpY6/T0jeKdfoHAG1QG9DZs0bctCfwo07qV5vGv > hiS1O3VrU9KRBaVcCm+IlacV1UsEc6U3n6WeXGxOG9wUTKGIvbVhyQvFUP/xgB+N > D8QW5gTzf96Vc8oh/pc/LRdo3qwafarbCYHRENdKs2YciseK11OkjhK3cxdJlQI=3D > =3DAs8k > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass >=20 >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nobody Tue Nov 18 11:45:01 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8E81A86E8 for ; Tue, 18 Nov 2014 11:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.094 X-Spam-Level: X-Spam-Status: No, score=-0.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_81=0.6, RP_MATCHES_RCVD=-0.594] 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 rEpxWVFAyScY for ; Tue, 18 Nov 2014 11:44:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 19FCC1A86E7 for ; Tue, 18 Nov 2014 11:44:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D1B90BEDB; Tue, 18 Nov 2014 19:44:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKH1_s5Wl04h; Tue, 18 Nov 2014 19:44:46 +0000 (GMT) Received: from [10.87.48.11] (unknown [86.46.20.163]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C97D9BED8; Tue, 18 Nov 2014 19:44:46 +0000 (GMT) Message-ID: <546BA1AE.6070001@cs.tcd.ie> Date: Tue, 18 Nov 2014 19:44:46 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Patrick McManus References: <546B86F7.1010602@cdt.org> <546B87CF.8000300@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/xF3pMQqxOeotL2f3KQO-cWu-I3U Cc: perpass , Joseph Lorenzo Hall Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 19:44:54 -0000 On 18/11/14 19:13, Patrick McManus wrote: > You can read more about the project at https://letsencrypt.org/ > > You can see (and participate in) the work in progress protocols (called > ACME) around certificate management here: > https://github.com/letsencrypt/acme-spec So the plan for questions/comments is just via github or is there a mailing list? Ta, S. > > On Tue, Nov 18, 2014 at 12:54 PM, Stephen Farrell > wrote: > > > Nice! > > Sounds extremely promising. > > S. > > On 18/11/14 17:50, Joseph Lorenzo Hall wrote: >>>> >>>> So cool I'll just shut my mouth and let the launch text speak for >>>> itself... (links in the original) >>>> >>>> ---- >>>> >>>> > https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt-entire-web >>>> >>>> # Launching in 2015: A Certificate Authority to Encrypt the Entire >>>> Web >>>> >>>> Today EFF is pleased to announce Let?s Encrypt, a new certificate >>>> authority (CA) initiative that we have put together with Mozilla, >>>> Cisco, Akamai, Identrust, and researchers at the University of >>>> Michigan that aims to clear the remaining roadblocks to transition >>>> the Web from HTTP to HTTPS. >>>> >>>> Although the HTTP protocol has been hugely successful, it is >>>> inherently insecure. Whenever you use an HTTP website, you are >>>> always vulnerable to problems, including account hijacking and >>>> identity theft; surveillance and tracking by governments, >>>> companies, and both in concert; injection of malicious scripts into >>>> pages; and censorship that targets specific keywords or specific >>>> pages on sites. The HTTPS protocol, though it is not yet flawless, >>>> is a vast improvement on all of these fronts, and we need to move >>>> to a future where every website is HTTPS by default.With a launch >>>> scheduled for summer 2015, the Let?s Encrypt CA will automatically >>>> issue and manage free certificates for any website that needs them. >>>> Switching a webserver from HTTP to HTTPS with this CA will be as >>>> easy as issuing one command, or clicking one button. >>>> >>>> The biggest obstacle to HTTPS deployment has been the complexity, >>>> bureaucracy, and cost of the certificates that HTTPS requires. >>>> We?re all familiar with the warnings and error messages produced >>>> by misconfigured certificates. These warnings are a hint that HTTPS >>>> (and other uses of TLS/SSL) is dependent on a horrifyingly complex >>>> and often structurally dysfunctional bureaucracy for >>>> authentication. >>>> >>>> The need to obtain, install, and manage certificates from that >>>> bureaucracy is the largest reason that sites keep using HTTP >>>> instead of HTTPS. In our tests, it typically takes a web developer >>>> 1-3 hours to enable encryption for the first time. The Let?s >>>> Encrypt project is aiming to fix that by reducing setup time to >>>> 20-30 seconds. You can help test and hack on the developer preview >>>> of our Let's Encrypt agent software or watch a video of it in >>>> action here: >>>> >>>> Let?s Encrypt will employ a number of new technologies to manage >>>> secure automated verification of domains and issuance of >>>> certificates. We will use a protocol we?re developing called ACME >>>> between web servers and the CA, which includes support for new and >>>> stronger forms of domain validation. We will also employ >>>> Internet-wide datasets of certificates, such as EFF?s own >>>> Decentralized SSL Observatory, the University of Michigan?s >>>> scans.io, and Google's Certificate Transparency logs, to make >>>> higher-security decisions about when a certificate is safe to >>>> issue. >>>> >>>> The Let?s Encrypt CA will be operated by a new non-profit >>>> organization called the Internet Security Research Group (ISRG). >>>> EFF helped to put together this initiative with Mozilla and the >>>> University of Michigan, and it has been joined for launch by >>>> partners including Cisco, Akamai, and Identrust. >>>> >>>> The core team working on the Let's Encrypt CA and agent software >>>> includes James Kasten, Seth Schoen, and Peter Eckersley at EFF; >>>> Josh Aas, Richard Barnes, Kevin Dick and Eric Rescorla at Mozilla; >>>> Alex Halderman and James Kasten and the University of Michigan. >>>> >>>> >>>> _______________________________________________ perpass mailing >>>> list perpass@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perpass >>>> >>>> >> >> _______________________________________________ >> perpass mailing list >> perpass@ietf.org >> https://www.ietf.org/mailman/listinfo/perpass >> >> > From nobody Tue Nov 18 19:55:57 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F2D1ACF67 for ; Tue, 18 Nov 2014 19:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 dnfRz_E-ZTM9 for ; Tue, 18 Nov 2014 19:55:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 478F21ACF71 for ; Tue, 18 Nov 2014 19:55:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLU13426; Wed, 19 Nov 2014 03:55:49 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Nov 2014 03:55:29 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Wed, 19 Nov 2014 11:55:24 +0800 From: "Songhaibin (A)" To: manning bill , Patrick McManus Thread-Topic: [perpass] EFF, Mozilla et al. announce new free certificate authority... Thread-Index: AQHQA1i5M62FvKFnXUmnU6RHAT1fcJxmOq4AgAAHAwCAARCy4A== Date: Wed, 19 Nov 2014 03:55:23 +0000 Message-ID: References: <546B86F7.1010602@cdt.org> <546B87CF.8000300@cs.tcd.ie> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/UbRSLp4NL8aWiBYLAtU8J6jTcP4 Cc: perpass , Joseph Lorenzo Hall , Stephen Farrell Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 03:55:55 -0000 It is now calling for attacks to test its robustness? Best Regards! -Haibin > -----Original Message----- > From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of manning bill > Sent: Wednesday, November 19, 2014 3:39 AM > To: Patrick McManus > Cc: perpass; Joseph Lorenzo Hall; Stephen Farrell > Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate > authority... >=20 > nothing more expensive than free... >=20 >=20 > /bill > PO Box 12317 > Marina del Rey, CA 90295 > 310.322.8102 >=20 > On 18November2014Tuesday, at 11:13, Patrick McManus > wrote: >=20 > > You can read more about the project at https://letsencrypt.org/ > > > > You can see (and participate in) the work in progress protocols > > (called ACME) around certificate management here: > > https://github.com/letsencrypt/acme-spec > > > > On Tue, Nov 18, 2014 at 12:54 PM, Stephen Farrell > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > Nice! > > > > Sounds extremely promising. > > > > S. > > > > On 18/11/14 17:50, Joseph Lorenzo Hall wrote: > > > > > > So cool I'll just shut my mouth and let the launch text speak for > > > itself... (links in the original) > > > > > > ---- > > > > > > https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt- > > > entire-web > > > > > > # Launching in 2015: A Certificate Authority to Encrypt the Entire > > > Web > > > > > > Today EFF is pleased to announce Let?s Encrypt, a new certificate > > > authority (CA) initiative that we have put together with Mozilla, > > > Cisco, Akamai, Identrust, and researchers at the University of > > > Michigan that aims to clear the remaining roadblocks to transition > > > the Web from HTTP to HTTPS. > > > > > > Although the HTTP protocol has been hugely successful, it is > > > inherently insecure. Whenever you use an HTTP website, you are > > > always vulnerable to problems, including account hijacking and > > > identity theft; surveillance and tracking by governments, companies, > > > and both in concert; injection of malicious scripts into pages; and > > > censorship that targets specific keywords or specific pages on > > > sites. The HTTPS protocol, though it is not yet flawless, is a vast > > > improvement on all of these fronts, and we need to move to a future > > > where every website is HTTPS by default.With a launch scheduled for > > > summer 2015, the Let?s Encrypt CA will automatically issue and > > > manage free certificates for any website that needs them. > > > Switching a webserver from HTTP to HTTPS with this CA will be as > > > easy as issuing one command, or clicking one button. > > > > > > The biggest obstacle to HTTPS deployment has been the complexity, > > > bureaucracy, and cost of the certificates that HTTPS requires. > > > We?re all familiar with the warnings and error messages produced by > > > misconfigured certificates. These warnings are a hint that HTTPS > > > (and other uses of TLS/SSL) is dependent on a horrifyingly complex > > > and often structurally dysfunctional bureaucracy for authentication. > > > > > > The need to obtain, install, and manage certificates from that > > > bureaucracy is the largest reason that sites keep using HTTP instead > > > of HTTPS. In our tests, it typically takes a web developer > > > 1-3 hours to enable encryption for the first time. The Let?s Encrypt > > > project is aiming to fix that by reducing setup time to > > > 20-30 seconds. You can help test and hack on the developer preview > > > of our Let's Encrypt agent software or watch a video of it in action > > > here: > > > > > > Let?s Encrypt will employ a number of new technologies to manage > > > secure automated verification of domains and issuance of > > > certificates. We will use a protocol we?re developing called ACME > > > between web servers and the CA, which includes support for new and > > > stronger forms of domain validation. We will also employ > > > Internet-wide datasets of certificates, such as EFF?s own > > > Decentralized SSL Observatory, the University of Michigan?s > > > scans.io, and Google's Certificate Transparency logs, to make > > > higher-security decisions about when a certificate is safe to issue. > > > > > > The Let?s Encrypt CA will be operated by a new non-profit > > > organization called the Internet Security Research Group (ISRG). > > > EFF helped to put together this initiative with Mozilla and the > > > University of Michigan, and it has been joined for launch by > > > partners including Cisco, Akamai, and Identrust. > > > > > > The core team working on the Let's Encrypt CA and agent software > > > includes James Kasten, Seth Schoen, and Peter Eckersley at EFF; Josh > > > Aas, Richard Barnes, Kevin Dick and Eric Rescorla at Mozilla; Alex > > > Halderman and James Kasten and the University of Michigan. > > > > > > > > > _______________________________________________ perpass mailing > list > > > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass > > > > > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1 > > > > > iQEcBAEBAgAGBQJUa4fMAAoJEC88hzaAX42idrsH/1ESxXdSUtqFuE3Qea2neAs8 > > > yECBMM44hIFI5Vqen/YtmNDsa8/L72mUkdaCkTEBCJdRQQt6pYigKNQZ+ZBIUU > i7 > > > VY9bhdugo/TqrszHhy+U3rCwvyBGbjBqQf4sVaNx6FOdqY0upnW8foetnYz2XbCI > > > AO+N6SoNjxd5NkU3zY/mJ09a1tpY6/T0jeKdfoHAG1QG9DZs0bctCfwo07qV5vGv > > > hiS1O3VrU9KRBaVcCm+IlacV1UsEc6U3n6WeXGxOG9wUTKGIvbVhyQvFUP/xgB > +N > > D8QW5gTzf96Vc8oh/pc/LRdo3qwafarbCYHRENdKs2YciseK11OkjhK3cxdJlQI=3D > > =3DAs8k > > -----END PGP SIGNATURE----- > > > > _______________________________________________ > > perpass mailing list > > perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass > > > > > > _______________________________________________ > > perpass mailing list > > perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nobody Tue Nov 18 23:15:10 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78DA1ACFA5 for ; Tue, 18 Nov 2014 23:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.777 X-Spam-Level: X-Spam-Status: No, score=-0.777 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 75VUrAy0gHWZ for ; Tue, 18 Nov 2014 23:15:06 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856E21ACF86 for ; Tue, 18 Nov 2014 23:15:06 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id hq12so10234347vcb.29 for ; Tue, 18 Nov 2014 23:15:05 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=osGyatgFhudwEh72hLkfmtGG3IYcT7RqUYIiV00tlmk=; b=VohqXe6rz/yfvjA7+DThLZMiiRF2n8svkPaT1gLLsNbOmyQjm2C0eKgozRAr085kBx KdJIaw0R2RS9H+2Di5OuVNs8WKTa//XCoVS/i+PU0RxwAfy2HdkIGM2I//GZjjYDwR6w tWL8nEEblr9DhPkqoeLH1zsdlDnpyH7f3DJmNLZ0Jjhx/RNxvM0rAP7KbuBq87iw7qEj Uj0idILBWaDg10TYJmg4vioLsCb9SBEMf41FvALCI+f7Vr9Lyoez3QYD4q9LsfsCLHJa rglfKbTFoxGoHKjpAa7zSnm96Cks2UbKd1bScLe5WUwieJxSJmqUsUByz9F7k6gKKAJx CKQw== X-Gm-Message-State: ALoCoQmLwR/UF0viK78i/ET00BtKch4c7BuP7raUhE9oMuTfjzmTUT4X/z2miQ++YoEht9uICudX MIME-Version: 1.0 X-Received: by 10.52.237.131 with SMTP id vc3mr30699384vdc.12.1416381305571; Tue, 18 Nov 2014 23:15:05 -0800 (PST) Received: by 10.31.149.1 with HTTP; Tue, 18 Nov 2014 23:15:05 -0800 (PST) In-Reply-To: <16017.1416337667@sandelman.ca> References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> Date: Tue, 18 Nov 2014 21:15:05 -1000 Message-ID: From: Richard Barnes To: Michael Richardson Content-Type: multipart/alternative; boundary=089e01182b2495e57a050830f8eb Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/amF25ya5rIW69XQYKJToFc0cJBU Cc: perpass , Joseph Lorenzo Hall Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 07:15:09 -0000 --089e01182b2495e57a050830f8eb Content-Type: text/plain; charset=UTF-8 On Tue, Nov 18, 2014 at 9:07 AM, Michael Richardson wrote: > > Joseph Lorenzo Hall wrote: > > Let?s Encrypt will employ a number of new technologies to manage > > secure automated verification of domains and issuance of > certificates. > > We will use a protocol we?re developing called ACME between web > > servers and the CA, which includes support for new and stronger forms > > of domain validation. We will also employ Internet-wide datasets of > > This is exciting; any interaction with cacert.org? > So, some kind of online certificate enrollment. > What protocols? What open source? > Here's what we have so far: Protocol: https://github.com/letsencrypt/acme-spec Demo Implementations: https://github.com/letsencrypt/node-acme https://github.com/letsencrypt/lets-encrypt-preview Obviously, this is a first cut, and will benefit a lot from more eyes. (AGL already pointed out something I should have caught in the first round.) This will be coming to the IETF Real Soon Now. I actually think there's a fair bit of momentum around automating certificate management, even from commercial CAs. I can't imagine that Cloudflare is doing TLS on 2M sites without some degree of automation to their cert management. > I don't think this is is this going to help eliminate the invalid > certificates that seem inevitable from things like ILOMs/iDRAC/etc. because > the https interface to the service processor never knows what zone it will > use. I'd love to find a way for such appliance uses of HTTPS to come > up secure in some way. > I would be interested in that as well, since those things are a major source of cert validation bugs. Any ideas for what the authentication would be? Or maybe there's no meaningful authentication here, and it's a use case for HTTP over unauthenticated TLS. --Richard > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > --089e01182b2495e57a050830f8eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 18, 2014 at 9:07 AM, Michael Richardson &= lt;mcr+ietf@sand= elman.ca> wrote:

Joseph Lorenzo Hall <joe@cdt.org> = wrote:
=C2=A0 =C2=A0 > Let?s Encrypt will employ a number of new technologies t= o manage
=C2=A0 =C2=A0 > secure automated verification of domains and issuance of= certificates.
=C2=A0 =C2=A0 > We will use a protocol we?re developing called ACME betw= een web
=C2=A0 =C2=A0 > servers and the CA, which includes support for new and s= tronger forms
=C2=A0 =C2=A0 > of domain validation. We will also employ Internet-wide = datasets of

This is exciting; any interaction with cacert.org?
So, some kind of online certificate enrollment.
What protocols?=C2=A0 What open source?

Here's what we have so far:

Demo Implementations:
https://github.com/letsencryp= t/node-acme
https://github.com/letsencrypt/lets-encrypt-preview

Obviously, this is a first cut, and will benefit a lot from more eye= s.=C2=A0 (AGL already pointed out something I should have caught in the fir= st round.)=C2=A0 This will be coming to the IETF Real Soon Now.

I ac= tually think there's a fair bit of momentum around automating certifica= te management, even from commercial CAs.=C2=A0 I can't imagine that Clo= udflare is doing TLS on 2M sites without some degree of automation to their= cert management.

=C2=A0
I don't think this is is this going to help eliminate the invalid
certificates that seem inevitable from things like ILOMs/iDRAC/etc. because=
the https interface to the service processor never knows what zone it will<= br> use.=C2=A0 =C2=A0 =C2=A0I'd love to find a way for such appliance uses = of HTTPS to come
up secure in some way.

I would be inter= ested in that as well, since those things are a major source of cert valida= tion bugs.=C2=A0 Any ideas for what the authentication would be?=C2=A0 Or m= aybe there's no meaningful authentication here, and it's a use case= for HTTP over unauthenticated TLS.

--Richard


=C2=A0

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass


--089e01182b2495e57a050830f8eb-- From nobody Tue Nov 18 23:17:31 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195381ACFA5 for ; Tue, 18 Nov 2014 23:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.423 X-Spam-Level: X-Spam-Status: No, score=0.423 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_52=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 gxQNsRF1ySZz for ; Tue, 18 Nov 2014 23:17:27 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D7421ACFA0 for ; Tue, 18 Nov 2014 23:17:27 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id im6so4863vcb.11 for ; Tue, 18 Nov 2014 23:17:26 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=fv7K+nWLvrKgT+QOL09PBuDe3bcUh+0iq3jofHvb0ZE=; b=A7z1QnzfyfTvMCzJS5Mw4IjGInuwdzxAKzOxvI2BF+m1/bQ67fKP7Db4I8jy2XpX+Q Kh4USFo15TRtYSpjukIWph6pjtH7jnMk+AoE+Qdyqya+l8QxFp86D8npUHcE8uNd/mbH /prRXMW3Gu+Q36WjTao6a4LvqlTQqgL5qBLj0rcvjwCAkApiayFK33ewJD2vhdiC6br/ eTgoDq44+Ou3cy5UD5Az4xjV0WnsQ4woM9+lXdoLR6cGMipctLrPMHrgQiVnjr+huYqU DTuPnoefIgUX7DxMBXgIEcaFBGzfuFqaWAwyd0jTIm83P4Oshyo3rvA01uJ3hZx1W5zV 1SPg== X-Gm-Message-State: ALoCoQmo3NE/OAqsFpC7YjypHK1x5HZ7O8nSAF478VMSfP9xeSCbUAknRsrxGtiVDzo/+haMm+WJ MIME-Version: 1.0 X-Received: by 10.220.87.1 with SMTP id u1mr901060vcl.18.1416381446245; Tue, 18 Nov 2014 23:17:26 -0800 (PST) Received: by 10.31.149.1 with HTTP; Tue, 18 Nov 2014 23:17:26 -0800 (PST) In-Reply-To: References: <546B86F7.1010602@cdt.org> <546B87CF.8000300@cs.tcd.ie> Date: Tue, 18 Nov 2014 21:17:26 -1000 Message-ID: From: Richard Barnes To: "Songhaibin (A)" Content-Type: multipart/alternative; boundary=001a11c1e5acf863d2050831000f Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/vegrOule-JR3x8wLKG4xlOAQ0wM Cc: perpass , Stephen Farrell , Patrick McManus , Joseph Lorenzo Hall , manning bill Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 07:17:30 -0000 --001a11c1e5acf863d2050831000f Content-Type: text/plain; charset=UTF-8 On Tue, Nov 18, 2014 at 5:55 PM, Songhaibin (A) wrote: > It is now calling for attacks to test its robustness? > If there were an actual CA, then maybe :) What we have now are some prototype implementations, with a goal of getting the CA stood up in the next few months. --Richard > > Best Regards! > -Haibin > > > -----Original Message----- > > From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of manning > bill > > Sent: Wednesday, November 19, 2014 3:39 AM > > To: Patrick McManus > > Cc: perpass; Joseph Lorenzo Hall; Stephen Farrell > > Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate > > authority... > > > > nothing more expensive than free... > > > > > > /bill > > PO Box 12317 > > Marina del Rey, CA 90295 > > 310.322.8102 > > > > On 18November2014Tuesday, at 11:13, Patrick McManus > > wrote: > > > > > You can read more about the project at https://letsencrypt.org/ > > > > > > You can see (and participate in) the work in progress protocols > > > (called ACME) around certificate management here: > > > https://github.com/letsencrypt/acme-spec > > > > > > On Tue, Nov 18, 2014 at 12:54 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > > > > Nice! > > > > > > Sounds extremely promising. > > > > > > S. > > > > > > On 18/11/14 17:50, Joseph Lorenzo Hall wrote: > > > > > > > > So cool I'll just shut my mouth and let the launch text speak for > > > > itself... (links in the original) > > > > > > > > ---- > > > > > > > > https://www.eff.org/deeplinks/2014/11/certificate-authority-encrypt- > > > > entire-web > > > > > > > > # Launching in 2015: A Certificate Authority to Encrypt the Entire > > > > Web > > > > > > > > Today EFF is pleased to announce Let?s Encrypt, a new certificate > > > > authority (CA) initiative that we have put together with Mozilla, > > > > Cisco, Akamai, Identrust, and researchers at the University of > > > > Michigan that aims to clear the remaining roadblocks to transition > > > > the Web from HTTP to HTTPS. > > > > > > > > Although the HTTP protocol has been hugely successful, it is > > > > inherently insecure. Whenever you use an HTTP website, you are > > > > always vulnerable to problems, including account hijacking and > > > > identity theft; surveillance and tracking by governments, companies, > > > > and both in concert; injection of malicious scripts into pages; and > > > > censorship that targets specific keywords or specific pages on > > > > sites. The HTTPS protocol, though it is not yet flawless, is a vast > > > > improvement on all of these fronts, and we need to move to a future > > > > where every website is HTTPS by default.With a launch scheduled for > > > > summer 2015, the Let?s Encrypt CA will automatically issue and > > > > manage free certificates for any website that needs them. > > > > Switching a webserver from HTTP to HTTPS with this CA will be as > > > > easy as issuing one command, or clicking one button. > > > > > > > > The biggest obstacle to HTTPS deployment has been the complexity, > > > > bureaucracy, and cost of the certificates that HTTPS requires. > > > > We?re all familiar with the warnings and error messages produced by > > > > misconfigured certificates. These warnings are a hint that HTTPS > > > > (and other uses of TLS/SSL) is dependent on a horrifyingly complex > > > > and often structurally dysfunctional bureaucracy for authentication. > > > > > > > > The need to obtain, install, and manage certificates from that > > > > bureaucracy is the largest reason that sites keep using HTTP instead > > > > of HTTPS. In our tests, it typically takes a web developer > > > > 1-3 hours to enable encryption for the first time. The Let?s Encrypt > > > > project is aiming to fix that by reducing setup time to > > > > 20-30 seconds. You can help test and hack on the developer preview > > > > of our Let's Encrypt agent software or watch a video of it in action > > > > here: > > > > > > > > Let?s Encrypt will employ a number of new technologies to manage > > > > secure automated verification of domains and issuance of > > > > certificates. We will use a protocol we?re developing called ACME > > > > between web servers and the CA, which includes support for new and > > > > stronger forms of domain validation. We will also employ > > > > Internet-wide datasets of certificates, such as EFF?s own > > > > Decentralized SSL Observatory, the University of Michigan?s > > > > scans.io, and Google's Certificate Transparency logs, to make > > > > higher-security decisions about when a certificate is safe to issue. > > > > > > > > The Let?s Encrypt CA will be operated by a new non-profit > > > > organization called the Internet Security Research Group (ISRG). > > > > EFF helped to put together this initiative with Mozilla and the > > > > University of Michigan, and it has been joined for launch by > > > > partners including Cisco, Akamai, and Identrust. > > > > > > > > The core team working on the Let's Encrypt CA and agent software > > > > includes James Kasten, Seth Schoen, and Peter Eckersley at EFF; Josh > > > > Aas, Richard Barnes, Kevin Dick and Eric Rescorla at Mozilla; Alex > > > > Halderman and James Kasten and the University of Michigan. > > > > > > > > > > > > _______________________________________________ perpass mailing > > list > > > > perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass > > > > > > > > > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1 > > > > > > > > iQEcBAEBAgAGBQJUa4fMAAoJEC88hzaAX42idrsH/1ESxXdSUtqFuE3Qea2neAs8 > > > > > yECBMM44hIFI5Vqen/YtmNDsa8/L72mUkdaCkTEBCJdRQQt6pYigKNQZ+ZBIUU > > i7 > > > > > VY9bhdugo/TqrszHhy+U3rCwvyBGbjBqQf4sVaNx6FOdqY0upnW8foetnYz2XbCI > > > > > AO+N6SoNjxd5NkU3zY/mJ09a1tpY6/T0jeKdfoHAG1QG9DZs0bctCfwo07qV5vGv > > > > > hiS1O3VrU9KRBaVcCm+IlacV1UsEc6U3n6WeXGxOG9wUTKGIvbVhyQvFUP/xgB > > +N > > > D8QW5gTzf96Vc8oh/pc/LRdo3qwafarbCYHRENdKs2YciseK11OkjhK3cxdJlQI= > > > =As8k > > > -----END PGP SIGNATURE----- > > > > > > _______________________________________________ > > > perpass mailing list > > > perpass@ietf.org > > > https://www.ietf.org/mailman/listinfo/perpass > > > > > > > > > _______________________________________________ > > > perpass mailing list > > > perpass@ietf.org > > > https://www.ietf.org/mailman/listinfo/perpass > > > > _______________________________________________ > > perpass mailing list > > perpass@ietf.org > > https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --001a11c1e5acf863d2050831000f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 18, 2014 at 5:55 PM, Songhaibin (A) <<= a href=3D"mailto:haibin.song@huawei.com" target=3D"_blank">haibin.song@huaw= ei.com> wrote:
It is now ca= lling for attacks to test its robustness?

If there were an actual CA, then maybe :)=C2=A0 What we have now are som= e prototype implementations, with a goal of getting the CA stood up in the = next few months.

--Richard

=C2=A0
=

Best Regards!
-Haibin

> -----Original Message-----
> From: perpass [mailto:perp= ass-bounces@ietf.org] On Behalf Of manning bill
> Sent: Wednesday, November 19, 2014 3:39 AM
> To: Patrick McManus
> Cc: perpass; Joseph Lorenzo Hall; Stephen Farrell
> Subject: Re: [perpass] EFF, Mozilla et al. announce new free certifica= te
> authority...
>
> nothing more expensive than free...
>
>
> /bill
> PO Box 12317
> Marina del Rey, CA 90295
> 310.322.8102 >
> On 18November2014Tuesday, at 11:13, Patrick McManus
> <pmcmanus@mozilla.com&g= t; wrote:
>
> > You can read more about the project at https://letsencrypt.org/
> >
> > You can see (and participate in) the work in progress protocols > > (called ACME) around certificate management here:
> > https://github.com/letsencrypt/acme-spec
> >
> > On Tue, Nov 18, 2014 at 12:54 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> > Nice!
> >
> > Sounds extremely promising.
> >
> > S.
> >
> > On 18/11/14 17:50, Joseph Lorenzo Hall wrote:
> > >
> > > So cool I'll just shut my mouth and let the launch text = speak for
> > > itself... (links in the original)
> > >
> > > ----
> > >
> > > https://www.eff.org/deeplinks/2014/1= 1/certificate-authority-encrypt-
> > > entire-web
> > >
> > >=C2=A0 # Launching in 2015: A Certificate Authority to Encryp= t the Entire
> > > Web
> > >
> > > Today EFF is pleased to announce Let?s Encrypt, a new certif= icate
> > > authority (CA) initiative that we have put together with Moz= illa,
> > > Cisco, Akamai, Identrust, and researchers at the University = of
> > > Michigan that aims to clear the remaining roadblocks to tran= sition
> > > the Web from HTTP to HTTPS.
> > >
> > > Although the HTTP protocol has been hugely successful, it is=
> > > inherently insecure. Whenever you use an HTTP website, you a= re
> > > always vulnerable to problems, including account hijacking a= nd
> > > identity theft; surveillance and tracking by governments, co= mpanies,
> > > and both in concert; injection of malicious scripts into pag= es; and
> > > censorship that targets specific keywords or specific pages = on
> > > sites. The HTTPS protocol, though it is not yet flawless, is= a vast
> > > improvement on all of these fronts, and we need to move to a= future
> > > where every website is HTTPS by default.With a launch schedu= led for
> > > summer 2015, the Let?s Encrypt CA will automatically issue a= nd
> > > manage free certificates for any website that needs them. > > > Switching a webserver from HTTP to HTTPS with this CA will b= e as
> > > easy as issuing one command, or clicking one button.
> > >
> > > The biggest obstacle to HTTPS deployment has been the comple= xity,
> > > bureaucracy, and cost of the certificates that HTTPS require= s.
> > > We?re all familiar with the warnings and error messages prod= uced by
> > > misconfigured certificates. These warnings are a hint that H= TTPS
> > > (and other uses of TLS/SSL) is dependent on a horrifyingly c= omplex
> > > and often structurally dysfunctional bureaucracy for authent= ication.
> > >
> > > The need to obtain, install, and manage certificates from th= at
> > > bureaucracy is the largest reason that sites keep using HTTP= instead
> > > of HTTPS. In our tests, it typically takes a web developer > > > 1-3 hours to enable encryption for the first time. The Let?s= Encrypt
> > > project is aiming to fix that by reducing setup time to
> > > 20-30 seconds. You can help test and hack on the developer p= review
> > > of our Let's Encrypt agent software or watch a video of = it in action
> > > here:
> > >
> > > Let?s Encrypt will employ a number of new technologies to ma= nage
> > > secure automated verification of domains and issuance of
> > > certificates. We will use a protocol we?re developing called= ACME
> > > between web servers and the CA, which includes support for n= ew and
> > > stronger forms of domain validation. We will also employ
> > > Internet-wide datasets of certificates, such as EFF?s own > > > Decentralized SSL Observatory, the University of Michigan?s<= br> > > > scans.io, = and Google's Certificate Transparency logs, to make
> > > higher-security decisions about when a certificate is safe t= o issue.
> > >
> > > The Let?s Encrypt CA will be operated by a new non-profit > > > organization called the Internet Security Research Group (IS= RG).
> > > EFF helped to put together this initiative with Mozilla and = the
> > > University of Michigan, and it has been joined for launch by=
> > > partners including Cisco, Akamai, and Identrust.
> > >
> > > The core team working on the Let's Encrypt CA and agent = software
> > > includes James Kasten, Seth Schoen, and Peter Eckersley at E= FF; Josh
> > > Aas, Richard Barnes, Kevin Dick and Eric Rescorla at Mozilla= ; Alex
> > > Halderman and James Kasten and the University of Michigan. > > >
> > >
> > > _______________________________________________ perpass mail= ing
> list
> > > perpass@ietf.org ht= tps://www.ietf.org/mailman/listinfo/perpass
> > >
> > >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> >
> iQEcBAEBAgAGBQJUa4fMAAoJEC88hzaAX42idrsH/1ESxXdSUtqFuE3Qea2neAs8
> >
> yECBMM44hIFI5Vqen/YtmNDsa8/L72mUkdaCkTEBCJdRQQt6pYigKNQZ+ZBIUU
> i7
> >
> VY9bhdugo/TqrszHhy+U3rCwvyBGbjBqQf4sVaNx6FOdqY0upnW8foetnYz2XbCI
> >
> AO+N6SoNjxd5NkU3zY/mJ09a1tpY6/T0jeKdfoHAG1QG9DZs0bctCfwo07qV5vGv
> >
> hiS1O3VrU9KRBaVcCm+IlacV1UsEc6U3n6WeXGxOG9wUTKGIvbVhyQvFUP/xgB
> +N
> > D8QW5gTzf96Vc8oh/pc/LRdo3qwafarbCYHRENdKs2YciseK11OkjhK3cxdJlQI= =3D
> > =3DAs8k
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > perpass mailing list
> > perpass@ietf.org
> > https://www.ietf.org/mailman/listinfo/perpass
> >
> >
> > _______________________________________________
> > perpass mailing list
> > perpass@ietf.org
> > https://www.ietf.org/mailman/listinfo/perpass
>
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass

_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass

--001a11c1e5acf863d2050831000f-- From nobody Wed Nov 19 15:42:30 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A611A3B9E for ; Wed, 19 Nov 2014 15:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 cGyDyZDHdsHk for ; Wed, 19 Nov 2014 15:42:25 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81BD11A3B9C for ; Wed, 19 Nov 2014 15:42:25 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2EBD020012 for ; Wed, 19 Nov 2014 18:44:57 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 82BDB637F5; Wed, 19 Nov 2014 18:42:24 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6CB6B63745 for ; Wed, 19 Nov 2014 18:42:24 -0500 (EST) From: Michael Richardson To: perpass In-Reply-To: References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/9MPyf3a4kVrH3MNa2Mc486jXOEo Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 23:42:28 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Richard Barnes wrote: >> I don't think this is is this going to help eliminate the invalid >> certificates that seem inevitable from things like ILOMs/iDRAC/etc. = because >> the https interface to the service processor never knows what zone i= t will >> use. I'd love to find a way for such appliance uses of HTTPS to = come >> up secure in some way. >>=20 > I would be interested in that as well, since those things are a major > source of cert validation bugs. Any ideas for what the authentication > would be? Or maybe there's no meaningful authentication here, and it= 's a > use case for HTTP over unauthenticated TLS. I agree that given what we have here, HTTP over unauthenticated TLS (with TOFU, ideally) would be significant better than training IT managers to cli= ck through the warning. I think that we should have, as a goal, elimination of the click through certificate warning... nobody should ever do that. In the case of an ILOM, we can't predict a name or an IP address which the device can claim... but, the manufacturer usually has a MAC address, Asset Tag, or other identifier which is often unique. If only *THAT* could go in= to the Location Bar instead of the IP address. Yes, this is user interface thing... sorta.. it's really about a different kind of URI. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVG0q3YCLcPvd0N1lAQLvqAf/ZW9gYBkOl8MZQOycynOj59Qat65SkCpj nuQVByWwTJqyW+RpnZb3qTs3ZHvm1pipKvk+zz5AG7yHRPlFhMWEcHhX3Wzc7ll1 SqF1I1gesepKNE9a3qVjeHL4DDGqTARkP/cs9P0j5Df9WlfdK5mYTLL4/pVazaiM zKycxUDHEHSs4R92HWkUmkK/PfkRhJ2QDWXB1SSl460iS53xlDKZGbfdx6tDZi5V NZLGs57abOezmFhelnHVrEPuQB9slg4mA8TdCxDeSvIK1YAgIJlq1GpoUjfS4eWw EeTZaPQeyPrWiDG5PCYLb/2kmCV3W1oIdHEqQQOEF8oMS5jGZjB5CQ== =i88t -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 19 15:47:06 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD79A1A1ABE for ; Wed, 19 Nov 2014 15:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_ZWpZSmFO6v for ; Wed, 19 Nov 2014 15:47:02 -0800 (PST) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDEB1A1A7C for ; Wed, 19 Nov 2014 15:47:02 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id id10so892664vcb.18 for ; Wed, 19 Nov 2014 15:47:01 -0800 (PST) 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:date :message-id:subject:from:to:cc:content-type; bh=CCvDaMBgVPomVBOryJfJW8LhUCPnjbgtRZsu1c2XgC0=; b=C7xH9a53XoA/lCwMrQDq104B/vqKC60dzObZYsOOma0IOdiuTIDiVpgz8sr95CBuKu Yjk1hsGZ/ahCHprh/ZZiuXkN+lRtnhjw9OhhComynykvUwRtQUd/HKQKrVCgsQoMJiSK 3Cx5iqI4Vd2jeFBF9uxavkgJWDuo/6fYbEQiBTN+QsmIpE2+4GC8RulIT43vSLiZqt3l rLw/Ft516E0DfXx9a3YQEm6N019d7ZJ34+nnUXEEql666qRotFpwjOoCx4Q9rhUCa+jH e01VKwiN0QR+bUOMdKdjXkti92eD/ko7MUSb7hZRxXbKCWzaAfLgvWpYMhoT7tw639fF tOuw== X-Gm-Message-State: ALoCoQmARNJUo3vQkfawysSU/W1bDW37STnWcO9NgNLZNvD6ResVCAczsrTjpSsQ5ZCDhjkQV8mz MIME-Version: 1.0 X-Received: by 10.220.118.194 with SMTP id w2mr39947570vcq.24.1416440821696; Wed, 19 Nov 2014 15:47:01 -0800 (PST) Received: by 10.31.149.1 with HTTP; Wed, 19 Nov 2014 15:47:01 -0800 (PST) In-Reply-To: <26158.1416440544@sandelman.ca> References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> Date: Wed, 19 Nov 2014 13:47:01 -1000 Message-ID: From: Richard Barnes To: Michael Richardson Content-Type: multipart/alternative; boundary=001a1132f4ba05f5d405083ed4ad Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/mFA3L8ev1W1d2J8KojGCoI3g3bw Cc: perpass Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 23:47:05 -0000 --001a1132f4ba05f5d405083ed4ad Content-Type: text/plain; charset=UTF-8 On Wed, Nov 19, 2014 at 1:42 PM, Michael Richardson wrote: > > Richard Barnes wrote: > >> I don't think this is is this going to help eliminate the invalid > >> certificates that seem inevitable from things like ILOMs/iDRAC/etc. > because > >> the https interface to the service processor never knows what zone > it will > >> use. I'd love to find a way for such appliance uses of HTTPS to > come > >> up secure in some way. > >> > > > I would be interested in that as well, since those things are a major > > source of cert validation bugs. Any ideas for what the > authentication > > would be? Or maybe there's no meaningful authentication here, and > it's a > > use case for HTTP over unauthenticated TLS. > > I agree that given what we have here, HTTP over unauthenticated TLS (with > TOFU, ideally) would be significant better than training IT managers to > click > through the warning. I think that we should have, as a goal, elimination > of > the click through certificate warning... nobody should ever do that. > > In the case of an ILOM, we can't predict a name or an IP address which the > device can claim... but, the manufacturer usually has a MAC address, Asset > Tag, or other identifier which is often unique. If only *THAT* could go > into > the Location Bar instead of the IP address. Yes, this is user interface > thing... sorta.. it's really about a different kind of URI. > We do have some history of putting identifiers besides domain names in the URL bar. Namely with EV certs, browsers typically display the authenticated owner name. So the real question is whether it's possible to make a PKI that can authenticate those identifiers. We would of course need some new types for subjectAltName, but that's just more OIDs. The more interesting question is how the PKI would be structured -- who are the trusted authorities for asset tags? --Richard > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > --001a1132f4ba05f5d405083ed4ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 19, 2014 at 1:42 PM, Michael Richardson &= lt;mcr+ietf@sand= elman.ca> wrote:

Richard Barnes <rlb@ipv.sx> wrote:
=C2=A0 =C2=A0 >> I don't think this is is this going to help elim= inate the invalid
=C2=A0 =C2=A0 >> certificates that seem inevitable from things like I= LOMs/iDRAC/etc. because
=C2=A0 =C2=A0 >> the https interface to the service processor never k= nows what zone it will
=C2=A0 =C2=A0 >> use.=C2=A0 =C2=A0 =C2=A0I'd love to find a way f= or such appliance uses of HTTPS to come
=C2=A0 =C2=A0 >> up secure in some way.
=C2=A0 =C2=A0 >>

=C2=A0 =C2=A0 > I would be interested in that as well, since those thing= s are a major
=C2=A0 =C2=A0 > source of cert validation bugs.=C2=A0 Any ideas for what= the authentication
=C2=A0 =C2=A0 > would be?=C2=A0 Or maybe there's no meaningful authe= ntication here, and it's a
=C2=A0 =C2=A0 > use case for HTTP over unauthenticated TLS.

I agree that given what we have here, HTTP over unauthenticated TLS = (with
TOFU, ideally) would be significant better than training IT managers to cli= ck
through the warning.=C2=A0 I think that we should have, as a goal, eliminat= ion of
the click through certificate warning... nobody should ever do that.

In the case of an ILOM, we can't predict a name or an IP address which = the
device can claim... but, the manufacturer usually has a MAC address, Asset<= br> Tag, or other identifier which is often unique.=C2=A0 If only *THAT* could = go into
the Location Bar instead of the IP address.=C2=A0 Yes, this is user interfa= ce
thing... sorta.. it's really about a different kind of URI.

We do have some history of putting identifiers bes= ides domain names in the URL bar.=C2=A0 Namely with EV certs, browsers typi= cally display the authenticated owner name.

So= the real question is whether it's possible to make a PKI that can auth= enticate those identifiers.=C2=A0 We would of course need some new types fo= r subjectAltName, but that's just more OIDs.=C2=A0 The more interesting= question is how the PKI would be structured -- who are the trusted authori= ties for asset tags?

--Richard

=C2=A0

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-




_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass


--001a1132f4ba05f5d405083ed4ad-- From nobody Thu Nov 20 10:01:55 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E20171A1AB4 for ; Thu, 20 Nov 2014 10:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 h-PqLog0upow for ; Thu, 20 Nov 2014 10:01:47 -0800 (PST) Received: from mr11p24im-asmtp001.me.com (mr11p24im-asmtp001.me.com [17.110.78.41]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01A01A1A17 for ; Thu, 20 Nov 2014 10:01:46 -0800 (PST) Received: from Den (c-67-183-152-156.hsd1.wa.comcast.net [67.183.152.156]) by mr11p24im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NFC005U4NEWZO60@mr11p24im-asmtp001.me.com> for perpass@ietf.org; Thu, 20 Nov 2014 18:01:46 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-20_08:2014-11-20,2014-11-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411200141 From: Trevor Freeman To: 'Richard Barnes' , 'Michael Richardson' References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> In-reply-to: Date: Thu, 20 Nov 2014 10:01:37 -0800 Message-id: <005401d004ec$08882f00$19988d00$@icloud.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_0055_01D004A8.FA6738F0" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQEBXdEcujp4vtkEDWHjdeYYdwnbIAH58s0yAcRCl2EBwccg+gM3Jsm1ncFhkAA= Content-language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/iZR4P7pUAAOO8i69B_TICKTOF4c Cc: 'perpass' Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 18:01:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0055_01D004A8.FA6738F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The certificate warning paradigm is over blown given that the typical = alternative is no TLS. An unauthenticated TLS connection is practically = speaking, no different to no TLS at all. The same of true when you see = certificate warring messages S/MIME messages when the rest of the inbox = is unsigned email. As long as the two cases are treated equal why cannot = you dispense with the certificate warning messages? =20 From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Richard = Barnes Sent: Wednesday, November 19, 2014 3:47 PM To: Michael Richardson Cc: perpass Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate = authority... =20 =20 =20 On Wed, Nov 19, 2014 at 1:42 PM, Michael Richardson = wrote: Richard Barnes wrote: >> I don't think this is is this going to help eliminate the invalid >> certificates that seem inevitable from things like = ILOMs/iDRAC/etc. because >> the https interface to the service processor never knows what = zone it will >> use. I'd love to find a way for such appliance uses of HTTPS = to come >> up secure in some way. >> > I would be interested in that as well, since those things are a = major > source of cert validation bugs. Any ideas for what the = authentication > would be? Or maybe there's no meaningful authentication here, and = it's a > use case for HTTP over unauthenticated TLS. I agree that given what we have here, HTTP over unauthenticated TLS = (with TOFU, ideally) would be significant better than training IT managers to = click through the warning. I think that we should have, as a goal, = elimination of the click through certificate warning... nobody should ever do that. In the case of an ILOM, we can't predict a name or an IP address which = the device can claim... but, the manufacturer usually has a MAC address, = Asset Tag, or other identifier which is often unique. If only *THAT* could go = into the Location Bar instead of the IP address. Yes, this is user interface thing... sorta.. it's really about a different kind of URI. =20 We do have some history of putting identifiers besides domain names in = the URL bar. Namely with EV certs, browsers typically display the = authenticated owner name. =20 So the real question is whether it's possible to make a PKI that can = authenticate those identifiers. We would of course need some new types = for subjectAltName, but that's just more OIDs. The more interesting = question is how the PKI would be structured -- who are the trusted = authorities for asset tags? --Richard =20 -- Michael Richardson >, Sandelman Software Works -=3D IPv6 IoT consulting =3D- _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass =20 ------=_NextPart_000_0055_01D004A8.FA6738F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The certificate warning paradigm is over blown given that the typical = alternative is no TLS. An unauthenticated TLS connection is practically = speaking, no different to no TLS at all. The same of true when you see = certificate warring messages =C2=A0S/MIME messages when the rest of the = inbox is unsigned email. As long as the two cases are treated equal why = cannot you dispense with the certificate warning = messages?

 

From:= = perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Wednesday, November 19, 2014 3:47 = PM
To: Michael Richardson
Cc: = perpass
Subject: Re: [perpass] EFF, Mozilla et al. announce = new free certificate authority...

 

 

 

On Wed, = Nov 19, 2014 at 1:42 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Richard Barnes <rlb@ipv.sx> wrote:
    = >> I don't think this is is this going to help eliminate the = invalid
    >> certificates that seem inevitable from = things like ILOMs/iDRAC/etc. because
    >> the https = interface to the service processor never knows what zone it = will
    >> use.     I'd love to find = a way for such appliance uses of HTTPS to come
    >> = up secure in some way.
    >>

    = > I would be interested in that as well, since those things are a = major
    > source of cert validation bugs.  Any = ideas for what the authentication
    > would be?  = Or maybe there's no meaningful authentication here, and it's a
  =   > use case for HTTP over unauthenticated TLS.

I agree = that given what we have here, HTTP over unauthenticated TLS = (with
TOFU, ideally) would be significant better than training IT = managers to click
through the warning.  I think that we should = have, as a goal, elimination of
the click through certificate = warning... nobody should ever do that.

In the case of an ILOM, we = can't predict a name or an IP address which the
device can claim... = but, the manufacturer usually has a MAC address, Asset
Tag, or other = identifier which is often unique.  If only *THAT* could go = into
the Location Bar instead of the IP address.  Yes, this is = user interface
thing... sorta.. it's really about a different kind of = URI.

 

We do have some history of putting identifiers besides = domain names in the URL bar.  Namely with EV certs, browsers = typically display the authenticated owner = name.

 

So the real question is whether it's = possible to make a PKI that can authenticate those identifiers.  We = would of course need some new types for subjectAltName, but that's just = more OIDs.  The more interesting question is how the PKI would be = structured -- who are the trusted authorities for asset = tags?

--Richard


 


--
Michael Richardson <mcr+IETF@sandelman.ca>, = Sandelman Software Works
 -=3D IPv6 IoT consulting = =3D-



______________________________________= _________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass<= /o:p>

 

------=_NextPart_000_0055_01D004A8.FA6738F0-- From nobody Thu Nov 20 10:17:24 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E612F1A1A9F for ; Thu, 20 Nov 2014 10:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 AvRuglAtvVX3 for ; Thu, 20 Nov 2014 10:17:19 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4891A1A8C for ; Thu, 20 Nov 2014 10:17:19 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id q107so2459439qgd.7 for ; Thu, 20 Nov 2014 10:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=e+GWsFmc6KV+HGfDAPjgxhVrJdbKcwTUDc+3T7dqajk=; b=nMmj8izpx6Ctvd7weVq33OKc/9Ws8RNQ6gcp/zIMcb1BIa4e6O27sGR8TACld6yPr0 MhkwdRRj4iiMJ5lnUR7nFl2eFrZQJdPOoAFU+5gAgoeeZpWLgCyjZalIgiPNt/uRapsY s+CqWSiSUKgWoVRrPO/SxlBYm7phJnjSgCfq7zGVzB+02sd7cHWK7nfHv8VU127iJtNC xZmenzQP8sSlg1/7InTG4e59pMmVJ2FZjo6IvaRA5zovm7kK3V/G3gR9W3R13y305bft muSQ2+K/lYtHupxIkHANh/P1TEL9l6dx8j5QE9DO+iOtARKz3iOM15WWT34nY5i0/Se1 gT/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:cc:content-type; bh=e+GWsFmc6KV+HGfDAPjgxhVrJdbKcwTUDc+3T7dqajk=; b=SeY0jIrkW945poNQykWAokp6B7iLxOb6BS9UbwG0C23R+auYMKyXqxtK7/TR/4zvQA z/QfhB2KsPzJNopcU4tUmJn0S3tBLtMhJ26xcFjqmZVrnFxUbMUtwty5minVE32OlTgy /Y2j80E8CDZvJBOOhzNI95T/B0vqzYVov1qikeMltkpZLRMnIPEjsXuhGE7xK+IT3hF+ TS2ag34r73n56VCFLtusIv6VzIuvUb/udECLfaegto6JhXVS0H4ipJ/usJTVduw5zCsK kOVrXEwFRAc3tsc794V/HYbhujGWsauS1iAWAMiEdTJ7Y+bnJ7Vj/EowvSaDs+ekz66P /CKQ== X-Gm-Message-State: ALoCoQlo9Q9I96mHZss/Bv61mRVD3QCVXqkX4a9QugR6yP0qfgCpQhFvlnXYO3iitrSxxUQ3phdA X-Received: by 10.224.37.133 with SMTP id x5mr14611292qad.59.1416507438583; Thu, 20 Nov 2014 10:17:18 -0800 (PST) MIME-Version: 1.0 References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> From: Ben Laurie Date: Thu, 20 Nov 2014 18:17:17 +0000 Message-ID: To: Trevor Freeman , Richard Barnes , Michael Richardson Content-Type: multipart/alternative; boundary=001a11c1f4bab30aa305084e5623 Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/DBBmMfG5jBoLT1ZPcwMqaZxjjZo Cc: perpass Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 18:17:23 -0000 --001a11c1f4bab30aa305084e5623 Content-Type: text/plain; charset=UTF-8 On Thu Nov 20 2014 at 6:02:00 PM Trevor Freeman wrote: > The certificate warning paradigm is over blown given that the typical > alternative is no TLS. An unauthenticated TLS connection is practically > speaking, no different to no TLS at all. > It is different: it is secure against passive attackers. > The same of true when you see certificate warring messages S/MIME > messages when the rest of the inbox is unsigned email. As long as the two > cases are treated equal why cannot you dispense with the certificate > warning messages? > > > > *From:* perpass [mailto:perpass-bounces@ietf.org] *On Behalf Of *Richard > Barnes > *Sent:* Wednesday, November 19, 2014 3:47 PM > *To:* Michael Richardson > *Cc:* perpass > > > *Subject:* Re: [perpass] EFF, Mozilla et al. announce new free > certificate authority... > > > > > > > > On Wed, Nov 19, 2014 at 1:42 PM, Michael Richardson > wrote: > > > Richard Barnes wrote: > >> I don't think this is is this going to help eliminate the invalid > >> certificates that seem inevitable from things like ILOMs/iDRAC/etc. > because > >> the https interface to the service processor never knows what zone > it will > >> use. I'd love to find a way for such appliance uses of HTTPS to > come > >> up secure in some way. > >> > > > I would be interested in that as well, since those things are a major > > source of cert validation bugs. Any ideas for what the > authentication > > would be? Or maybe there's no meaningful authentication here, and > it's a > > use case for HTTP over unauthenticated TLS. > > I agree that given what we have here, HTTP over unauthenticated TLS (with > TOFU, ideally) would be significant better than training IT managers to > click > through the warning. I think that we should have, as a goal, elimination > of > the click through certificate warning... nobody should ever do that. > > In the case of an ILOM, we can't predict a name or an IP address which the > device can claim... but, the manufacturer usually has a MAC address, Asset > Tag, or other identifier which is often unique. If only *THAT* could go > into > the Location Bar instead of the IP address. Yes, this is user interface > thing... sorta.. it's really about a different kind of URI. > > > > We do have some history of putting identifiers besides domain names in the > URL bar. Namely with EV certs, browsers typically display the > authenticated owner name. > > > > So the real question is whether it's possible to make a PKI that can > authenticate those identifiers. We would of course need some new types for > subjectAltName, but that's just more OIDs. The more interesting question > is how the PKI would be structured -- who are the trusted authorities for > asset tags? > > --Richard > > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass > --001a11c1f4bab30aa305084e5623 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu Nov 20 2014 at 6:02:00 PM Trevor = Freeman <trevor.freeman99= @icloud.com> wrote:

The certificate warning paradigm is over blown given that = the typical alternative is no TLS. An unauthenticated TLS connection is pra= ctically speaking, no different to no TLS at all.


It is different: it is secure against passive= attackers.
=C2=A0

The same of true when you see certificate warring m= essages =C2=A0S/MIME messages when the rest of the inbox is unsigned email.= As long as the two cases are treated equal why cannot you dispense with th= e certificate warning messages?

=C2=A0

From: perpass [mailto:perpass-bounces@ie= tf.org] On Behalf Of Richard Barnes
Sent: Wednesday, N= ovember 19, 2014 3:47 PM
To: Michael Richardson
Cc: per= pass


Subject: Re: [perpass= ] EFF, Mozilla et al. announce new free certificate authority...<= /u>

=C2=A0

=C2=A0

=C2=A0

On Wed, Nov 19, 2014 at 1:42 PM, Michael Richardson <mcr+ietf@sandelman.ca>= ; wrote:

=
Richard Barnes <rlb@= ipv.sx> wrote:
=C2=A0 =C2=A0 >> I don't think this is i= s this going to help eliminate the invalid
=C2=A0 =C2=A0 >> certif= icates that seem inevitable from things like ILOMs/iDRAC/etc. because
= =C2=A0 =C2=A0 >> the https interface to the service processor never k= nows what zone it will
=C2=A0 =C2=A0 >> use.=C2=A0 =C2=A0 =C2=A0I&= #39;d love to find a way for such appliance uses of HTTPS to come
=C2=A0= =C2=A0 >> up secure in some way.
=C2=A0 =C2=A0 >>

= =C2=A0 =C2=A0 > I would be interested in that as well, since those thing= s are a major
=C2=A0 =C2=A0 > source of cert validation bugs.=C2=A0 A= ny ideas for what the authentication
=C2=A0 =C2=A0 > would be?=C2=A0 = Or maybe there's no meaningful authentication here, and it's a
= =C2=A0 =C2=A0 > use case for HTTP over unauthenticated TLS.

I agr= ee that given what we have here, HTTP over unauthenticated TLS (with
TOF= U, ideally) would be significant better than training IT managers to click<= br>through the warning.=C2=A0 I think that we should have, as a goal, elimi= nation of
the click through certificate warning... nobody should ever do= that.

In the case of an ILOM, we can't predict a name or an IP = address which the
device can claim... but, the manufacturer usually has = a MAC address, Asset
Tag, or other identifier which is often unique.=C2= =A0 If only *THAT* could go into
the Location Bar instead of the IP addr= ess.=C2=A0 Yes, this is user interface
thing... sorta.. it's really = about a different kind of URI.

=C2=A0

We do have some = history of putting identifiers besides domain names in the URL bar.=C2=A0 N= amely with EV certs, browsers typically display the authenticated owner nam= e.

=C2=A0<= /p>

So the = real question is whether it's possible to make a PKI that can authentic= ate those identifiers.=C2=A0 We would of course need some new types for sub= jectAltName, but that's just more OIDs.=C2=A0 The more interesting ques= tion is how the PKI would be structured -- who are the trusted authorities = for asset tags?

--Richar= d


=C2=A0

<= p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">
--
Michael Rich= ardson <mcr= +IETF@sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT= consulting =3D-



__________________________________= _____________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/l= istinfo/perpass

<= /div>_______________________________________________
perpass mailing list
perpass@ietf.org<= br> https://www.ietf.org/mailman/listinfo/perpass
--001a11c1f4bab30aa305084e5623-- From nobody Thu Nov 20 10:25:38 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5BA1A19F2 for ; Thu, 20 Nov 2014 10:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 tcaR2C_rAO-D for ; Thu, 20 Nov 2014 10:25:33 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97751A212A for ; Thu, 20 Nov 2014 10:25:14 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B4A642002A; Thu, 20 Nov 2014 13:27:48 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5FBA1637F5; Thu, 20 Nov 2014 13:25:13 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 49E0B637EA; Thu, 20 Nov 2014 13:25:13 -0500 (EST) From: Michael Richardson To: Richard Barnes In-Reply-To: References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/vWzJCluOUUe1DYSlL6SCthEhTyM Cc: perpass Subject: [perpass] getting rid of appliance/ilom invalid certificate warnings X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 18:25:36 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On Wed, Nov 19, 2014 at 1:42 PM, Michael Richardson wrote: > In the case of an ILOM, we can't predict a name or an IP address which the > device can claim... but, the manufacturer usually has a MAC address, Asset > Tag, or other identifier which is often unique. If only *THAT* could go > into > the Location Bar instead of the IP address. Yes, this is user interface > thing... sorta.. it's really about a different kind of URI. > rlb> We do have some history of putting identifiers besides domain names rlb> in the URL bar. Namely with EV certs, browsers typically display = the rlb> authenticated owner name. okay, but in my experience the EV cert still has to match the host part of the zone that the user typed in. ILOMs, home appliances, etc. get an IP address by DHCP or SLAAC. In the IPv6 situation things are perhaps slightly better because the odds that appliance vendors will tell peope to type in an IPv6 address, vs using mDNS/Bonjour seem lower. Maybe, in some of those situations, we can have a name like "dell-r420-ABCD1234.local"=20 used, and then maybe Dell can convince someone to give them a certificate with this name in it... but... ideally, Dell would have their own intermediate CA, and would ship their iDRAC with a built-in certificate. rlb> So the real question is whether it's possible to make a PKI that c= an rlb> authenticate those identifiers. We would of course need some new rlb> types for subjectAltName, but that's just more OIDs. The more rlb> interesting question is how the PKI would be structured -- who are rlb> the trusted authorities for asset tags? I think that CAs would have to have a new category for intermediate CAs with subjectAltName constraints that mean they can only sign asset tags/ DeviceIDs. Also see draft-richardson-6tisch-idevid-cert-00, which 6tisch considers using as part of the ANIMA work. I had no thoughts about ILOM and appliance use of this system until you mentioned that browsers could put something different than an HTTP URL in t= he Location bar. Where could this work get done? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVG4yBYCLcPvd0N1lAQK2Ngf/ZC7clVBHA6cFgAvrsfSFpUPCB/ekDG7h USJcPWraLc0C9bn9sImhOpvYQTiDmpc/3Q9sgezufh7t0EvSxYVsD6p1kcKoASic WkvB4XyMIx+Nd38q3R7LedSQFp38XRJIFip62j4ZsoZU7p3G3QrBLrI7+Imuqlh/ WQW5R/WQgmfPwncuLopbt8dopGCf3Qu7Chi4n0NIH/aE9sXWM3u+aJD93y9aAdE8 FjsLRveY7SF/PNKSu0IdSJwZOD9wZRTvTa35VkOouRqduaQK2IojCwdhBWJ7LCQ6 T9oK5y+BLR2Em2OxCo8oAqxSkDJtVbQM1EO+OijIT6dCmfXkrMCy/A== =sMG/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 20 12:13:06 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3481AC444 for ; Thu, 20 Nov 2014 12:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.495 X-Spam-Level: X-Spam-Status: No, score=-4.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.594, 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 FXhSJgatPQvF for ; Thu, 20 Nov 2014 12:12:50 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9FC1AC425 for ; Thu, 20 Nov 2014 12:12:14 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 70CAE2002A; Thu, 20 Nov 2014 15:14:49 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id CDFF1637F5; Thu, 20 Nov 2014 15:12:13 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B112C63745; Thu, 20 Nov 2014 15:12:13 -0500 (EST) From: Michael Richardson To: Trevor Freeman In-Reply-To: <005401d004ec$08882f00$19988d00$@icloud.com> References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/fyG1fmEI-EOIpKzzMMfyq0aUkoc Cc: 'Richard Barnes' , 'perpass' Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 20:12:59 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Trevor Freeman wrote: > The certificate warning paradigm is over blown given that the typical > alternative is no TLS. An unauthenticated TLS connection is practical= ly > speaking, no different to no TLS at all. The same of true when you see > certificate warring messages S/MIME messages when the rest of the > inbox is unsigned email. As long as the two cases are treated equal w= hy > cannot you dispense with the certificate warning messages?=20 unauthenticated TLS is resistant to passive (bend the fiber, watch the leak, starbucks coffee shop wifi) monitoring while no TLS is not. unauthenticated TLS is not resistant to active (hijack the BGP session, bre= ak the fiber, etc.) attacks. {authenticated TLS is not resistant to national security letters} If we had unauthenticated TLS plus TOFU, many home appliances would be more secure; and we would avoid training end users to click through warning screens. In the scenario of home appliances and management access to ILOMs, people a= re usually confident that BGP attacks are not occuring; the machine is just a few layer-2 hops away. And once you connect to the home appliance, one could then instruct the device to do "letsencrypt" if you can give it a stable name reachable from the letsencrypt people. IPv6 could provide the connectivity. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVG5LGoCLcPvd0N1lAQLl+Af/WLpyw7qy2BeVGkmQWmJ/6qPGTm40Oi/f GpWZvhOcb3IKFDM1ldUo+5VDyXLMlJiHpNxvRAHSLFhKM16D0MmcP7vacv5BJgWj SJc9Nld76j+UosGQ+8hAce/4K4aud4Pi4X7enRpSs763z3d8ER3LHrrtYNsd+0G+ Ft9z7b1xOj/Q0q2Z8KRFA6pzc2YcN3COgA/80oZux7uVceaztLVVGrs2E1eRUyhj xZ07HgVdNsmfo1LiXuCGD0VxjapHJ4m/w42dsjcOU4M5CRCZLduL5inhWukYVkfy 3aLPG9fWw49ODdtRYncyMGClP0ZrXMH5suFRE3LayLx+XUqEBGDvoA== =CPRR -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 20 16:46:48 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2881E1ACF96 for ; Thu, 20 Nov 2014 16:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 O9m1N2XBSZWF for ; Thu, 20 Nov 2014 16:46:43 -0800 (PST) Received: from mr11p24im-asmtp002.me.com (mr11p24im-asmtp002.me.com [17.110.78.42]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6921A1ACE for ; Thu, 20 Nov 2014 16:46:43 -0800 (PST) Received: from Den (c-67-183-152-156.hsd1.wa.comcast.net [67.183.152.156]) by mr11p24im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.33.0 64bit (built Aug 27 2014)) with ESMTPSA id <0NFD00AGI65SXT10@mr11p24im-asmtp002.me.com> for perpass@ietf.org; Fri, 21 Nov 2014 00:46:42 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68,1.0.28,0.0.0000 definitions=2014-11-21_01:2014-11-20,2014-11-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411210003 From: Trevor Freeman To: 'Michael Richardson' References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> In-reply-to: <32035.1416514333@sandelman.ca> Date: Thu, 20 Nov 2014 16:46:34 -0800 Message-id: <006401d00524$9a6842b0$cf38c810$@icloud.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQEBXdEcujp4vtkEDWHjdeYYdwnbIAH58s0yAcRCl2EBwccg+gM3Jsm1AJnqEmUDNiqC7p2jT/Dg Content-language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/3pLWttfOEKBYRvKT6TZLR0lYaO8 Cc: 'Richard Barnes' , 'perpass' Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 00:46:45 -0000 Technically you are correct however give the vast majority of users do not understand the basics of encryption and singing, let alone these nuances, you cannot express them as differences in the connection state to the user. Hence you should treat them as equal in the UI. -----Original Message----- From: perpass [mailto:perpass-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Thursday, November 20, 2014 12:12 PM To: Trevor Freeman Cc: 'Richard Barnes'; 'perpass' Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... Trevor Freeman wrote: > The certificate warning paradigm is over blown given that the typical > alternative is no TLS. An unauthenticated TLS connection is practically > speaking, no different to no TLS at all. The same of true when you see > certificate warring messages S/MIME messages when the rest of the > inbox is unsigned email. As long as the two cases are treated equal why > cannot you dispense with the certificate warning messages? unauthenticated TLS is resistant to passive (bend the fiber, watch the leak, starbucks coffee shop wifi) monitoring while no TLS is not. unauthenticated TLS is not resistant to active (hijack the BGP session, break the fiber, etc.) attacks. {authenticated TLS is not resistant to national security letters} If we had unauthenticated TLS plus TOFU, many home appliances would be more secure; and we would avoid training end users to click through warning screens. In the scenario of home appliances and management access to ILOMs, people are usually confident that BGP attacks are not occuring; the machine is just a few layer-2 hops away. And once you connect to the home appliance, one could then instruct the device to do "letsencrypt" if you can give it a stable name reachable from the letsencrypt people. IPv6 could provide the connectivity. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- From nobody Thu Nov 20 21:23:38 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0441C1AD0BD for ; Thu, 20 Nov 2014 21:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 U2mKTo-J0l7I for ; Thu, 20 Nov 2014 21:23:35 -0800 (PST) Received: from xsmtp03.mail2web.com (xsmtp23.mail2web.com [168.144.250.186]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C231A0052 for ; Thu, 20 Nov 2014 21:23:35 -0800 (PST) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Xrggt-0004tI-Cb for perpass@ietf.org; Fri, 21 Nov 2014 00:23:34 -0500 Received: (qmail 1438 invoked from network); 21 Nov 2014 05:23:30 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Nov 2014 05:23:29 -0000 From: "Christian Huitema" To: "'Trevor Freeman'" , "'Michael Richardson'" References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> In-Reply-To: <006401d00524$9a6842b0$cf38c810$@icloud.com> Date: Thu, 20 Nov 2014 21:23:33 -0800 Message-ID: <035f01d0054b$4c6f19e0$e54d4da0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQEBXdEcujp4vtkEDWHjdeYYdwnbIAH58s0yAcRCl2EBwccg+gM3Jsm1AJnqEmUDNiqC7gLgaB7nnYycGoA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/0I9J4_q1p6DGwLF3m50OBbOq2sU Cc: 'Richard Barnes' , 'perpass' Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 05:23:37 -0000 Trevor Freeman wrote: > The certificate warning paradigm is over blown given that the typical > alternative is no TLS. An unauthenticated TLS connection is practically > speaking, no different to no TLS at all. The same of true when you see > certificate warring messages S/MIME messages when the rest of the > inbox is unsigned email. As long as the two cases are treated equal why > cannot you dispense with the certificate warning messages? The reasoning behind the warning is about expectation. If the browser sees a self-signed cert instead, it does not know whether that was the original intent of the site, or whether someone just staged an attack and provided a self-signed cert instead of the real one. Since there is an expectation that a site that publishes an HTTPS URL will also provide a CA signed certificate, the browser errs on the side of detecting an attack. This would change if there was an easy way to detect that the site intended to use self-sign cert. But there is no such easy way today. -- Christian Huitema From nobody Thu Nov 20 22:00:43 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7661AD0C2 for ; Thu, 20 Nov 2014 22:00:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 k2TqwSHa04Gf for ; Thu, 20 Nov 2014 22:00:38 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C331AD0C4 for ; Thu, 20 Nov 2014 22:00:38 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2E52720098; Fri, 21 Nov 2014 01:03:14 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1B02F637F5; Fri, 21 Nov 2014 01:00:36 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F3ACB637EA; Fri, 21 Nov 2014 01:00:36 -0500 (EST) From: Michael Richardson To: Trevor Freeman In-Reply-To: <006401d00524$9a6842b0$cf38c810$@icloud.com> References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/lw-PLP6CvBDN1sGhTFKYcSQMGm0 Cc: 'Richard Barnes' , 'perpass' Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 06:00:41 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Trevor Freeman wrote: > Technically you are correct however give the vast majority of users d= o not > understand the basics of encryption and singing, let alone these nua= nces, > you cannot express them as differences in the connection state to the= user. > Hence you should treat them as equal in the UI. Nobody said that unauthenticated TLS should show a "lock" =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVG7VAYCLcPvd0N1lAQKoLAf/fNc3gudP7NNpddb4sgZMfSCntBk3e/h+ w+sN2I9AK1ODePOJ00T+0nGqy+mOuZo7yQPolSeUTTRa90mpINFp0V5ufPb4Wn0h +oCvNaqbs5dTDtDR4ItO2u6YcPRD5uVXuH0h+FkhAKbdpWC/Vt+v8ZFQDWD1l1gl jUYwvOfUIvXrnh4gnkLpi5aO2+23AoQ0BBH8Q3V95d59KzKyKbs0ijpMInVHfLOl fnNd/JeiCwi+wm5V44v/iFdjUeP2dkJQ/m8YXCA1rlwY3gryrUtmJod6f7i3D2yP KT10mGp7snnuXH1RhUGzlVaYrHof1acq9KFydJjpfmApNOxeJkzKXw== =nID0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 21 06:06:03 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED551AD41F for ; Fri, 21 Nov 2014 06:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 nnn568s3yyIn for ; Fri, 21 Nov 2014 06:05:59 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5DF1AD386 for ; Fri, 21 Nov 2014 06:05:59 -0800 (PST) Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id 7CD1223805D7; Fri, 21 Nov 2014 09:05:57 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <2518.1416549636@sandelman.ca> Date: Fri, 21 Nov 2014 09:05:39 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> <2518.1416549636@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/ODRLH5Eb22P_o2wegbMh7rDLLoA Cc: Richard Barnes , perpass , Trevor Freeman Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 14:06:02 -0000 On Nov 21, 2014, at 1:00 AM, Michael Richardson = wrote: > Nobody said that unauthenticated TLS should show a "lock" Unfortunately I think more people notice "https://" than the lock. = Although perhaps I think that because I am a geek who knows what = https:// means, and regular folk actually do look at the lock icon. In = any case, I think that a cert signed by this free CA does the job, = because it is not a self-signed cert: there would presumably be an = independent verification step, even if that step is only to show that = the person getting the cert actually has control over the domain. Of course, if that is the test that is used, this sort of cert is no = better than a DANE cert. I guess the one advantage is that it doesn't = require DNSSEC. From nobody Fri Nov 21 06:11:50 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F811AD432 for ; Fri, 21 Nov 2014 06:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] 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 wGG89bGCs4ez for ; Fri, 21 Nov 2014 06:11:37 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C82AD1A017C for ; Fri, 21 Nov 2014 06:11:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8AA17BED6; Fri, 21 Nov 2014 14:11:36 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdAPCF0e6DD2; Fri, 21 Nov 2014 14:11:36 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 65A86BECA; Fri, 21 Nov 2014 14:11:36 +0000 (GMT) Message-ID: <546F481A.7010909@cs.tcd.ie> Date: Fri, 21 Nov 2014 14:11:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Ted Lemon , Michael Richardson References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> <2518.1416549636@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/Bih7Tyl4W5hWLhO08DanHfO2FvE Cc: Richard Barnes , perpass , Trevor Freeman Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 14:11:47 -0000 On 21/11/14 14:05, Ted Lemon wrote: > On Nov 21, 2014, at 1:00 AM, Michael Richardson wrote: >> Nobody said that unauthenticated TLS should show a "lock" > > Unfortunately I think more people notice "https://" than the lock. The relevant proposal here is the httpbis WG draft. [1] I'm not sure when a -01 will pop out, but there have been some comments on this (incl. from me:-) on the WG list, so best to check there in case you're repeating stuff that's already planned to change. That is based on use of HTTP URIs and also not indicating that TLS is in use via any lock icons or similar. Seems like a fine idea to me fwiw, though somewhat controversial amongst some browser folks still. S. [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption From nobody Fri Nov 21 06:18:15 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A14A1AD47A for ; Fri, 21 Nov 2014 06:18:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, 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 o4YnV6IOgy3O for ; Fri, 21 Nov 2014 06:18:12 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 002DC1AD437 for ; Fri, 21 Nov 2014 06:18:11 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id EA79D2C40B0; Fri, 21 Nov 2014 06:18:11 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gjmkRSC6gacw; Fri, 21 Nov 2014 06:18:11 -0800 (PST) Received: from [10.0.1.17] (c-76-103-162-14.hsd1.ca.comcast.net [76.103.162.14]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 56CB12C40A8; Fri, 21 Nov 2014 06:18:11 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E695EB18-5018-4217-8E77-607C94BBF9A9"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b2 From: Nicholas Weaver In-Reply-To: Date: Fri, 21 Nov 2014 06:18:10 -0800 Message-Id: References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> <2518.1416549636@sandelman.ca> To: Ted Lemon X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/n9FsbtypwHOdgvHZgxtk84DIwbo Cc: Richard Barnes , Michael Richardson , perpass , Nicholas Weaver , Trevor Freeman Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 14:18:14 -0000 --Apple-Mail=_E695EB18-5018-4217-8E77-607C94BBF9A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 21, 2014, at 6:05 AM, Ted Lemon wrote: >=20 > On Nov 21, 2014, at 1:00 AM, Michael Richardson = wrote: >> Nobody said that unauthenticated TLS should show a "lock" >=20 > Unfortunately I think more people notice "https://" than the lock. = Although perhaps I think that because I am a geek who knows what = https:// means, and regular folk actually do look at the lock icon. In = any case, I think that a cert signed by this free CA does the job, = because it is not a self-signed cert: there would presumably be an = independent verification step, even if that step is only to show that = the person getting the cert actually has control over the domain. Thats actually the genius portion of the scheme: its a DV cert because = the default flow has the certificate management program receives a = request from the CA to put a token on the web site in question which the = CA can then verify, so it allows fully automated proof of control for = the site. If anything, its arguably better than many CAs Domain Verification = process. > Of course, if that is the test that is used, this sort of cert is no = better than a DANE cert. I guess the one advantage is that it doesn't = require DNSSEC. Given that, because this will be cross signed (agreements are already in = place) as well as an accepted root, this will be accepted by effectively = all browsers, while ~1% of systems measured can not get DNSSEC = information period. Overall, this is a really clever scheme, with really smart people behind = it. I expect a smashing success, and the only thing IMO they should do in = addition is try for low friction payment as well, so that those who = WOULD want to pay (couched in terms of "2 lattes" or something like = that) can easily put in their credit card #. -- Nicholas Weaver it is a tale, told by an idiot, nweaver@icsi.berkeley.edu full of sound and fury, 510-666-2903 .signifying nothing PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc --Apple-Mail=_E695EB18-5018-4217-8E77-607C94BBF9A9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUb0miAAoJEG2B1w+SDi/u66MQAJ3UBdVCY7KOZlRFcreH9xHc Dzdm5jiWzxcym67kfF5OeqlOC9MwqXb+ST3fvl2bupy6k7UW65spCbJKyhBrrP9s 6rvdH72vCAJsJ0HZX6bbwJmUx0IFdpTKuknse2ZSeVUzO5+bUtDlGCBzUzyoro6J H39+SojCvvxq6YhP2lmsdQytv/guTwfn3bRa97CGs2DyDg/mbAj5cJoN6b5f5bze ZNIjhBROXThpo50/rCXS2NGMkakd1P64r9GUJ9N5oNEvgijl4l5mtichu24DCi7W 8mFXjr3soPpqyFdftsYz5eLnsGw3Bj3lut/wmV2rVSBaNr7NclxHFy+Datq9GADE zy6g5qdpSn8J7LPzDSYlTG15Qzy4QATidUWZNHILBNhO0UM73MylAuKOOxuTstNl EehpwxOnQ2FvxhEL3uHJEJv/P3v2Ky0CuVMxgn6V5Zjksi1XL6N4ie7qpNcbRX/6 TqNBUJP+UabW72Kxif/vG1ZQNDZwHcS7wmwEclg+G9YnU+bm6Xu9atxSbEV99tNV 3cJw4lUv7oUKBW/ScN+J3cEaTrVZI17LpyvPfSNBvhoOOyUZ4j5kGvjHP/p6rU8h kVqXZU8RCIO7OK6fhpO+MyNG8P64Jkw1Y/rFkbVTMlwcSvseUj43Q5uU6BTGzRSS Mu4DhREpLSubv4ArzYgN =ee5+ -----END PGP SIGNATURE----- --Apple-Mail=_E695EB18-5018-4217-8E77-607C94BBF9A9-- From nobody Fri Nov 21 06:25:18 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CF31AD492 for ; Fri, 21 Nov 2014 06:25:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.594] 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 FqfvQkk4UDS7 for ; Fri, 21 Nov 2014 06:25:14 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E0721AD491 for ; Fri, 21 Nov 2014 06:24:59 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id C853C2803DE; Fri, 21 Nov 2014 15:24:57 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id C1D062803A8; Fri, 21 Nov 2014 15:24:57 +0100 (CET) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id BEE434C007C; Fri, 21 Nov 2014 15:24:27 +0100 (CET) Date: Fri, 21 Nov 2014 15:24:27 +0100 From: Stephane Bortzmeyer To: Christian Huitema Message-ID: <20141121142427.GA9393@nic.fr> References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> <035f01d0054b$4c6f19e0$e54d4da0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <035f01d0054b$4c6f19e0$e54d4da0$@huitema.net> X-Operating-System: Debian GNU/Linux jessie/sid X-Kernel: Linux 3.16-2-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/BMpVa-hRP-qvLEvcEtXKwmyduB0 Cc: 'Richard Barnes' , 'Michael Richardson' , 'perpass' , 'Trevor Freeman' Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 14:25:16 -0000 On Thu, Nov 20, 2014 at 09:23:33PM -0800, Christian Huitema wrote a message of 29 lines which said: > This would change if there was an easy way to detect that the site > intended to use self-sign cert. That's precisely what RFC 6698 does... Deploying this standard-track RFC would help a lot more than creating a new CA (we already have a gratis and automatic CA, CAcert). From nobody Fri Nov 21 06:26:23 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4911AD44C for ; Fri, 21 Nov 2014 06:26:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, 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 RTHxc8V8uIID for ; Fri, 21 Nov 2014 06:26:20 -0800 (PST) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484591A0AF7 for ; Fri, 21 Nov 2014 06:26:20 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id x3so3749431qcv.22 for ; Fri, 21 Nov 2014 06:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=65dxaG5OtURp1tdwDhiGvmuLoC0hIwOvDd52gXJLFeg=; b=mzV+MYdYsEYQ/V7WQpH9zhldy27d2ly+kT2MTzLwH6ihH2cvf9hkENVheiMj0iBF7Z 4S6q45UYlR+mdC27fOJQZcVZvaVBboC2ARZBYC6DTFEImKwF1fY+4LdhLZ2DBawHBcJn yQmxnv4HC3SsRi3lfp3uALDyd/xnjlEmEJMg+F0iXzjuRLX9O9mpZ7aQEKw4aQ5MYuz1 oT9Mx2fYMnf9C8mAgHh81Rsh3ADDD5adpoUazgfVAlUGl+jTcB8Dh96brd3x0jPoy8hA rRI6lzhLf6TsYWp56IpWaJbvWXQQbIJB9kN9p5zn6OQR6tF/UmIpwmyUx/N9ireERFol pGVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:cc:content-type; bh=65dxaG5OtURp1tdwDhiGvmuLoC0hIwOvDd52gXJLFeg=; b=ZIjcwQFpnNU7OUpv2XHN25YEH3LNZ8rAoAehj01xLwGL0jcB07Dc3hmEI0M41Mebep 323b8Ty8o2Uq7c5R/XbNiQxBeMlyeAigAMwPaL9EmGSFi1BWpvwoiZYslK+r1Xlmxf+d irObKMsnggKzFOM5FD07LHjF1vVsfMQ+8RO0MlETVkLgRt2lIZpdt4mQQ7U0z37/xH/w oZ54LRUa+GRhj6WzD3gWgclhHpzEqQCJvVU+rkUkgLmDTOFMRXVBo/qArS4cGFa9ClZ6 j+7pi+Lom1RASPcVmYzbm9ht8s5B+XEIpOWy6bD8MRfpAQ256Y7184QjzsX0i8Ob6W7A pzwg== X-Gm-Message-State: ALoCoQmCd34nVdrG8mwWZ0eJ999Co91jrdgXBVOoW9OiqFtZ/hjZC8BCJ8pK/0izYRYY39n3aAne X-Received: by 10.224.136.194 with SMTP id s2mr7065623qat.82.1416579979282; Fri, 21 Nov 2014 06:26:19 -0800 (PST) MIME-Version: 1.0 References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> <2518.1416549636@sandelman.ca> From: Ben Laurie Date: Fri, 21 Nov 2014 14:26:15 +0000 Message-ID: To: Nicholas Weaver , Ted Lemon Content-Type: multipart/alternative; boundary=001a11c2d8e27639ad05085f3aa8 Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/tHmpvryshZl-O35KAYrgtmf6_sA Cc: Richard Barnes , Michael Richardson , perpass , Trevor Freeman Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 14:26:22 -0000 --001a11c2d8e27639ad05085f3aa8 Content-Type: text/plain; charset=UTF-8 On Fri Nov 21 2014 at 2:18:19 PM Nicholas Weaver wrote: > > > On Nov 21, 2014, at 6:05 AM, Ted Lemon wrote: > > Of course, if that is the test that is used, this sort of cert is no > better than a DANE cert. I guess the one advantage is that it doesn't > require DNSSEC. > > Given that, because this will be cross signed (agreements are already in > place) as well as an accepted root, this will be accepted by effectively > all browsers, while ~1% of systems measured can not get DNSSEC information > period. > Our somewhat-out-of-date tests indicated ~4%. --001a11c2d8e27639ad05085f3aa8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri Nov 21 2014 at 2:18:19 PM Nichola= s Weaver <nweaver@icsi.berk= eley.edu> wrote:

> On Nov 21, 2014, at 6:05 AM, Ted Lemon <mellon@fugue.com> wrote:
> Of cours= e, if that is the test that is used, this sort of cert is no better than a = DANE cert.=C2=A0 =C2=A0I guess the one advantage is that it doesn't req= uire DNSSEC.

Given that, because this will be cross signed (agreements are already in pl= ace) as well as an accepted root, this will be accepted by effectively all = browsers, while ~1% of systems measured can not get DNSSEC information peri= od.

Our somewhat-out-of-date tests indi= cated ~4%.

--001a11c2d8e27639ad05085f3aa8-- From nobody Fri Nov 21 07:26:01 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E301A1A32 for ; Fri, 21 Nov 2014 07:26:00 -0800 (PST) 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 YbvVSWNN7yEs for ; Fri, 21 Nov 2014 07:25:58 -0800 (PST) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0581A1A31 for ; Fri, 21 Nov 2014 07:25:57 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id i17so3947987qcy.35 for ; Fri, 21 Nov 2014 07:25:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ij8I2SdO8IuLBI7WupR+Mb4vqpsAbJGkS/z46R1xWxM=; b=HSt4P9WWxgtbergj4XJ2PGWIJy8A2Q3PI5gZyMouvK3GRLpRFjkO5tZ+SjX8qUIAQ6 wTE4KT5ZEMx+4+V1o29v/qUKAdrOBWJOkK1/mbcRci6kdGuPsJwQ6Tb7foaL9bheqnIG X69A5XKI+y4U5Qt//zU3AtB9BfaLEbTal4Jfs7yix3doNZ5IJ62MpRciMRI23+LVULnv NzS+AY5uW/1b9ADkvcoGXdVSCK1zWEVdx/NKvFjrqqp27KAGzqxC68J5ASzoeqb1ootO USzoKaBfwEUh63nYi0SdOXjaCje0M1stSqo0zIu8XjclWc+iHA61DzMoV5nxmAwtaQQ6 Lg+w== X-Received: by 10.140.28.101 with SMTP id 92mr6990406qgy.53.1416583557056; Fri, 21 Nov 2014 07:25:57 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id v105sm4872321qgv.46.2014.11.21.07.25.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Nov 2014 07:25:55 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <546F481A.7010909@cs.tcd.ie> Date: Fri, 21 Nov 2014 10:25:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <922BA8FF-AEAA-46CA-B825-735DC40DC222@gmail.com> References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> <2518.1416549636@sandelman.ca> <546F481A.7010909@cs.tcd.ie> To: Stephen Farrell Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/RQ8Y_CisZ6DXZOxGWObD0TPh0YU Cc: Richard Barnes , Michael Richardson , perpass , Ted Lemon , Trevor Freeman Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 15:26:00 -0000 Sent from my iPhone > On Nov 21, 2014, at 9:11 AM, Stephen Farrell w= rote: >=20 >=20 >=20 >> On 21/11/14 14:05, Ted Lemon wrote: >>> On Nov 21, 2014, at 1:00 AM, Michael Richardson w= rote: >>> Nobody said that unauthenticated TLS should show a "lock" >>=20 >> Unfortunately I think more people notice "https://" than the lock. =20 >=20 > The relevant proposal here is the httpbis WG draft. [1] I'm not > sure when a -01 will pop out, but there have been some comments > on this (incl. from me:-) on the WG list, so best to check there > in case you're repeating stuff that's already planned to change. >=20 > That is based on use of HTTP URIs and also not indicating that > TLS is in use via any lock icons or similar. That's in line with consensus from the STRINT workshop. Fallback to unauthe= nticated crypto would appear to the user same as an http session. Regards, Kathleen >=20 > Seems like a fine idea to me fwiw, though somewhat controversial > amongst some browser folks still. >=20 > S. >=20 > [1] https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption >=20 > _______________________________________________ > perpass mailing list > perpass@ietf.org > https://www.ietf.org/mailman/listinfo/perpass From nobody Fri Nov 21 07:40:23 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D752B1A1A32 for ; Fri, 21 Nov 2014 07:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=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 6Xgj-EtWcvpP for ; Fri, 21 Nov 2014 07:40:13 -0800 (PST) Received: from linode64.ducksong.com (li629-102.members.linode.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF6C1A1A69 for ; Fri, 21 Nov 2014 07:39:46 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by linode64.ducksong.com (Postfix) with ESMTPSA id 305B03A020 for ; Fri, 21 Nov 2014 10:39:46 -0500 (EST) Received: by mail-la0-f43.google.com with SMTP id q1so4423450lam.2 for ; Fri, 21 Nov 2014 07:39:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.152.29.41 with SMTP id g9mr5628465lah.83.1416584384732; Fri, 21 Nov 2014 07:39:44 -0800 (PST) Received: by 10.112.89.164 with HTTP; Fri, 21 Nov 2014 07:39:44 -0800 (PST) In-Reply-To: <922BA8FF-AEAA-46CA-B825-735DC40DC222@gmail.com> References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> <2518.1416549636@sandelman.ca> <546F481A.7010909@cs.tcd.ie> <922BA8FF-AEAA-46CA-B825-735DC40DC222@gmail.com> Date: Fri, 21 Nov 2014 10:39:44 -0500 Message-ID: From: Patrick McManus To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=089e0158c09a0be34f0508604106 Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/-vKycTgScmB-V8ywkBPLtKDJwJA Cc: Richard Barnes , Michael Richardson , perpass , Ted Lemon , Trevor Freeman , Stephen Farrell Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 15:40:20 -0000 --089e0158c09a0be34f0508604106 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 21, 2014 at 10:25 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > That's in line with consensus from the STRINT workshop. Fallback to > unauthenticated crypto would appear to the user same as an http session. I bet we're on the same page, but I think there is a little potential confusion in that statement that I want to clarify. https:// cannot fallback to unauthenticated crypto and automatically change the scheme to http:// when it does so for at least 2 reasons: 1] https:// demands authenticated crypto and the users of those links expect that property and we want to promote that 2] https://foo/bar and http://foo/bar are simply different origins and independent resources. There is nothing about the web model that says they carry the same content over different transports despite our intuition when looking at them. So we can't go automatically converting from one to the other and have web compatibility unless the server issues a redirect. Instead of being a fallback for https, O-S is an opportunistic upgrade for otherwise plaintext http://.. ciphertext is the new plaintext for http:// and it isn't treated any differently in the UI because of it. https:// urls with self signed certificates will continue to get giant warnings even in the presence of O-E; nothing about https:// handling changes. --089e0158c09a0be34f0508604106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Nov 21, 2014 at 10:25 AM, Kathleen Moriarty <<= a href=3D"mailto:kathleen.moriarty.ietf@gmail.com" target=3D"_blank">kathle= en.moriarty.ietf@gmail.com> wrote:
That's in line with consensus from the STRINT workshop.=C2=A0 Fa= llback to unauthenticated crypto would appear to the user same as an http s= ession.

I bet we'= ;re on the same page, but I think there is a little potential confusion in = that statement that I want to clarify.

https:// cannot fallback to u= nauthenticated crypto and automatically change the scheme to http:// when i= t does so for at least 2 reasons:

1] https:// demands authenticated = crypto and the users of those links expect that property and we want to pro= mote that

2] https://foo/bar and http://foo/bar= are simply different origins and independent resources. There is nothing a= bout the web model that says they carry the same content over different tra= nsports despite our intuition when looking at them. So we can't go auto= matically converting from one to the other and have web compatibility unles= s the server issues a redirect.

Ins= tead of being a fallback for https, O-S is an opportunistic upgrade for oth= erwise plaintext http://.. ciphertext is the new plaintext for http:// and = it isn't treated any differently in the UI because of it. https:// urls= with self signed certificates will continue to get giant warnings even in = the presence of O-E; nothing about https:// handling changes.

=
--089e0158c09a0be34f0508604106-- From nobody Fri Nov 21 08:38:42 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E88D1AD4C8 for ; Fri, 21 Nov 2014 08:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 Rr7PArIk09AX for ; Fri, 21 Nov 2014 08:38:31 -0800 (PST) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0622A1AD531 for ; Fri, 21 Nov 2014 08:38:27 -0800 (PST) X-Footer: Y2R0Lm9yZw== Received: from hypochilid-2.local ([199.119.118.21]) (authenticated user jhall@cdt.org) by mail.maclaboratory.net (using TLSv1 with cipher DHE-RSA-AES256-SHA (256 bits)) for perpass@ietf.org; Fri, 21 Nov 2014 11:38:26 -0500 Message-ID: <546F6A82.5010705@cdt.org> Date: Fri, 21 Nov 2014 11:38:26 -0500 From: Joseph Lorenzo Hall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: perpass@ietf.org References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> <035f01d0054b$4c6f19e0$e54d4da0$@huitema.net> <20141121142427.GA9393@nic.fr> In-Reply-To: <20141121142427.GA9393@nic.fr> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/434NjctCpQdwEp5XABfEono2AqI Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 16:38:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/21/14, 9:24 AM, Stephane Bortzmeyer wrote: > On Thu, Nov 20, 2014 at 09:23:33PM -0800, Christian Huitema > wrote a message of 29 lines which said: > >> This would change if there was an easy way to detect that the >> site intended to use self-sign cert. > > That's precisely what RFC 6698 does... Deploying this > standard-track RFC would help a lot more than creating a new CA (we > already have a gratis and automatic CA, CAcert). Correct me if I'm wrong but there's not much EFF, Mozilla, et al. can do to directly catalyze deployment of DANE. And the Let's Encrypt effort will be both a new CA that I expect to be more widely supported than CAcert [1] but also a highly-usable doman-validation tool similar to sslmate (check that out if you have not). best, Joe [1]: http://wiki.cacert.org/InclusionStatus - -- Joseph Lorenzo Hall Chief Technologist Center for Democracy & Technology 1634 I ST NW STE 1100 Washington DC 20006-4011 (p) 202-407-8825 (f) 202-637-0968 joe@cdt.org PGP: https://josephhall.org/gpg-key fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) iQIcBAEBCAAGBQJUb2qCAAoJEF+GaYdAqahx2EMP/RPuvqJ5DV2nK2qin/p3Chx+ iOk5r0l09NCVWFwl3IKg1mrzNGqsyQ4itv1iRPpxYxs9JEpD2l0HPMcZglkvSG1L Ycr770HEOEQuR5MVC0VfiPgYRsgQmPk0dTzVvUygq6rQPBZcxpZIAaeDJOa6WMdP OMPFECnFE++v0chcjcw5E4G8gAPyT6B/OrKndmb4yNov/cRRMMG7dmlZaRwnIsS5 Vy6S/H9+9EygKUK3uzWsabTMM+SOFDlncFlVtuaQWNwaShwp7t/3zNVg+c/0B6kv CPiUJ+QATFmITg1MZGzdfjWOCOKp88SRdt9D4A2tEWSuQ+g7HNT/kcVyqjTkoX9d /SDoydwLlgbyvJW3+j0MvHQFtJMDXMn1W3gFJCtBGwDG0bykH56SMny36D1ABwmu pV5Khp6ycwrYlhhTye8C4zZ7BsBzrMR5VCHjJi0c00z25/AfKfDskTJzGQVk1Fv3 RQkhDQ/2glSePdP8zONtebsPrYCWv39/Szqd5VYRk7iF1bhfHxJ4UyaKzMboYUAQ qs9dGNW4dq+sptZWZ14weZ3ABGxb36UWqgn8SA5VAlAcCGvIMZOH/0KG5+iUcJI2 dUHmz/VtRq28Eu5h+IHrXx+z2sPcXxL+sS+BBy2hgjFQV8UMv97sxndP6S1H/UM8 y4PujeRKiriN3pRaU6eD =QwCN -----END PGP SIGNATURE----- From nobody Fri Nov 21 08:40:46 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41821AD53E for ; Fri, 21 Nov 2014 08:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RP_MATCHES_RCVD=-0.594] 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 9Ks9lT-NGItG for ; Fri, 21 Nov 2014 08:40:42 -0800 (PST) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84FBC1AD531 for ; Fri, 21 Nov 2014 08:40:42 -0800 (PST) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id F0A922804DA; Fri, 21 Nov 2014 17:40:40 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx4.nic.fr (Postfix) with ESMTP id EC3B02804C6; Fri, 21 Nov 2014 17:40:40 +0100 (CET) Received: from bortzmeyer.nic.fr (unknown [IPv6:2001:67c:1348:7::86:133]) by relay1.nic.fr (Postfix) with ESMTP id DF51B4C007C; Fri, 21 Nov 2014 17:40:10 +0100 (CET) Date: Fri, 21 Nov 2014 17:40:10 +0100 From: Stephane Bortzmeyer To: Joseph Lorenzo Hall Message-ID: <20141121164010.GA30296@nic.fr> References: <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> <035f01d0054b$4c6f19e0$e54d4da0$@huitema.net> <20141121142427.GA9393@nic.fr> <546F6A82.5010705@cdt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <546F6A82.5010705@cdt.org> X-Operating-System: Debian GNU/Linux jessie/sid X-Kernel: Linux 3.16-2-686-pae i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/5_E6wIWs4RlFAzPLTjtMdCFXauk Cc: perpass@ietf.org Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 16:40:45 -0000 On Fri, Nov 21, 2014 at 11:38:26AM -0500, Joseph Lorenzo Hall wrote a message of 62 lines which said: > Correct me if I'm wrong but there's not much EFF, Mozilla, et al. can > do to directly catalyze deployment of DANE. Quite the contrary. Mozilla, for instance, could include DANE support in Firefox. From nobody Fri Nov 21 09:01:42 2014 Return-Path: X-Original-To: perpass@ietfa.amsl.com Delivered-To: perpass@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528661AD4F8 for ; Fri, 21 Nov 2014 09:01:39 -0800 (PST) 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 y0jkouF8LbU4 for ; Fri, 21 Nov 2014 09:01:37 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657AC1A6EEF for ; Fri, 21 Nov 2014 09:01:34 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id b6so4401942lbj.2 for ; Fri, 21 Nov 2014 09:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JdGzqtvR/yvAdO1bT1uno/N+N9OwRmkU2xk4TzX3Lvo=; b=aKDzynpN/jVuXizAevAAf64BQURySnIlm9yZJPY5sIECbl9AI5G7utJV/dPxqM1XpH 3EadmaMzN28OpSLBB3gVq5z6QQBmCNT6xnpndDE0RRSbADirWfBuLVY6p4irDAmvY8zZ 4BCKor5JmWnS8KP3hHAyoHCFLsBi/cREjvgfIBODbcvefdfkd0Q1p6HHqid61j/8hniH Kcpi/3ydXXcJqYMC+NVThBmhqw9ziKyZW8oCmThdM4NWmBragmZ3wFTkm+Xg6FhOZuUO ITz/DFOHjtIVQKrxzrLHRYDxYEdThqQWM9yPXTVYyGUFHcS5c9FJ7+0OkNLxncSB7Eqc XXrA== MIME-Version: 1.0 X-Received: by 10.112.93.231 with SMTP id cx7mr5103738lbb.89.1416589290645; Fri, 21 Nov 2014 09:01:30 -0800 (PST) Received: by 10.112.49.52 with HTTP; Fri, 21 Nov 2014 09:01:30 -0800 (PST) In-Reply-To: References: <546B86F7.1010602@cdt.org> <16017.1416337667@sandelman.ca> <26158.1416440544@sandelman.ca> <005401d004ec$08882f00$19988d00$@icloud.com> <32035.1416514333@sandelman.ca> <006401d00524$9a6842b0$cf38c810$@icloud.com> <2518.1416549636@sandelman.ca> <546F481A.7010909@cs.tcd.ie> <922BA8FF-AEAA-46CA-B825-735DC40DC222@gmail.com> Date: Fri, 21 Nov 2014 12:01:30 -0500 Message-ID: From: Kathleen Moriarty To: Patrick McManus Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/perpass/n1XXJ6cFObK-3HDMKLUFSiysHKQ Cc: Richard Barnes , Michael Richardson , perpass , Ted Lemon , Trevor Freeman , Stephen Farrell Subject: Re: [perpass] EFF, Mozilla et al. announce new free certificate authority... X-BeenThere: perpass@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "The perpass list is for IETF discussion of pervasive monitoring. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 17:01:39 -0000 On Fri, Nov 21, 2014 at 10:39 AM, Patrick McManus wrote: > > On Fri, Nov 21, 2014 at 10:25 AM, Kathleen Moriarty > wrote: >> >> That's in line with consensus from the STRINT workshop. Fallback to >> unauthenticated crypto would appear to the user same as an http session. > > > I bet we're on the same page, but I think there is a little potential > confusion in that statement that I want to clarify. > > https:// cannot fallback to unauthenticated crypto and automatically change > the scheme to http:// when it does so for at least 2 reasons: > > 1] https:// demands authenticated crypto and the users of those links expect > that property and we want to promote that > > 2] https://foo/bar and http://foo/bar are simply different origins and > independent resources. There is nothing about the web model that says they > carry the same content over different transports despite our intuition when > looking at them. So we can't go automatically converting from one to the > other and have web compatibility unless the server issues a redirect. > > Instead of being a fallback for https, O-S is an opportunistic upgrade for > otherwise plaintext http://.. ciphertext is the new plaintext for http:// > and it isn't treated any differently in the UI because of it. https:// urls > with self signed certificates will continue to get giant warnings even in > the presence of O-E; nothing about https:// handling changes. Thanks, Patrick. As long as OS doesn't look the same to the user as an authenticated encrypted session... so not fallback (wrong term), but OS might look the same as HTTP. Sounds good, thanks for your work on this effort! Kathleen > -- Best regards, Kathleen