Re: https at ietf.org

Dave Cridland <dave@cridland.net> Thu, 07 November 2013 17:28 UTC

Return-Path: <dave@cridland.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F3911E8108 for <ietf@ietfa.amsl.com>; Thu, 7 Nov 2013 09:28:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.732
X-Spam-Level:
X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ecrxyrOaCw8 for <ietf@ietfa.amsl.com>; Thu, 7 Nov 2013 09:28:53 -0800 (PST)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C2B5111E80E9 for <ietf@ietf.org>; Thu, 7 Nov 2013 09:28:44 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id er20so707453lab.17 for <ietf@ietf.org>; Thu, 07 Nov 2013 09:28:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PwLl4wK0RixdGHwyrPsIcIV0js2wvPzWO0MtHNhiFWQ=; b=jTguveRtiID0YM4TTSfH9IfbfND5aRGl4lXtNMAqgcoN43ixarjQfmiVTPiP+d0hnJ 2rF8xe3i+axtcrgyHulfhNCJD+vdumeu8+QLmds2ZjIpCPPC3FGoQo4zE3DqpJZaIqME 9uzZ8Or1mxeuUI7lruM7Syvawe/FeCCOeJocw=
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=PwLl4wK0RixdGHwyrPsIcIV0js2wvPzWO0MtHNhiFWQ=; b=BUbcqsfVXCzMqrmkSmkMxPkySIafDOxhKB/UGTr/fm3vZMO8PoWeOgEEPBat9tdWau g9iumqCjJljLBoRAcpSdwEx3VSCAs3vCwDFmF2/ugsDYGncDTrdvYZ7zkXM2fnGOhMhR yMnxnx0e5I2NUNUV69Pt+e9s/dyI4fl7wCb9z8QRc02A0aUmirr72F3Hm1G04WYNLoFz TcgBDozrDEdZWpsttw52NRvL91Tz5OsUJCU4qJFzIcmR7hHBPGjNQuQ3ozc1iK8cpniV sEpf9e9U8QHe8vEG3XL0CJ2eCz0qDCeoRl2Cifyg1ctKbEGF2RMnYRZhiA8W28o1JE8D xZcg==
X-Gm-Message-State: ALoCoQlv3bFQOBHuXOorVZvNM3IBXftLPzj4qWbtXvUFdbLThgfWY0Sa79SDDQf7cYoDnwN7fTLK
MIME-Version: 1.0
X-Received: by 10.112.89.69 with SMTP id bm5mr81897lbb.76.1383845309709; Thu, 07 Nov 2013 09:28:29 -0800 (PST)
Received: by 10.114.183.47 with HTTP; Thu, 7 Nov 2013 09:28:29 -0800 (PST)
In-Reply-To: <20131107171900.B41DE18C0E2@mercury.lcs.mit.edu>
References: <20131107171900.B41DE18C0E2@mercury.lcs.mit.edu>
Date: Thu, 07 Nov 2013 17:28:29 +0000
Message-ID: <CAKHUCzwkuVx1OOJg=cD3BKL+XSA_TgxUXoTd8BxHE5T+9ALMyA@mail.gmail.com>
Subject: Re: https at ietf.org
From: Dave Cridland <dave@cridland.net>
To: Noel Chiappa <jnc@mercury.lcs.mit.edu>
Content-Type: multipart/alternative; boundary="001a11c36d7a1c139004ea99987b"
Cc: "ietf@ietf.org Discussion" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 07 Nov 2013 17:28:54 -0000

On Thu, Nov 7, 2013 at 5:19 PM, Noel Chiappa <jnc@mercury.lcs.mit.edu>wrote:

>     > From: ned+ietf@mauve.mrochek.com
>
>     > In light of the sentiments expressed at the plenary and in perpass in
>     > regards to opportunistic encryptions, perhaps this is the dogfood we
>     > should be eating.
>
> Yes, encrypting publicly available documents will do so much to increase
> our
> privacy.
>
>
That's not what Ned or I was hinting at.

RFC 2817 describes a mechanism for connecting on port 80, and asking the
server nicely to switch to TLS, rather than connecting on port 443 and
switching to TLS from the outset.

It's the equivalent of the majority of protocols, which support a
"STARTTLS" or similar extension, making it trivial to provide and use
optional, opportunistic, encryption.

What this would allow is that browsers could *easily* use TLS to provide
some protection, even when given an "http" scheme URI.

Dave.