Re: [openpgp] ways forward wrt IETF wg - please try answer by Apr 8th

[David Leon Gil <[e-mail]>]

 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 <[e-mail]>
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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp
>