Stephen: Thank you for the terrific summary!
--
As several people have pointed this out: I wanted to apologize for my
absurd pomposity on the list: Saying 'Yahoo requests' is clearly
inappropriate for an IETF discussion. I'm very glad that the IETF places a
high value on technical arguments. So...mea maxima culpa.
(In my partial defense, I was kind of blindsided by the pace of discussion;
I had a mandate to get something out about our deprecation plans prior to
OSS release of our branch of E2E. Which is at github.com/yahoo/end-to-end,
by the way.)
--
So: I work for Yahoo on their side of the End-to-End project, in close
collaboration with Google. Yahoo's goal is to provide E2E email encryption
'for the 90%': typical webmail users, who aren't familiar with crypto.
We're hopeful that -- in the 1 year timeframe -- E2E encryption will be
available for all Yahoo webmail users. (This would be a somewhat larger
deployment than the ~ 1.5m recentish keys in the SKS system.)
I'd really like to limit the scope of the OpenPGP WG to email (possibly,
for the moment, email sans attachments[*]), where there's a clear
interoperability story.
Unfortunately, with, e.g., Google's recent pull-out from XMPP, the
interoperability story for instant messaging is really unclear right now. I
don't want to see the interoperability of end-to-end encrypted email be
negatively affected by that: email remains really, really important.
[*]: Given that both Google and Yahoo are moving to 'out-of-band'
attachments via cloud storage, I may not be able to get much buy-in on
anything other than a spec for distributing symmetric file-encrypting-keys
and download URLs along with email. (I'm thinking, here, of something
resembling Pond's 'detachments'.)
--
Responses to options, in (weak) order of preference:
Preferred: Option 3: Major revision. The goals of OpenPGP are relevant. But
-- after four incremental revisions -- the spec has grown from something
simple to something unmanageably complex. I think that experience from the
TLS WG shows that changes of (at least) the scale of TLS1.3 will be
required.
Risk: This will be a lot of work for Stephen...and the rest of us. And
there are a lot of issues that will be really controversial.
--
Preferred: Option 1: Talk for another six months. Get some more deployment
experience from Yahoo, Google, and similar projects using
1. OpenPGPv4
2. and things designed to be concrete proposals for OpenPGPv5
and then take action.
Risks: Half-a-dozen new message formats in the interim, potential for
participant 'lock-in' to drive later discussion rather than technical
merits.
--
Acceptable, depending on scope: Option 2: Minor revisions to OpenPGPv4 in
the interim, specification of a 'simple' OpenPGPv4 profile, and then
discussion of OpenPGPv5 in six months. My main concern is that this will
require a lot of effort, which may distract from the bigger picture issues.
If this happens, specific things I'd like to see:
1. One of curve448 (per IRTF I-D), E-521, or E/Fq(M607) specified as an
alternative for ECDH, possibly with a better KDF (for the first two,
implemented by Mike Hamburg's 'decaf' library, there's working,
MIT-licensed code)
2. A revision to WK's Ed25519 spec to require that inputs are always from
SHA2-512. (I and our cryptographers are unhappy with anything else.)
3. A backwards-compatible extension to SEIPD packets that is a sound(ish)
AEAD mode for modern implementations. (This appears to be feasible, though
a bit of a hack.)
4. A spec for HTML-mail-friendly signatures that *doesn't* require PGP/MIME
support. (PHB has pointed out that base64 confuses non-crypto-geeks. This
has been Yahoo's experience as well.)
--
Unacceptable: Option 4. This would include IM, as I understand it. Three
issues:
1. Likely requires different approach to crypto than in the email case.
(E.g., Axolotl, MAC-and-continue.)
2. Implementations will have completely different APIs.
3. No real point without interoperability at the messaging layer, which
largely no longer exists...regrettably.[*]
[*] I'm hopeful that some of the WebRTC work may eventually result in a
return to interoperability, but they already have a security model
compatible with 'End-to-End' security.
--
Probably unacceptable: Any of the 't' options. (Except, perhaps, an
informational RFC about the web of trust, provided that it takes into
account the incentives against key rotation it creates.)
Both Google and Yahoo have committed to building out a key transparency
system for our users.
And Yahoo is expending significant resources to ensure that it will be
viable for providers smaller than us to participate in such a system.
This work will likely eventually be in scope for Transparency-WG, but we're
not far enough along to be able to commit to any specific proposal at this
time.
Limited exception: Jelle van den Hooof of MIT has a clever proposal to use
DKIM+a form of KT for bootstrapping trust in the interim. (This could be
adapted to TOFU, as well.) A proposal along those lines might be
interesting as a stopgap.
- David
On Wed, Apr 1, 2015 at 11:58 AM Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
wrote:
Hi all,
So I think the volume and content of discussions over the
last few weeks clearly indicates a desire to do something
about openpgp, but that discussion doesn't seem to be closing
in on exactly what to do, in the IETF context. It'd help me
to try figure that out if folks would respond to this saying
which of the options below you think can make sense. Picking
more than one is fine, but if so, please say which you prefer.
Annotating/explaining your choice(s) is very welcome but
please try resist the temptation to change this into a chat
about a different set of options:-)
It would also really help me (and I suspect others) evaluate
messages if you could say something about how you fit into
the openpgp universe (e.g. "I wrote the foo implementation"
or "I run a thing with N people using pgp" or whatever). An
essay on that is not useful here, but a line or two could
be really good.
Please try respond to this if you can before Wed April 8th
and I'll try summarise whatever we get back to the list after
that, and we may or may not have a plan of action at that
point - we'll see I guess.
And pretty please do change the message subject if you want
to follow up and discuss something from someone else's response.
That'll at least make my life a little easier when it comes
to trying to summarise back to the list but it'll also make it
easier for folks to check if I've mucked up in how I summarise
(and I muck up a lot, sadly:-).
Anyway here's the options:
option 1: do nothing - there's nothing much to do or at least
not in the IETF or not within the IETF for the next >6 months.
option 2: do maintenance work on rfc4880 - produce a 4880bis
with better crypto options at least, and debate any further
detailed changes during chartering - the charter will contain
a list of specific things to do and other things will be out
of scope (for now)
option 3: do a major revision to openpgp - take rfc4880 as a
starting point but question all design decisions in the process
of developing a successor version of openpgp and write a
charter that allows for all such design decisions to be
questioned
option 4: move beyond openpgp (or smime) to develop a new
flavour of end-to-end security for interpersonal messaging,
possibly not that tightly coupled to email, but at least
supporting an email flavour
For options 2-4 one could include more or less work related
to trust models or key hierarchies/key distribution. If you
would like to include that kind of work please pick one of
those below. If pursuing any of these, we'd need a separate
discussion about the scope of that work and whether or not
one specific approach ought be standardised, but please
let's not yet have that discussion until we see that one of
the "t" options below has a good bit of support.
option 2t: option 2 + add some trust model/key management
option 3t: option 3 + add some trust model/key management
option 4t: option 4 + add some trust model/key management
So that's for choices. Remember it's ok to pick more than
one with which you could live, but please be clear about
which you prefer.
I'd also like to talk about how we might process some of
the above if we establish rough consensus for one of 'em.
Option 1 is easy. The list can continue to debate stuff,
but there's no IETF process stuff needed and no new RFCs
on the horizon. I get off the hook:-)
For option 2, or 2t we could start crafting a charter on
the list once we've gotten agreement that that's the goal.
I don't think a face-to-face BoF would be needed before
forming a working group unless the scope of the "t" part of
2t was proving hard to pin down. (We could arrange some
virtual audio meetings if that'd help of course.) That
could mean a working group is formed quite soon, and that
working group might choose to meet face-to-face in Prague
in July, or might prefer to work on the list only, or
with some audio meetings.
For options 3, 3t, 4 or 4t I do think we'd likely need to
have a face-to-face BoF meeting as there'd be a lot to
consider and pin down and higher bandwidth is much better
for that. In that case, the important date is June 5th
which is the next cutoff date for requesting such a meeting
for the Prague IETF to be held July 19-24. [1] (June 5th
might seem like a long way off, but it's not really so if
we needed such a meeting then starting to work towards that
soon would be much better than doing so late.)
Also, some of this can be done sequentially. For example,
as an area director I'm very happy re-chartering existing
working groups to add more tasks where those groups have
demonstrated the ability to be productive. In my experience
that can work better than starting out with the hard/ambitious
stuff as the very first thing to do. That might argue for
starting with option 2 and then, if all goes well, discussing
whether or how to tackle option 3 or 4. (We could even charter
a group to do the maintenance work for option 2 and when that's
done to then discuss how to re-charter for one of the more
complicated choices.) I'd suggest however, we ignore such
sequential processing for now, see what folks prefer as a
goal, and then think about whether there's a way to get to
what people want via sequencing things cleverly. So, just
for now, please don't suggest "2, followed by 3" even if
that's something you like the sound of - I think folks'
initial responses will probably make it obvious if we need
a chat about that.
And lastly, please let's not have an IETF process discussion
or a discussion about why the IETF is great or crap. If we
see that there's IETF stuff folks want to do and if those
folks are willing and able to implement/deploy the results
then that's enough to be going on with.
Thanks,
S.
[1] https://www.ietf.org/meeting/important-dates-2015.html#ietf93
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp