Re: [Uta] opportunistic keying / encryption considered of dubious value
Trevor Perrin <trevp@trevp.net> Sat, 22 March 2014 00:23 UTC
Return-Path: <trevp@trevp.net>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2965B1A07A8 for <uta@ietfa.amsl.com>; Fri, 21 Mar 2014 17:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 EAgVXQFcYs0i for <uta@ietfa.amsl.com>; Fri, 21 Mar 2014 17:22:59 -0700 (PDT)
Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) by ietfa.amsl.com (Postfix) with ESMTP id 249FF1A0762 for <uta@ietf.org>; Fri, 21 Mar 2014 17:22:58 -0700 (PDT)
Received: by mail-we0-f171.google.com with SMTP id t61so2003581wes.2 for <uta@ietf.org>; Fri, 21 Mar 2014 17:22:49 -0700 (PDT)
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=hikV380yDD8UGDS3pPXQfkSnsxehdgkkvjlhA7xO95c=; b=iuafCcZmaLIkVi7Pmi+2vJzNgCrJxs7Q4A1bZJan14m+vr1dwRo2WUlVgOox5RGEJ/ R5tv4PIuHZUYnyLzqfOlAZE0/LqzsEsI7jvQBx4islAlrQSlOhLKv8rDFBsOOnY2/G5Y gP98RdeR++Oj+buoB70Ivri3E9z30wnGvpGbCa23anrCG0bVCg9VueLCY9rLDnaFM607 po5LQAPp7GsK6Q7YcPL/4YiH7KamgUYw7BmxrwDtrOlj+aFARHy7jJVtXnyOXSJIaqds TtQQ08Y78MowwifBUwFKmg6b8Lf53e418W6iIXCKMCPVdFslc5ZS07i2hgE9l9REPft4 wDiw==
X-Gm-Message-State: ALoCoQkgTrT7hbzR5PZ63F7hQvcSQ38VAfI2KU3R8RQGmxyAoFWibbacmXInx+4aeYTIOIBPUZjh
MIME-Version: 1.0
X-Received: by 10.180.9.42 with SMTP id w10mr527724wia.20.1395447769215; Fri, 21 Mar 2014 17:22:49 -0700 (PDT)
Received: by 10.216.45.146 with HTTP; Fri, 21 Mar 2014 17:22:49 -0700 (PDT)
X-Originating-IP: [184.23.29.222]
In-Reply-To: <532660F5.908@cs.tcd.ie>
References: <53249D4E.2080104@network-heretics.com> <5324ECFC.2050004@akr.io> <53256D07.7020005@network-heretics.com> <5325AEB2.9070804@mnt.se> <5325B3E7.3060508@network-heretics.com> <5326271D.40107@eff.org> <532660F5.908@cs.tcd.ie>
Date: Fri, 21 Mar 2014 17:22:49 -0700
Message-ID: <CAGZ8ZG0LDrHNo2W-Ho2OssPTYNjoaiRCZ3u4rcvWXhj=vG+3cQ@mail.gmail.com>
From: Trevor Perrin <trevp@trevp.net>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: http://mailarchive.ietf.org/arch/msg/uta/iDTeMWWUUgbD3iIC5OnXQbZ5hWg
Cc: "uta@ietf.org" <uta@ietf.org>
Subject: Re: [Uta] opportunistic keying / encryption considered of dubious value
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Mar 2014 00:23:03 -0000
On Sun, Mar 16, 2014 at 7:41 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > Anonymous reporting in this venue from such sources should > get the respect it deserves: i.e zero. The bogus non-argument > stated has in fact already been better made (it would be hard > to do as poorly TBH) in public by named broswer folk and is > crap both in that guise nbut even moreso as reported anonymously > at second hand. Catching up on this list. The rest of Stephen's response to Yan is below. Yan made a well-reasoned argument deserving of respect. The inclusion of some comments from a browser developer added insight into how this debate is viewed by people who matter. I probably agree with Stephen's argument more than Yan's, but I found the level of vitriol in Stephen's response to be startling, and not the sort of tone our Area Director should be setting. Trevor > There are arguments to be made against OK/OE encryption but you > seem to utterly miss all of those below. > >> however, I fear that >> sanctioning opportunistic encryption (OE) will hinder our long-term goal >> of getting every server to use real TLS with key pinning, certificate >> transparency, etc. > > Nonsense says me with exactly as much evidence as you, i.e. none. > > However, I do additionally have some evidence - we know that > ciphertext != plaintext and we have many reports from credible sources > that plaintext helps pervasive monitoring a lot. And in fact that > is logically as plain as the noses on all our faces. > > That kind of "if we do something, some other bad thing may happen" > argument is utterly bogus IMO. > > If we do nothing, then the current bad things will just keep on > happening, but increasingly on behalf of more and more bad actors > as others jump on NSA and GCHQ's bandwagon. > > If you have evidence of some negative effect, relate it. If you > have logical argument, then relate that. If you have neither then > please do not promote gibberish - silence would be better in that > case. Thus far, you are IMO only promoting gibberish. > > The rest of your mail is simply negative nonsense but I will > respond nonetheless. Readers short of time can stop reading here > though since neither the supposed argument nor the obvious > refutations are at all content-ful. > >> >> In other words, if lazy sysadmins > > "lazy sysadmins" is pure BS rhetoric > >> get the impression that OE is "good >> enough", > > "good enough" for what? please make a non-empty statement that > is amenable to evaluation. > >> they'll have even less motivation than they do now to deploy > > Even less than now, according to what body of evidence? > None? Ah ok. So you're just spreading baseless rumour then? > If so, it really is better to be clear about that. A label > that says "fiction" is the usual way to deal with that. > >> authenticated TLS, which is the minimum level of security that we should > > "the minimum" begs the overall question which you started out > (pretending?) to wonder about. There is no need to accumulate > logical fallacies for fun, honestly. > >> be asking for, given the scale of active MITM attack infrastructure that >> NSA has allegedly been developing (ex: >> https://www.eff.org/deeplinks/2014/03/new-nsa-slides-reveal-tailored-access-run-amok). > > There are many news releases that imply that plaintext is either > the meat for their monitoring or else is required for launching > a man on the side attack. > > There is no evidence so far that I know of that indicates that > MITM attacks against even moderately well implemented crypto can > be done at anything similar in scale. Do correct me in detail > if I am wrong. > > There is an abundance of evidence that endpoint authentication > is a sufficient barrier to make turning on crypto too hard for > enough folks for that to be important. > >> >> As a side note, I think some folks in this discussion may be >> exaggerating the cost of active MITM attacks in a world with OE, >> compared to the cost of passively collecting traffic. > > Feel free to supply us with facts. No? Ah ok. > > Feel free to quote someone who argues for OK/OE who has > misrepresented its benefits. I don't recall such. > >> The cost >> difference may be prohibitive to someone on their laptop sniffing >> traffic at a coffeeshop, but it's unlikely to force ISPs and government >> spy agencies to move to "narrowly targeted" surveillance; they can >> easily MITM every OE connection or force a downgrade. > > Earlier you asserted cost/benefit analysis as an argument, now > you assert that cost is irrelevant and for an as-far-as-we-kmow > much more costly attack than recording plaintext. > > And your base assertion is highly questionable. Plaintext is > free if the attacker can keep up with traffic speeds. If we > can add even crappy crypto (say DES brute-force) overhead to > that then we win. > > Feel free to argue in detail that I am wrong here. > >> >> A security engineer for a large browser vendor who has more perspective >> than I do on this particular issue wishes to anonymously contribute the >> following argument: > > BS. There are no significant browser makers who have not spoken > up on this as part of the HTTP/2.0 discussion that I know of. If > there are internal arguments within such organisations, I hope > they are of far higher quality than this piece of innuendo laden > nonsense. > > S. > >> >> """ >> OO: Opportunistic Obfuscation. I won't honor unauthenticated encraption >> with the name "encryption". >> >> Many site operators are looking for any reason at all to not do any work >> to authenticate or otherwise secure their services. The stronger the "OO >> is OK" view is presented, the more they will tend to believe that when >> HTTP2 rolls out, the less work they will have to do. "OO is Better Than >> Nothing," they'll say. "That should be good enough for our users." It is >> not. OO would slow the adoption of real security. >> >> There is a range of options on the continuum between passive and active >> attack, at varying cost levels. Meditate on the Snowden documents, >> especially the QUANTUM stuff. And in any case, attacks always get better >> (cheaper, more powerful), never worse. Even if OO were sufficient now >> (it's not), it would not suffice next year. >> >> Our reasonable fear is that states have compromised CAs, making >> fully-authenticated, real HTTPS ineffective or less effective. (Hence >> PKP, TACK, and CT.) The idea that OO is enough to stymie the most >> powerful militaries in the world does not pass the giggle test. >> """ >> >> _______________________________________________ >> Uta mailing list >> Uta@ietf.org >> https://www.ietf.org/mailman/listinfo/uta >> >> > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta
- [Uta] opportunistic keying / encryption considere… Keith Moore
- Re: [Uta] opportunistic keying / encryption consi… Watson Ladd
- Re: [Uta] opportunistic keying / encryption consi… Keith Moore
- Re: [Uta] opportunistic keying / encryption consi… Paul Hoffman
- Re: [Uta] opportunistic keying / encryption consi… Keith Moore
- Re: [Uta] opportunistic keying / encryption consi… Michael Richardson
- Re: [Uta] opportunistic keying / encryption consi… Keith Moore
- Re: [Uta] opportunistic keying / encryption consi… Michael Richardson
- Re: [Uta] opportunistic keying / encryption consi… Keith Moore
- Re: [Uta] opportunistic keying / encryption consi… Yan Zhu
- Re: [Uta] opportunistic keying / encryption consi… Stephen Farrell
- Re: [Uta] opportunistic keying / encryption consi… Alyssa Rowan
- Re: [Uta] opportunistic keying / encryption consi… Olle E. Johansson
- Re: [Uta] opportunistic keying / encryption consi… Keith Moore
- Re: [Uta] opportunistic keying / encryption consi… Leif Johansson
- Re: [Uta] opportunistic keying / encryption consi… Alan Johnston
- Re: [Uta] opportunistic keying / encryption consi… Keith Moore
- Re: [Uta] opportunistic keying / encryption consi… Keith Moore
- Re: [Uta] opportunistic keying / encryption consi… Yan Zhu
- Re: [Uta] opportunistic keying / encryption consi… Daniel Kahn Gillmor
- Re: [Uta] opportunistic keying / encryption consi… Keith Moore
- Re: [Uta] opportunistic keying / encryption consi… Stephen Farrell
- Re: [Uta] opportunistic keying / encryption consi… Keith Moore
- Re: [Uta] opportunistic keying / encryption consi… Michael Richardson
- [Uta] getting back to UTA and injecting clue (was… Eliot Lear
- Re: [Uta] opportunistic keying / encryption consi… Salz, Rich
- Re: [Uta] opportunistic keying / encryption consi… Alyssa Rowan
- Re: [Uta] opportunistic keying / encryption consi… Olle E. Johansson
- Re: [Uta] opportunistic keying / encryption consi… Daniel Kahn Gillmor
- Re: [Uta] opportunistic keying / encryption consi… Alyssa Rowan
- Re: [Uta] opportunistic keying / encryption consi… Alyssa Rowan
- Re: [Uta] opportunistic keying / encryption consi… Stephen Farrell
- Re: [Uta] getting back to UTA and injecting clue Stephen Farrell
- Re: [Uta] opportunistic keying / encryption consi… Stephen Farrell
- Re: [Uta] getting back to UTA and injecting clue … Olle E. Johansson
- Re: [Uta] opportunistic keying / encryption consi… Keith Moore
- Re: [Uta] opportunistic keying / encryption consi… Orit Levin (LCA)
- Re: [Uta] opportunistic keying / encryption consi… Rick Andrews
- Re: [Uta] opportunistic keying / encryption consi… Stephen Farrell
- Re: [Uta] opportunistic keying / encryption consi… Trevor Perrin
- Re: [Uta] opportunistic keying / encryption consi… Stephen Farrell
- Re: [Uta] opportunistic keying / encryption consi… Trevor Perrin
- Re: [Uta] opportunistic keying / encryption consi… Watson Ladd
- Re: [Uta] opportunistic keying / encryption consi… Christian Huitema
- Re: [Uta] opportunistic keying / encryption consi… t.p.
- Re: [Uta] opportunistic keying / encryption consi… Adam Langley
- Re: [Uta] opportunistic keying / encryption consi… t.p.
- Re: [Uta] getting back to UTA and injecting clue Peter Saint-Andre
- Re: [Uta] getting back to UTA and injecting clue Peter Saint-Andre
- Re: [Uta] getting back to UTA and injecting clue Alexey Melnikov
- Re: [Uta] getting back to UTA and injecting clue Leif Johansson