Re: [openpgp] New encryption formats for messaging
Christoph Anton Mitterer <calestyo@scientia.net> Wed, 18 March 2015 23:38 UTC
Return-Path: <calestyo@scientia.net>
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 0786C1A0194 for <openpgp@ietfa.amsl.com>; Wed, 18 Mar 2015 16:38:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7k9kkzB2Z2mt for <openpgp@ietfa.amsl.com>; Wed, 18 Mar 2015 16:38:07 -0700 (PDT)
Received: from mailgw02.dd24.net (mailgw-02.dd24.net [193.46.215.43]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778281A9170 for <openpgp@ietf.org>; Wed, 18 Mar 2015 16:38:07 -0700 (PDT)
Received: from mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.26]) by mailgw02.dd24.net (Postfix) with ESMTP id 576275FC49 for <openpgp@ietf.org>; Wed, 18 Mar 2015 23:38:06 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at mailpolicy-01.live.igb.homer.key-systems.net
Received: from mailgw02.dd24.net ([192.168.1.36]) by mailpolicy-01.live.igb.homer.key-systems.net (mailpolicy-01.live.igb.homer.key-systems.net [192.168.1.25]) (amavisd-new, port 10236) with ESMTP id LLoXu38EHp4n for <openpgp@ietf.org>; Wed, 18 Mar 2015 23:38:04 +0000 (UTC)
Received: from heisenberg.fritz.box (ppp-93-104-121-105.dynamic.mnet-online.de [93.104.121.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailgw02.dd24.net (Postfix) with ESMTPSA for <openpgp@ietf.org>; Wed, 18 Mar 2015 23:38:03 +0000 (UTC)
Message-ID: <1426721882.4249.72.camel@scientia.net>
From: Christoph Anton Mitterer <calestyo@scientia.net>
To: openpgp@ietf.org
Date: Thu, 19 Mar 2015 00:38:02 +0100
In-Reply-To: <CAA7UWsUz65C0GAQo8Yf7ZOeT9BYy+NLV5pbbPg+Ok0-72ca1eA@mail.gmail.com>
References: <CAA7UWsUz65C0GAQo8Yf7ZOeT9BYy+NLV5pbbPg+Ok0-72ca1eA@mail.gmail.com>
Content-Type: multipart/signed; micalg="sha-512"; protocol="application/x-pkcs7-signature"; boundary="=-ySQJaBO+BHHGUQTr7uLY"
X-Mailer: Evolution 3.12.9-1+b1
Mime-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/SCZqFWK8d7ZSzIMuwo5z9KT-w1A>
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: Wed, 18 Mar 2015 23:38:10 -0000
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 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. 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). 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. And definitely not for marketing reasons. > 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? 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. 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). 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) > 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. > 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. > 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. > 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.) > > Thus, what any proposal should specify, at the crypto level: > > C1. A single curve providing security above the 192-bit-equivalent > level. (This is because the *tightest* security reductions for any > concrete instantiation of EC primitives result in a security level of > ~ 120-bits for a 384-bit curve.) Same as above for all the "single foo" demands. > C2. A single message format intended for use with signed and encrypted > messages of length >> 128 bytes and << 2^24 bytes. (That is, something > appropriate for email. I would consider encryption of large files and > very short messages out of scope at this time.) I am agnostic as to > whether encrypted-then-signed or signed-then-encrypted is preferable. > I am curious if anyone else has strong views on this? You're aware that OpenPGP isn't just for mail respectively what Yahoo want's to do with it? > C3. A single message format intended for detached signatures. This > should target, specifically, the common use-case of OpenPGP signatures > for code-signing. No strong opinions here. The only thing important is that we warn implementors about the typical issues (see the InRelease hacks within Debian, or the problems with the --verify option in GnuPG with detached sigs but only one argument) > C4. Specify a mechanism for encapsulating a signature over the body of > an HTML email in a way that is compatible with HTML email as commonly > used. This signature should be indifferentiable from random for anyone > who does not know the public key of the sender. Not the task of OpenPGP - we're not a mail standard only. > (This last should be easy. A concrete proposal: If a > "data-openpgp-sig" attribute is present on a tag, it contains a > base64urlsafe-encoded signature over the contents of that tag, with no > special normalization rules applied. This can be made more precise by > reference to the HTML5 spec.) Isn't that also out of the scope of an OpenPGP standard? > The IETF lately has not seemed to be so much about canonizing "de > facto" standards (which it was good at) as design-by-committee (which > it isn't). And recent revelations have shown that design-by-committee > is -- besides being irritating for implementors -- a boon to > intelligence agencies. Well it doesn't seem to me as if IETF would make bad work here and I'd see no reason to pull the standardisation to some other body. And "not helping the NSA comments" from a US company?! ;-) > So: I would encourage anyone interested in seeing something > standardized to make a complete proposal a la Hugo Krawycz's OP-TLS > proposal for TLS1.3. But implement the proposal first. Working code > &c. off topic: That approach is IMHO much more problematic with respect to potentially evil orgsanisations/people, since those who do the code, spread it in the wild before it was discussed by experts make quite some pressure to have their ideas being used (see e.g. SPDY). > Yahoo will not support a specification that, by sloppiness or > untestability, makes our users unsafe. Apart from the fact that this sentence makes me smile (just searching through the heise archive for security issues at Yahoo ^^): I guess someone else has already mentioned that it's really not appropriate that someone of the "big players" (even though I wouldn't call any of Google/Yahoo/MS big players for people who want *real* security ;) ) try to make any kinds of pressure here. Cheers, Chris.
- Re: [openpgp] New encryption formats for messaging Christoph Anton Mitterer
- Re: [openpgp] New encryption formats for messaging ianG
- Re: [openpgp] New encryption formats for messaging Christoph Anton Mitterer
- Re: [openpgp] New encryption formats for messaging ianG
- Re: [openpgp] New encryption formats for messaging Christoph Anton Mitterer
- [openpgp] Manifesto - who is the new OpenPGP for? ianG
- Re: [openpgp] Manifesto - who is the new OpenPGP … Christoph Anton Mitterer
- Re: [openpgp] Manifesto - who is the new OpenPGP … Phillip Hallam-Baker
- Re: [openpgp] Manifesto - who is the new OpenPGP … Falcon Darkstar Momot
- Re: [openpgp] Manifesto - who is the new OpenPGP … Werner Koch
- Re: [openpgp] Manifesto - who is the new OpenPGP … Stephen Paul Weber
- Re: [openpgp] Manifesto - who is the new OpenPGP … Stephen Paul Weber
- Re: [openpgp] Manifesto - who is the new OpenPGP … Wyllys Ingersoll
- Re: [openpgp] Manifesto - who is the new OpenPGP … Clint Adams
- Re: [openpgp] Manifesto - who is the new OpenPGP … Phillip Hallam-Baker
- Re: [openpgp] Manifesto - who is the new OpenPGP … ianG
- Re: [openpgp] Manifesto - who is the new OpenPGP … ianG
- Re: [openpgp] Manifesto - who is the new OpenPGP … Tim Bray
- Re: [openpgp] Manifesto - who is the new OpenPGP … Phillip Hallam-Baker
- Re: [openpgp] Manifesto - who is the new OpenPGP … Christoph Anton Mitterer
- Re: [openpgp] Manifesto - who is the new OpenPGP … John Kreznar
- Re: [openpgp] Manifesto - who is the new OpenPGP … Werner Koch
- Re: [openpgp] Manifesto - who is the new OpenPGP … Phillip Hallam-Baker
- Re: [openpgp] Manifesto - who is the new OpenPGP … Brian Sniffen
- Re: [openpgp] Manifesto - who is the new OpenPGP … Bill Frantz
- Re: [openpgp] Manifesto - who is the new OpenPGP … Phillip Hallam-Baker
- Re: [openpgp] Manifesto - who is the new OpenPGP … Christoph Anton Mitterer
- Re: [openpgp] Manifesto - who is the new OpenPGP … Christoph Anton Mitterer
- [openpgp] OpenPGP private certification [was: Re:… Daniel Kahn Gillmor
- Re: [openpgp] OpenPGP private certification [was:… Phillip Hallam-Baker
- Re: [openpgp] OpenPGP private certification [was:… Daniel Kahn Gillmor
- Re: [openpgp] OpenPGP private certification [was:… Phillip Hallam-Baker
- [openpgp] public logging of e-mail certificates [… Daniel Kahn Gillmor
- Re: [openpgp] public logging of e-mail certificat… Phillip Hallam-Baker
- Re: [openpgp] public logging of e-mail certificat… Daniel Kahn Gillmor
- Re: [openpgp] public logging of e-mail certificat… Phillip Hallam-Baker
- Re: [openpgp] OpenPGP private certification [was:… Derek Atkins
- Re: [openpgp] public logging of e-mail certificat… Brian Sniffen
- Re: [openpgp] OpenPGP private certification [was:… Phillip Hallam-Baker
- Re: [openpgp] public logging of e-mail certificat… Phillip Hallam-Baker
- Re: [openpgp] Manifesto - who is the new OpenPGP … ianG
- Re: [openpgp] OpenPGP private certification Werner Koch
- Re: [openpgp] OpenPGP private certification Phillip Hallam-Baker
- Re: [openpgp] OpenPGP private certification Christoph Anton Mitterer
- Re: [openpgp] OpenPGP private certification Phillip Hallam-Baker
- Re: [openpgp] OpenPGP private certification Christoph Anton Mitterer
- Re: [openpgp] OpenPGP private certification Werner Koch
- Re: [openpgp] OpenPGP private certification Derek Atkins
- Re: [openpgp] OpenPGP private certification Phillip Hallam-Baker
- Re: [openpgp] OpenPGP private certification Phillip Hallam-Baker
- Re: [openpgp] OpenPGP private certification Christoph Anton Mitterer
- Re: [openpgp] OpenPGP private certification Christoph Anton Mitterer
- Re: [openpgp] OpenPGP private certification Phillip Hallam-Baker
- Re: [openpgp] OpenPGP private certification Christoph Anton Mitterer
- Re: [openpgp] OpenPGP private certification Werner Koch
- Re: [openpgp] OpenPGP private certification ianG
- Re: [openpgp] OpenPGP private certification [was:… ianG
- Re: [openpgp] public logging of e-mail certificat… Phillip Hallam-Baker
- Re: [openpgp] public logging of e-mail certificat… ianG
- [openpgp] New encryption formats for messaging David Leon Gil
- Re: [openpgp] OpenPGP private certification Ben McGinnes