Re: Mandatory encryption

Phillip Hallam-Baker <hallam@gmail.com> Wed, 18 July 2012 15:07 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8972A21F861A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 18 Jul 2012 08:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.958
X-Spam-Level:
X-Spam-Status: No, score=-8.958 tagged_above=-999 required=5 tests=[AWL=1.641, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NGHE2jOmVb8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 18 Jul 2012 08:07:17 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id BD89121F8610 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 18 Jul 2012 08:07:17 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1SrVqf-0003l6-8T for ietf-http-wg-dist@listhub.w3.org; Wed, 18 Jul 2012 15:07:33 +0000
Resent-Date: Wed, 18 Jul 2012 15:07:33 +0000
Resent-Message-Id: <E1SrVqf-0003l6-8T@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1SrVqV-0003k9-FA for ietf-http-wg@listhub.w3.org; Wed, 18 Jul 2012 15:07:23 +0000
Received: from mail-vc0-f171.google.com ([209.85.220.171]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <hallam@gmail.com>) id 1SrVqR-0006dg-2U for ietf-http-wg@w3.org; Wed, 18 Jul 2012 15:07:23 +0000
Received: by vcdd16 with SMTP id d16so792734vcd.2 for <ietf-http-wg@w3.org>; Wed, 18 Jul 2012 08:06:53 -0700 (PDT)
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:content-transfer-encoding; bh=nOSYVwcDIqSfqPnn4Fx7bn9pT8UTY2YtQ/yiBbaC+KE=; b=Qt+ey89pMF2tHWLN4yETOLFKXAQnXCM3SaWw0wHBdghkcBltlNyT3dfxmYPia1cUym bD1tQVS9emkf3RX3mSzE2e/OJQiM7obmqySSXml3DMjFDPr+jpEb/9nLykB3jBmYdCcJ Cq8jn0iEOHWCY+LzQ5Qxlc2Zv8cIa+du1HxBlg7sMj2mtakie6ZDrsZab4WbPV77TtFO XZXWvqkhf3QF6a9SLaiMFeDrUFK2YhV9rDPYLu0cPp8B2TnP7MsVTiSH9sNFsRBEhoWh jUib1JF7yYG2zeS1tLP0LcZI7VxYQgAntEH+NjrNHFnxJL1cGqFmC41HDm3/dbdGCmPy vdFQ==
MIME-Version: 1.0
Received: by 10.52.23.136 with SMTP id m8mr903979vdf.28.1342624012918; Wed, 18 Jul 2012 08:06:52 -0700 (PDT)
Received: by 10.58.161.139 with HTTP; Wed, 18 Jul 2012 08:06:52 -0700 (PDT)
In-Reply-To: <5006C08A.6000608@cisco.com>
References: <CAPik8yYuB1BZVN0YW3Hx9ubRRzd608jd09vVz+FASP=i5iRoZA@mail.gmail.com> <CAMm+LwizJ0zesHZnZjCp=tEEiGFpG1Mt56SxvvqNj+C_=KkoZQ@mail.gmail.com> <20120718060936.GC5875@1wt.eu> <CABaLYCvZF0zwQZnAkyvggWMoo0U+xOYU4t5uLCU=fYz6Yzx8aw@mail.gmail.com> <5006C08A.6000608@cisco.com>
Date: Wed, 18 Jul 2012 11:06:52 -0400
Message-ID: <CAMm+LwgMYUc6npo_TuUX9W6RV5HOizoeAk-EQTQvu4wTW=cnnA@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Mike Belshe <mike@belshe.com>, Willy Tarreau <w@1wt.eu>, Paul Hoffman <paul.hoffman@gmail.com>, grahame@healthintersections.com.au, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.220.171; envelope-from=hallam@gmail.com; helo=mail-vc0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-2.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1SrVqR-0006dg-2U 3049648825ef7db39fd6c7e6724aa031
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Mandatory encryption
Archived-At: <http://www.w3.org/mid/CAMm+LwgMYUc6npo_TuUX9W6RV5HOizoeAk-EQTQvu4wTW=cnnA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/14493
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

It isn't just the cost that is an issue.

The ongoing maintenance cost is a real hinderance. Much of the cost in
the CA business turns out to be getting the customer to renew at the
one year expiry point. In many cases the Web site was set up by a
consultant who bought the cert and didn't tell the customer that they
needed to renew it.


The real security requirement here is to avoid a downgrade attack.
Mandating use of TLS in HTTP 2.0 does nothing for that unless there is
also a means of avoiding the downgrade attack to HTTP/1.1

We need to make preventing a downgrade attack practical and if we do
that we do not need the mandate.

Here is an example of the type of mechanism that could make use of
security policy practical:

http://tools.ietf.org/html/draft-hallambaker-omnibroker-01


Now Comodo and Kaspersky are already deploying schemes that have some
of this functionality already. I expect Symantec and McAfee will
eventually follow suit with their own plug ins. So the question is not
whether people will do something like this but whether it will be a
standard or not.


On Wed, Jul 18, 2012 at 9:56 AM, Eliot Lear <lear@cisco.com> wrote:
> Mike,
>
>
> On 7/18/12 8:54 AM, Mike Belshe wrote:
>
> Show me the user that will stand up and say, "Yes, I would like my
> communications to be snoopable and changeable by 3rd parties without my
> knowledge."
>
>
> This is a red herring.  The real argument is around the ability of all web
> servers to get certificates that the browser will  / should trust, or using
> a means of trust that doesn't require certificate chains. The server
> administrator must not be put in a position of having to pay an annual fee
> to avoid the client warning, because that introduces at least a potential
> externality in that the server administrator may not value avoiding the
> warning in the way that you would expect.  Certainly the end user doesn't
> act appropriately against the warning, which is why we're having this
> discussion[1,2][*].
>
> Eliot
>
> [1] Herley, C., “So Long, And No Thanks for the Externalities: The Rational
> Rejection of Security Advice by Users”, NSPW’09, September 8–11, 2009.
> [2] Edelman, S., et al, “You've been warned: an empirical study of the
> effectiveness of web browser phishing warnings”, Proceedings of the
> twenty-sixth annual SIGCHI conference on Human factors in computing systems
> , 2008.
> [*] There are probably dozens of citations in this space.



-- 
Website: http://hallambaker.com/