Re: https at ietf.org

Eric Burger <eburger@standardstrack.com> Mon, 25 November 2013 12:08 UTC

Return-Path: <eburger@standardstrack.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09B381ACCFE for <ietf@ietfa.amsl.com>; Mon, 25 Nov 2013 04:08:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.578
X-Spam-Level: *
X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYRzJJM2-BHO for <ietf@ietfa.amsl.com>; Mon, 25 Nov 2013 04:08:26 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) by ietfa.amsl.com (Postfix) with ESMTP id C6B9A1AD7BE for <ietf@ietf.org>; Mon, 25 Nov 2013 04:08:25 -0800 (PST)
Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:52837 helo=[192.168.15.105]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <eburger@standardstrack.com>) id 1Vkuxe-0008Q0-Cz for ietf@ietf.org; Mon, 25 Nov 2013 04:08:24 -0800
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_A6899135-3C46-494E-9CB7-38D55014FFFE"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Message-Id: <731D4B97-BC19-4AC8-BEF6-DA702073069A@standardstrack.com>
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: https at ietf.org
Date: Mon, 25 Nov 2013 07:08:16 -0500
References: <CAHBU6ivbrk=NXgd4_5Upik+8H0AbHRy3kJnN=8fcK+Bz3pOV9Q@mail.gmail.com> <alpine.LRH.2.01.1311051733570.4200@egate.xpasc.com> <01P0FR4HDQNG00004G@mauve.mrochek.com> <CAHBU6ivZS33r4HHbCC391Ug9fMtZkJ3nojEeeqH5L+0+o3ZqGQ@mail.gmail.com> <01P0FU0CS96Q00004G@mauve.mrochek.com> <26C6A672-A5D2-44C4-B343-9CCE5E388348@standardstrack.com> <CAKHUCzzzT-0p89uT62zrxGqF1XACG+Ok7hNLcuTaDad7R7eCTQ@mail.gmail.com> <527C2233.3030605@cis-india.org> <CAKHUCzzcNros1=O=D1zkEU1n+XdRcdYdgK2Hkik=AvxbuUJX3w@mail.gmail.com>
To: IETF-Discussion Discussion <ietf@ietf.org>
In-Reply-To: <CAKHUCzzcNros1=O=D1zkEU1n+XdRcdYdgK2Hkik=AvxbuUJX3w@mail.gmail.com>
X-Mailer: Apple Mail (2.1822)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2013 12:08:27 -0000

I like where this has ended up. I am pretty convinced that HTTPS is mostly a dead end because of the CA problem. However, getting RFC 2817 really, really out there would be a huge advance. Like a lot of security stuff, people need a compelling reason to deploy *or* they will use it if it is “just there.” Let us make it “just be there."

On Nov 8, 2013, at 2:40 AM, Dave Cridland <dave@cridland.net> wrote:

> On Thu, Nov 7, 2013 at 11:28 PM, Pranesh Prakash <pranesh@cis-india.org> wrote:
> Dave Cridland [2013-11-06 06:39]:
> > Requiring HTTPS, particularly with reasonable cipher suites, might restrict
> > use of from certain jurisdictions.
> 
> Could we have more concrete examples, please?  Would these be because of
> export restrictions?[1]  For instance, are there any jurisdictions from
> where users have to disable the HTTPS by default option in Gmail?
> 
>  [1]: http://www.cryptolaw.org/
> 
> Examining this website for marginally less than a minute tells me that encryption is generally banned in Saudi Arabia.
> 
> But that's really besides the point. If we "fixed" RFC 2817 support, we could have opportunistic (better than nothing) crypto on *all* websites, rather than forcing every website to deploy HTTPS-only - pretty good win for privacy / anti-pervasive-surveillance.
> 
> That is, making encryption optional, but available everywhere, is a bigger win than making it mandatory in a few places.
> 
> Dave.