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

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Apr 2015 19:57:49 +0100

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

---

From: Nicholas Cole <[email-masked]>
Date: Wed, 1 Apr 2015 20:26:26 +0100

On Wednesday, 1 April 2015, Stephen Farrell <[email-masked]>
wrote:

> about a different set of options:-
>

[snip]

FWIIW I favour option 2.  That is to say, making the necessary changes to
the cypher list etc and the packet format that allow us to move away from
obsolete and deprecated algorithms -- especially moving to something better
than SHA-1 in those places where that is currently hard-coded.

I do not think that we should be talking about successors to OpenPGP, nor
do I think that we should use this as an opportunity to hard-code
particular security policies or usages, which is where some of this
discussion has sometimes veered.

Werner has the best sense of what needs fixing is within the scope of
option 2 or 3, but my vote is for evolutionary changes not a radical
departure.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Apr 2015 15:51:21 -0400

> essay on that is not useful here, but a line or two could

I have written code that makes S/MIME easy to use by taking concepts
from the PGP world. I am planing to extend the same approach to PGP.

In particular, my scheme is designed to provide frictionless security
so that the user does not need to do anything differently unless we
are making something easier to do.

I am also looking at trust models that combine ideas from S/MIME, PGP
and TRANS. But that is not an immediate focus.

> not in the IETF or not within the IETF for the next >6 months.

I think it is clear that there is important work to be done.

> a list of specific things to do and other things will be out

I would support this. Cleaning up the legacy OpenPGP specs would be a
help even if it didn't go further. It is not my preferred option.

I think it is also important to decide in advance what our end
objective is going to be. We are going to approach this very
differently if we have given up hope of getting a single message
format.

> charter that allows for all such design decisions to be

I support this but the scope has to be manageable and to understand
what is 'manageable' we need more information on the existing
implementations.

In particular, I would like to achieve a clean break between the
message format layer and the trust model layer and tackle those
independently. Quite possibly in separate IETF and IRTF tracks.

If you give me the fingerprint of Alice's key and some way to resolve
that to a public key and her email security preferences, encrypting
the message is straightforward. I would like the IETF to come to a
single answer to that problem, though just as we have JPG and PNG and
GIF in the Web, it need not be a single format.

The question of how Bob finds Alice's fingerprint and what confidence
he can have in the answer is something that I think needs research.
PKIX and PGP are both early essays in the craft. We have 20 years of
operational experience and some important IPR is no longer encumbered.

> supporting an email flavour

I do not support this at this time.

The reason I chose to start with email is that it is the hardest, most
constrained problem. If we can solve that problem we can apply the
same approach to everything else. The only problem that is as hard as
email is code signing and that is hard for the same reason - because
it is an asynchronous problem.

It is an important and inevitable piece of work which is why I care
about getting issues such as efficient JSON encoding right. But I
don't want to open the subject up until we have SPUD, efficient JSON
and the trust model sorted. And this is not a project I would want to
do in the security area, it would need the WebRTC type folk and the
messaging folk.

The only near term consequence of the expectation that we will
eventually do this work for me would be that I am much more open to
re-working existing data structures in JSON than I would be otherwise.
If we do eventually re-do the whole application layer then it should
have a consistent encoding from top to bottom with as few exceptions
as possible.

> option 4t: option 4 + add some trust model/key management

My preferences are

Option 3t [With the T part in IRTF]
Option 3
Option 2

I do not want to do Option 2t or option 4.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 01 Apr 2015 16:27:37 -0400

> a list of specific things to do and other things will be out

I think i favor this approach, ideally *without* adding trust model work
into the mix.

Trying to explicitly declare a standardized trust model would be a
mistake for the WG.  it's a huge rat hole, and a "one trust model fits
all" approach is probably illegitimate at some deeper level, since
different people have different adversaries.

If there's any work to be done with trust models, it would be to write a
document that tries to describe one or more of the more common
approaches to trust models (e.g. the GnuPG default arrangement, or
whatever sort of TOFU mechanism that PHB thinks is what everyone
"actually uses").  I do *not* think that needs to be in the WG charter,
that can be an independent submission any time by anyone with an
interest in clarifying trust models they use.

For option 2, i have the following specific items i'd like to see
addressed (though they may not need to all be in a new charter):

a) update the fingerprint format (avoid inclusion of creation date, use
   stronger digest algorithm; i'm dubious about embedding algorithm
   agility in the fingerprint itself, but explicit version info in the
   fingerprint might be reasonable so we don't have to keep guessing by
   fpr structure for future versions)

b) get rid of keyids entirely -- when referring to a key, use the
   fingerprint where a compact hint is needed (e.g. in a replacement of
   the issuer subpacket) or the full primary key where it is more
   sensitive (e.g. in designated revoker).  With EC keys, we could
   consider using the full key (not the full cert) even in the issuer
   subpacket case, which could make things cleaner.

c) deprecate MD5, SHA1, and RIPEMD160

d) clarify that cleartext signatures should all use charset/encoding
   UTF-8.

e) update S2K with something more modern (PBKDF2, HKDF, scrypt?),
   deprecate all the other mechnanisms explicitly

f) standardize the two new curves coming out of the CFRG: 25519 and
   curve448 ("goldilocks") for both signatures and encryption (Werner
   has already started this process for 25519 signatures)

g) remove compression entirely

h) clean up the language: clearly distinguish between "public key" and
   "certificate", and ensure that the use of the terms "trust" and
   "validity", if still present, are used unambiguously.

i) declare a literal data packet type "m" that means "MIME content" so
   that we can punt on the rest of the message
   structure/format/encoding/type craziness to MIME.

j) deprecate 3DES, IDEA, and as many of the weaker ciphers as we can
   get away with.

k) provide a modern streamable/chunkable AEAD replacement for
   Symmetrically-Encrypted Integrity-Protected Data (SEIPD) packets

l) change MTI algorithms: SHA512, the two new ECs, and the new AEAD
   mechanism should be the baseline.

Could be other incremental changes too, but that's the top of my stack
at the moment.

I know i was the one who brought the MIME message-structuring question
("memoryhole") to this list recently, but i'm now having second thoughts
about whether this is the right place for it -- the above work seems
concrete and reasonably well-scoped, and a lot of the feedback in Dallas
seemed to be that e-mail header protection could be nice to handle more
generally, possibly in collaboration with S/MIME people.  I'm not sure
where the right place to put that would be, but the work seems
orthogonal to the discussions above.

   --dkg

---

From: Wyllys Ingersoll <[email-masked]>
Date: Wed, 01 Apr 2015 20:30:38 +0000

On Wed, Apr 1, 2015 at 2:58 PM Stephen Farrell
> essay on that is not useful here, but a line or two could

$ whoami
I wrote an independent implementation of 4880 for an iOS app ("ipgmail") in
Objective-C.

My preference would be option 2 (4880bis).  I would eventually like to see
a more standardized spec for the PGP trust model, but not as part of the
core spec.

-Wyllys Ingersoll

---

From: James Cloos <[email-masked]>
Date: Wed, 01 Apr 2015 17:53:46 -0400

>>>>> "SF" == Stephen Farrell <[email-masked]> writes:

SF> option 2: do maintenance work on rfc4880 - produce a 4880bis
SF> with better crypto options at least, and debate any further
SF> detailed changes during chartering - the charter will contain
SF> a list of specific things to do and other things will be out
SF> of scope (for now)

That looks best.

And dkg's list is a great summary of what is needed.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: ianG <[email-masked]>
Date: Thu, 02 Apr 2015 18:54:51 +0100

On 1/04/2015 19:57 pm, Stephen Farrell wrote:
> the openpgp universe ...

In the period 1995-2002 approx I managed a team called Cryptix which 
produced Java & Perl implementations of PGP 2 and then OpenPGP.  This 
was originally written to support a payments system that based its 
crypto/security packets on PGP.  (Sometime around 2012 I replaced the 
Cryptix & OpenPGP with a custom cut-down internal design I call SKF for 
SOX Key Format.)

> supporting an email flavour
...
> option 4t: option 4 + add some trust model/key management

Option 4t is what I would favour.

The reason being that I have since replaced all the direct OpenPGP code 
with my own design, because it's more efficient (lean, easier to hack), 
and it meets the needs of the late 2000s identity concept I work to.  I 
wouldn't go backwards but I could possibly go forward to a newer 
design/architecture that incorporated much of the new knowledge.

And, say options 3t or option 4 is also possible to a lesser extent.

iang

---

From: Tom Ritter <[email-masked]>
Date: Thu, 2 Apr 2015 17:13:28 -0500

I'm somewhere in between 2 & 3.  I think dkg's list is quite good.

-tom

---

From: Ben McGinnes <[email-masked]>
Date: Tue, 07 Apr 2015 08:44:13 +1000

> about a different set of options:-)

Sure ... why not break my silence with this.

> essay on that is not useful here, but a line or two could

I'm a long time user of PGP and GPG (about 20 years, I began with PGP
2.3a for DOS), co-founder of CryptoParty in Melbourne, privacy & civil
liberties campaigner, current Treasurer of Pirate Party Australia,
former Vice President of Linux Users of Victoria and professional geek
(former Sun Systems Engineer).  I've been training people with using
GPG specifically for several years across a variety of industries.
I've been lurking on this list for a while, a few years at least.

> not in the IETF or not within the IETF for the next >6 months.

Ah, nope, I believe there are some things to do to some extent.
Particularly in light of the legislation recently passed in my country
(see below).

> a list of specific things to do and other things will be out

I think this is the most viable option at the moment.  We all know,
for example, that there are significant changes coming with ECC
becoming a viable option, so there are some things which could be
tightened at the same time.

I think the top of my list would have to be incorporating more of
what's usually classed as SMTP headers in the encrypted portion of a
(presumably PGP/MIME) message.  Ideally everything after the data
command is delivered to the SMTP server, but that might be pushing it
a bit (though mail from and rcpt to commands should be all said server
needs to do what it has to do).  Obviously the WGs dealing with SMTP
and probably POP3 and IMAP might have a thing or two to say about
that.

> charter that allows for all such design decisions to be

Maybe, there's no harm in questioning things, but the intended outcome
would need to be clear.

> supporting an email flavour

I believe this is called starting a new WG to create and/or implement
some new thing.  While I've got nothing against that, there's a point
where you just have to say, "hey this is a new project, but we've been
inspired by what came before."

> 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.

Maybe.  Trust models always get a bit contentious because people
inevitably don't consider some obscure use case or policy set that is
not encountered often in their social or professional environs.  I'm
happy to have the discussion, but I suspect that a better approach
would be to step back and provide recommendations for end users or
communities to develop their own policies, but with a standardised
method of communicating those policies to others.

> 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:-)

Sorry dude, you're outta luck there.  ;)

> 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.

I'd be in the latter camp, primarily contributing via email where
possible, but this is Australia and in addition to the time difference
we've just had mandatory data retention foisted on us, so a lot more
of my energy is going to both political and technical solutions to
dealing with a country where we're all suspects.  Who'd've thought
we'd come half-way around the globe and struggle through two centuries
only to brand ourselves convicts again?  Incredible.

> 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.

If that happens I'll be sure to go play with my political party, there
are actual problems which need solving all over the place and I don't
have the time for kindergarden krap.

Regards,
Ben

-- 
Ben McGinnes  http://www.adversary.org/  Twitter: benmcginnes
    Writer, Systems Administrator, Trainer, ICT Consultant
Encrypted email preferred, primary OpenPGP/GPG key: 0x321E4E2373590E5D
OpenPGP/GPG key here: http://goo.gl/GVGwT and http://goo.gl/SDs0D
OpenPGP/GPG key transition: http://www.adversary.org/keyswitch.txt.asc

---

From: Ryan Carboni <[email-masked]>
Date: Mon, 6 Apr 2015 21:56:53 -0700

I learned how to use PGP within the past 11 months.

All I have to say is this: PGP will always be a kludge, it is best as a
manual method of transmitting files through insecure means. Anything more
requires a total rewrite of the standard.
I support option two. I'm going to disappear after this, but I suggest the
following language:

something something encrypting more than 2^35 bytes through a 64-bit block
cipher, warn the user that the cipher is less than theoretically secure,
particularly if the data is not compressed.
something something PGP encryption should default to AES.

---

From: DataPacRat <[email-masked]>
Date: Tue, 7 Apr 2015 01:11:11 -0400

On Wed, Apr 1, 2015 at 2:57 PM, Stephen Farrell
<[email-masked]> wrote:

> how you fit into the openpgp universe

I'm a random internet citizen with a long-standing interest in
cryptography and a suspicion of centralized certificate authorities.

> Anyway here's the options:

My chief preference would be for 2t; at least improving the RFC seems
to be worth doing, but I suspect improving the trust model and key
distribution system would make an even more positive impact.

(My secondary choices would be for 3t and 4t.)

Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Tue, 07 Apr 2015 11:09:59 +0200

On 04/01/2015 10:27 PM, Daniel Kahn Gillmor wrote:
>> 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)
> 
> I think i favor this approach, ideally *without* adding trust model
> work into the mix.
> 
> mistake for the WG.  it's a huge rat hole, and a "one trust model
> fits all" approach is probably illegitimate at some deeper level,
> since different people have different adversaries.
> 

I agree with DKG on both favoring Option 2 and avoiding definition of
trust model as part of this update; if anything this can be provided
as an informative rfc outside of the scope of this WG, it is only
relevant to the extent we would need additional mechanisms to
implement them, and the current mechanism provide good flexibility for
various implementations already.

DKGs list of things to look into seems like a good starting point
(although I haven't reviewed it in detail), I also seem to recall
discussion about whether a hard expiry should be introduced that
should be possible within option 2 if we want to.

whoami:
Running https://sks-keyservers.net and one of the SKS developers.

- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public OpenPGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
"Statistics are like a bikini. What they reveal is suggestive, but
what they conceal is vital."
(Aaron Levenstein)

---

From: Brian Sniffen <[email-masked]>
Date: Tue, 07 Apr 2015 19:15:10 -0400

> the openpgp universe (e.g. "I wrote the foo implementation"

I run a thing with 50-200 people using PGP, all scattered GnuPG
implementations.  At some level I care about GnuPG cross-version
compatibility, and have little need for a standard for today's needs.

I would like to have an OpenPGP-like standard for authentication and
secrecy of detached objects---for example, for subresource integrity on
the Web, and in ways that support and cooperate with TLS trust models.
I am hopeful but not optimistic about JOSE getting this right in its
first years.

Both of those would be improved by standardized support for modern
cryptographic choices, and for getting past some of the older choices
that haven't held up well.

Therefore, I prefer option 2.  I'd be happy with the eventual results of
option 3, but I expect it to take an awfully long time.  I don't think
option 4 is helped by standardization---yet.

> option 4t: option 4 + add some trust model/key management

I value having a *different* trust model than X.509/TLS in the space of
available designs. 

I'm not sure whether that means (t): it's good to have a standard way of
endorsing a binding of name to key, and it's good to have a standard
language for use in describing names. A finer grain for user ID packets
would be nice.  If that's a (t) conversation, then I think [2t,3t] is
wise.  Otherwise, [2,3], in that order.

-Brian

> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

-- 
Brian Sniffen
Akamai Technologies

---

From: Werner Koch <[email-masked]>
Date: Wed, 08 Apr 2015 10:01:20 +0200

> a list of specific things to do and other things will be out

I prefer this option.

> option 2t: option 2 + add some trust model/key management

I would like to see an _informational_ RFC describing the trust models
currently in use.  Trust models should not be part of OpenPGP because I
fear that we would end up like PKIX by trying to unify the demands of
many different parties.

Shalom-Salam,

   Werner

p.s.  I wrote and maintain most parts of GnuPG (which includes a
complete PKIX implementation in addition to OpenPGP).

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: David Leon Gil <[email-masked]>
Date: Wed, 08 Apr 2015 15:41:43 +0000

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 <[email-masked]>

---

From: Tom Ritter <[email-masked]>
Date: Wed, 8 Apr 2015 11:14:51 -0500

A suggestion I have, that would dovetail nicely with Google's and
Yahoo's plans of getting deployment experience and iterating based on
it, would be to essentially solicit full-scale proposals from
individuals or teams of individuals, and using those as a base.  This
was something that did not happen in the TLS WG but I thought made a
good amount of sense.

We could discuss a wide range of ideas[0], and set a date (perhaps
IETF 94 in November?) to present all the proposals. It doesn't have to
be a complete textual proposal but a complete outline makes people
think through what they want and how to get there - that can be
greatly beneficial.

-tom

[0] If it was me, I'd use a wiki to copy some ideas cross and clean
them up into a less threaded summary

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 8 Apr 2015 14:05:37 -0400 (EDT)

Nothing like a deadline to motivate replies...

> essay on that is not useful here, but a line or two could

I consume PGP for encrypted discussion of embargoed security issues, e.g.,
in my role as a maintainer of MIT Kerberos.

> flavour of end-to-end security for interpersonal messaging,
I think 2 is the most feasible so far, and we could get agreement on what
to do without too much teeth-gnashing.  Option 3 is tempting, but it may
be a larger project than there is energy to take on.  Option 4 seems like
it ought to be a new working group (and is additionally unlikely to gain
much adoption barring a bit player pushing it to users), so I don't think
we should tackle it here.

I also would prefer to not try to mandate a specific trust model or
models, though we can certainly have some in mind to ensure that what we
come up with is compatible with them.

-Ben

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 08 Apr 2015 20:39:00 +0200

> > flavour of end-to-end security for interpersonal messaging,

I'd probably chose the following options in decreasing priority:
3, 2, 1, 4

Cheers,
Chris.

---

From: Dominik Schuermann <[email-masked]>
Date: Wed, 08 Apr 2015 20:41:35 +0200

Hi,

I am in favor of option 2, a 4880bis with fixed crypto primitives and
modes. Everything else sounds like creating a new standard instead of
fixing OpenPGP.

I work on OpenKeychain, an OpenPGP implementation for Android.

Regards
Dominik

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Apr 2015 12:37:29 +0100

Hi all,

Many thanks for the set of reasoned responses.

I think the outcome is clear (see below for notes I took while
re-reading the thread) and is to go with option 2 - develop a
4880bis. Starting more-or-less from DKG's list as an initial
proposed set of changes seemed to resonate with a few folks.

What I'd like to do next is to get a sense of whether we have enough
volunteer cycles to deliver option 2 (unless people volunteer to do
stuff, and actually do stuff, then stuff won't happen).

That means some folks who can do chair-like things and help organise,
and some folks who'll do editing and review work.

Please send me an offlist mail if you'd be willing and able to help
co-chair a re-formed openpgp WG chartered to do a 4880bis. If you're
going to do that, please do so before Tuesday next April 14th. (Sending
that to the list disqualifies you from chairing btw:-) If you're not
sure, send me a mail anyway and we can chat.

Please send a mail to the list if you're willing and able to do
editing or review of drafts during this calendar year. (Say which
or both.) If you'd also be implementing in roughly that timeframe
feel free to say that too. Doing that in the next week would be
a fine thing. (So deadline: April 17th.)

If we appear to have sufficient volunteer cycles and I can identify
a couple of chair-like beings, then what I'd like is for those to
manage the discussion that ends up with a WG charter that'd get us
to option 2. And if that all goes smoothly, then we can just proceed
with chartering a WG. Optimistically, we could have that all done
and dusted by sometime in May and the WG could fire ahead from
there.

In terms of chairs, I'd prefer to get two, at least one of whom has
done the IETF WG chairing thing before and at least one of whom knows
the subject matter very well. Various combinations of people and
skills can satisfy that ask. I'm also checking separately with a
few folks to see if I can find any victims^H^H^H^H^H^Hvolunteers
with chairing experience who're not on this list but are willing
to help out. (But also sane, etc:-)

In terms of charter, there are a few options to consider, e.g.
how much detail of the planned work to put in a charter,
whether or not to mention a possible re-charter for broader work
and whether or not to let folks write non-normative documents
that describe some trust models. Probably a few more things too.
If we seem to have chairs and editor/reviewers then we can
start in on that week after next, so no need to worry about that
for a little bit.

It's probably worth clarifying one thing too: if we form a WG,
then the WG chairs are the people who pick the editors of WG
drafts. So we don't need to decide that now, we just need to know
there're sensible choices from which the chairs can pick, and
that there's a bunch of folks who'll review text. But if you're
feeling motivated enough to start now on writing a draft then
please go ahead and do so!

And lastly, I'll also start a thread where folks can discuss
what bits of work to include in scope of option 2. Partly that's
to give you all something to do while we work on the process
crap:-) But we also need to give folks a chance to make the
case that their favourite things be included in a 4880bis.

Cheers,
S.

Notes I made when re-reading the responses:

17 responses from:
cole,phb,dkg,ingersoll,
cloos,iang,ritter,mcginnes,
carboni,datapacrat,fiskerstrand,sniffen,
koch,gil,kaduk,mitterer,
schuermann

Those were split as follows (CAPS used for
preferred option where someone said >1 was
ok)

1: gil,mitterer

2: cole, phb, dkg, ingersoll,
cloos,ritter,mcginnes,carboni,
fiskerstrand,SNIFFEN,koch,
gil,kaduk,mitterer,schuermann

3: phb,ritter,sniffen,GIL,MITTERER

4: iang, mitterer

2t: DATAPACRAT

3t: PHB,iang,datapacrat

4t: IANG,datapacrat

- dkg's list referred to a couple of times
- informational (non-normative) trust model
  RFC idea liked by a few
- option 2 now, maybe more later, liked by a
  few
- "t" options (or one-such as normative)
  disliked by a good few

---

From: Derek Atkins <[email-masked]>
Date: Fri, 10 Apr 2015 10:40:41 -0400

Hi,

I realize you've already summed up your responses, but I want to respond
for the record too.  (Yes, I realize it's been 9 days since you sent
this, so I missed your "please try to answer by the 8th" request).

In terms of the options, I think option 2 is best and closest matches
what can realistically be done.  Some others might want 3 or 4.  I doubt
anyone wants 1.

I think we should not do any of the 't' options -- I think 2440 and 4880
got it right by only specifying how to make signatures but not what they
mean.  I.e., it doesn't even define the 'web of trust'.  Now, I do think
it would be reasonable to have *separate* documents that explain, e.g.,
how to do web-of-trust in OpenPGP, how to do CA assertions in OpenPGP,
etc.  Indeed, I'd probably even be willing to author a draft on how to
specify and implement "name constraints" in OpenPGP using assertion
signature notifications.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 10 Apr 2015 16:34:13 -0400

> a fine thing. (So deadline: April 17th.)

I'm willing and able to do editing and review of drafts related to RFC
4880bis during this calendar year.

I'm not directly responsible for any particular OpenPGP implementation
upstream, but i would be willing to supply patches to free software (to
the extent of my ability and time) that implement sensible decisions
within the next calendar year as well, and would be happy to try to help
good free software implementations get wider distribution and testing
via my involvement in Debian.

        --dkg

---

From: Tom Ritter <[email-masked]>
Date: Sat, 11 Apr 2015 21:30:36 -0500

> a fine thing. (So deadline: April 17th.)

I can definitely commit to reviewing. If the drafts are maintained in
a collaborative format (I like TLS' github model) I will make my
suggestions even easier to integrate and will be encouraged to do more
of them ;)

-tom

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Apr 2015 16:44:14 +0100

> suggestions even easier to integrate and will be encouraged to do more

Thanks. More indications like that to the list would be welcome.
Even if you feel it's obvious, it may help the IESG when it comes
time to evaluate whether or not there's sufficient interest to
form a new WG.

Thanks,
S.