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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp