Re: [openpgp] New encryption formats for messaging

ianG <iang@iang.org> Mon, 23 March 2015 18:12 UTC

Return-Path: <iang@iang.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B94F1AD0BE for <openpgp@ietfa.amsl.com>; Mon, 23 Mar 2015 11:12:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 czOaKtpVLjCC for <openpgp@ietfa.amsl.com>; Mon, 23 Mar 2015 11:12:31 -0700 (PDT)
Received: from virulha.pair.com (virulha.pair.com [209.68.5.166]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA0661AD0BD for <openpgp@ietf.org>; Mon, 23 Mar 2015 11:12:29 -0700 (PDT)
Received: from tormenta.local (iang.org [209.197.106.187]) by virulha.pair.com (Postfix) with ESMTPSA id EF01E6D7FA; Mon, 23 Mar 2015 14:12:27 -0400 (EDT)
Message-ID: <5510578A.80304@iang.org>
Date: Mon, 23 Mar 2015 18:12:26 +0000
From: ianG <iang@iang.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: openpgp@ietf.org
References: <CAA7UWsUz65C0GAQo8Yf7ZOeT9BYy+NLV5pbbPg+Ok0-72ca1eA@mail.gmail.com> <1426721882.4249.72.camel@scientia.net>
In-Reply-To: <1426721882.4249.72.camel@scientia.net>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/X62SLXUMjRkJpOcXp_P1Jg5xeWg>
Subject: Re: [openpgp] New encryption formats for messaging
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 18:12:34 -0000

On 18/03/2015 23:38 pm, Christoph Anton Mitterer wrote:
> On Fri, 2015-03-13 at 17:41 -0700, David Leon Gil wrote:
>> A0. Be as secure as possible by default. Do not offer options to
>> fallback to doing unsafe things. "Experienced" users often think they
>> want them; there are usually better solutions for their use-cases.
> Yes and no.
>
> Looking at the context you come from (Yahoo) I must note, that the big
> players seem to have discovered security recently ... o.O


Hmmm... so our technique is to punish people for wanting to improve. 
Grand...

> And part of their marketing strategy seems to be "security must be
> easy" (i.e. a totally unaware person should be able to be "secure").
> This is basically the same what some people around the heise Verlag seem
> to campaign for recently.


New to some, but it has a long history:  Kerckhoffs' 6th principle:

"6. Finally, it is necessary, given the circumstances that command its 
application, that the system be easy to use, requiring neither mental 
strain nor the knowledge of a long series of rules to observe."

Writing about cryptography communications systems in 1883.

http://www.financialcryptography.com/mt/archives/000195.html


> While this sounds like a great goal it's completely unrealistic.
> Someone who doesn't at least know some basic concepts will never be
> secure, because he'll believe any social engineering and the first mail
> telling him to just fetch the "unknown key from website X or keyserver
> Y" will be followed.
> Many of my less crypto-aware friends use nowadays things like
> TextSecure/etc. on their mobiles, believing they're secure.
> Well first it's Android (so failed) and second, none of them knows about
> the basic principle that one *is not* secure if not some form of mutual
> authentication hasn't taken place via some secure path (i.e. not
> first-come-is-trusted like key pinning).


I think this is simply wrong.  This is no principle.  TOFU has proved 
itself.  If you don't want to use it, that's fine, but the notion that 
it's "not secure" is simply rubbish because security is a relative risks 
thing, not an absolute thing, and it is extremely unlikely in almost all 
cases that anyone's going to watch and dive like that.  Security is 
statistical, it is risk.

Empirically, I just today got my first 419 hit on Skype, which was set 
up to let others see my name - their mistake on default install.  After 
about a decade of usage?

Even including the notion that Microsoft now copies it all to the NSA, 
that's still only 4 parties with capability to connect to me:  Me, my 
friends, Microsoft and NSA.


> To be honest, Yahoo, doesn't have the best security record, and in
> general I wouldn't trust any web-based crypto app regardless of who it
> wrote.
>
> That being said, I agree that it shouldn't be easy to make a well
> designed crypto system insecure by settings - but not if this means that
> one takes away valid functionality from the more experienced users.

Why do you prioritise "experienced users" above the lesser experienced? 
  Do they pay more money?  Is this the Church Of BOFHs?  Do they pay 
their dues by helping others?  From your writings it seems unlikely...


> And definitely not for marketing reasons.


No such group exists in most places.  In SSL there is a myth that 
sysadms can understand how to configure the apache config files, so 
consequently choice is good.  None do, to a very high statistical 
confidence - most copy files back and forth, and a few read guides like 
bettercrypto.org.  And I can tell you that the BetterCrypto guys are 
always having arguments about what is right, best, etc.  If the <1% 
can't agree the 99% is screwed.


>> A1. Only specify a single asymmetric encryption scheme and a single
>> asymmetric signature scheme. This is critical: This is the second most
>> dangerous and buggy code in any crypto scheme.
> Why?
>
> a) What's the problem a with symmetric scheme as we have it now?


It's all old stuff.  We've moved on.

> b) Why should there be only one?
> I think its a wrong assumption that code will become more secure by
> supporting less algos/systems.
> If a project cannot develop/maintain more of them securely it's rather a
> sign for lack of funding/manpower.


Ah.  So you see that handling more algorithms is a cost for big 
companies to meet and therefore a barrier to entry which makes for less 
choice and eventual balkanisation.  What about opportunity cost - time 
spent managing and debugging algorithms that are rarely if ever used - 
could be better spent on getting more usability?


> The past has shown that sooner or later every algorithm (except for OTP
> of course ;) ) has its flaws and is needed to be replaced.
> Quite often recently, people waited far too long till that replacement
> started (just look at the issues in SSL/TLS).


Fully agreed.  Now, here?

> Since the experience has shown that standardisation of something new
> takes quite a while (see the discussions about Curve25519 at the CFRG) I
> would feel much better if a cryptosystem has several algorithms
> (ciphers, signature schemes, hash algos, etc.) ready in place.
> Implementations can still strongly suggest only a small subset to be
> actually used - but *if* some problem is found in these, it wouldn't
> take ages to get rid of them (like RC4, basically all the old CBC and
> non-EtM algos in SSH, TLS,... hell we still have systems in the wild
> which use MD5 for security purposes)


That argument didn't work.  Basically when ever a problem was found, it 
couldn't be solved by an algorithm switch, 9 times out of 10.  The one 
time that a problem was found, it was solved by ... a switch *backwards* 
to RC4.  Not exactly a happy result.

Secondly, *there is no plan to switch*.  There is a switch, but no plan, 
no methodology nor siren nor alert.

Algorithm agility is all standards body sophistry, not real life.  It's 
another paper invention thrown over the wall, and when it's actually 
needed, it doesn't deliver.


>> A2. Clearly separate handling of various message and key metadata from
>> the underlying encryption scheme. This is critical: Parsing code is
>> the most dangerous and buggy code in any crypto scheme.
> It's a bit unclear to me, what exactly you mean here.


layering.


>> A3. Do not specify things which are infeasible to thoroughly test.
>> This implies avoiding combinatorial complexity, which the OpenPGPv4
>> spec doesn't.
> As above, I doubt you can really check every combination, and I wouldn't
> want to sacrifice too much, just for being able to do so - especially
> not diversity of algorithms.


When has diversity of algorithms ever bought user advantage?

I can think of (been told) one case:  the "Russians GOST" requirements. 
  Frankly, I'm not that keen to let them do that.  If *every* government 
did it, then we'd be in a pickle, and we'd not be talking to any of them 
at all.  So why do we care about the Russians?

Why are we actually preparing a perfect argument for USA Congress to 
turn around and mandate a USA weak key suite?


>> A4. All messages, including signed but unencrypted messages, should be
>> indistinguishable from random to an adversary who does not know the
>> public key of the signer. (This is, essentially, a Tor-style security
>> requirement.)
> By "messages" you mean "OpenPGP Messages" i.e. also they keys?
>
>
>
>> B1. Only modern hash functions that provide a significant security
>> margin against cryptanalysis. Let's not repeat the MD-5/SHA-1
>> disaster. (We only need two hash functions at most.)
> Disagreeing with the "We only need two hash functions at most.".
>
> Diversity is good (of course we should only include secure algos),
> especially when one expects that each algo sooner or later sees
> weaknesses.


Well, sure, on paper.  But if you had a process to switch then you could 
also ... use that process to switch!  Why not just roll out v+1 ?


>> B2. Only block and stream ciphers that offer a significant margin of
>> safety against cryptanalysis. (Or that, when composed, offer a
>> significant margin of safety against cryptanalysis.)
>>
>> B3.. A single AEAD mode that is maximally misuse-resistant, in the
>> sense of https://eprint.iacr.org/2014/793. (But probably not AEZ, or
>> any other CAESAR competitor for that matter. I would prefer a scheme
>> that uses generic composition of well-studied primitives.)


Here's my take on this.  Pick the most experienced guy in the room, tell 
him to come back next month with a recommendation.  Done.



iang