Subject: Re: [openpgp] Proposed WG charter

From: Simon Josefsson <[email-masked]>
Date: Mon, 1 Jun 2015 14:18:23 +0200

"Christopher LILJENSTOLPE" <[email-masked]> writes:

> Greetings,
>
> 	Here's a first cut of the charter.  We'd like to get this
> 	process started ASAP, so please make any comments, suggestions
> 	as soon as possible.

Good starting point.  It looks rather open ended when it comes to the
actual issues with RFC 4880 though.  Can you mention at least five
top-priority issues in RFC 4880 that needs to be adressed?  This would
tighten the scope a bit, without limiting ability to adress other
issues.

/Simon

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Mon, 01 Jun 2015 14:30:29 +0200

On 06/01/2015 02:18 PM, Simon Josefsson wrote:
>> Here's a first cut of the charter.  We'd like to get this process
>> started ASAP, so please make any comments, suggestions as soon as
>> possible.
> 
> Good starting point.  It looks rather open ended when it comes to
> the actual issues with RFC 4880 though.  Can you mention at least
> five top-priority issues in RFC 4880 that needs to be adressed?
> This would tighten the scope a bit, without limiting ability to
> adress other issues.

I agree that limiting the scope will become important at some point,
but isn't this a matter for the WG itself and not necessarily
something that should be part of an initial charter?

its current form looks good to me

- -- 
- ----------------------------
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
- ----------------------------
Qui audet vincit
Who dares wins

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 01 Jun 2015 09:52:18 -0400

> tighten the scope a bit, without limiting ability to adress other

I think it would only tighten the scope if we *did* prohibit addressing
any un-mentioned issues, and i'd rather not commit to something with
that kind of wording.

OTOH, having some explicit targets listed here (without limiting the
work to those targets) would help the group to make sure that 4880bis
did cover the relevant ground.

Simon, if you had to list items that you thought were "must-haves",
which would they be?

Some highlights I'd go for (needs wordsmithing, just brainstorming here,
and not in any particular order):

 * inclusion of the CFRG elliptic curves

 * proper AEAD symmetric crypto

 * updated mandatory-to-implement algorithms

 * updated fingerprints

I'm not sure they need to be in the charter, but if there's a general
sense from the group that they should be, and a prompt proposal for the
language change, i have no objection to including them.

     --dkg

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 1 Jun 2015 16:25:01 +0200

Den Mon, 01 Jun 2015 09:52:18 -0400
skrev Re: Proposed WG charter:

> I think it would only tighten the scope if we *did* prohibit
> addressing any un-mentioned issues, and i'd rather not commit to
> something with that kind of wording.

I agree.  I suppose this is up to the ADs though.

> did cover the relevant ground.

Yes.

> Simon, if you had to list items that you thought were "must-haves",

I don't know.  That is the primary reason for asking the charter to
include a list, to give me and others a sense of direction.  The
charter proposal is written in a broad way now, which can be
counter-productive (it leads to meta-discussions).

> Some highlights I'd go for (needs wordsmithing, just brainstorming
> here, and not in any particular order):
> 

Yes.  I would mention Curve25519 and Ed25519 directly, or keep it
general and say "new elliptic curve key agreement and digital
signatures" instead.

There appears to be interest in Curve25519/EdDSA algorithms from people
on this list, and I haven't seen interest in any other algorithms.

Referring to CFRG explicitly is problematic because of timeline and
authority reasons.  The CFRG hasn't published anything or made
any decisions, so referring to CFRG seems unnecessarily
limiting in when we can publish.  Regarding authority: the CFRG can
make general recommendations, and I'm sure reasonable arguments will be
listened to, but I believe the decision on which algorithms are useful
for OpenPGP is one that belongs here and not in the CFRG.

>  * proper AEAD symmetric crypto

Sure.  Is there any proposals on the table?

>  * updated mandatory-to-implement algorithms

Makes sense.

>  * updated fingerprints

No idea.

> sense from the group that they should be, and a prompt proposal for
> the language change, i have no objection to including them.

I suggest to mention everything you can think of that there is no
controversy over.

I recall improvements to PGP/MIME was discussed?

There is also my old OpenPGP mail/news header proposal [1], but I'm not
sure there is energy for it.  I have also started to think that it ended
up being too complex for its own good.

/Simon

[1] https://tools.ietf.org/html/draft-josefsson-openpgp-mailnews-header-07

---

From: Werner Koch <[email-masked]>
Date: Mon, 01 Jun 2015 17:48:48 +0200

> general and say "new elliptic curve key agreement and digital

Both ways are okay for me.

> authority reasons.  The CFRG hasn't published anything or made

Right, we would need to wait for endianess peace ;-)

> Sure.  Is there any proposals on the table?

It has been suggested that we should wait for the outcome of the CAESAR
competition.  However, that will be by the end of 2017 which would
required that we plan for 4880bis not ealier than mid 2017 - a year
later than the suggested plan.

We would also go with OCB mode which would be readily available.

> No idea.

That is important because we need to be future poof and plan to retire
SHA-1.  That also means a v5 packet format and thus this goal alone
would not be sufficent.  Better don't put it explictly on the list.

> I recall improvements to PGP/MIME was discussed?

That means to update RFC-3156.  Although related top OpenPGP, it is a
different thing.  I would be in favor of adding this as a second work
item to charter.  The required changes are minimal.

Shalom-Salam,

   Werner

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 01 Jun 2015 12:32:17 -0400

> would not be sufficent.  Better don't put it explictly on the list.

I'm not convinced that an updated fingerprint requires a v5 packet
format.  Can you explain that?

> item to charter.  The required changes are minimal.

I think the WG should focus on 4880bis to try to get it done cleanly and
promptly.  If we do it right, this would indicate functional interest
and an active community.  If an update to PGP/MIME is something the
community also ends up working on, we ought to be able to recharter to
expand into work on that.

           --dkg

---

From: Werner Koch <[email-masked]>
Date: Mon, 01 Jun 2015 19:15:17 +0200

> format.  Can you explain that?

Without that we will have two fingerprints for the same key.  That may
lead to confusion.  In the past it was easy to decide what kind of key
you have.  A v5 packet format also makes it easier to change the
implicit available preferences (e.g. 3DES) because applications
supporting a v5 would also support the new preferences

OTOH, this introduces backward incompatibility.  We need to discuss the
advantages of a v5 format versus the need for a new fingerprint format.

> community also ends up working on, we ought to be able to recharter to

My conclusion from the discussion at the OpenPGP summit was that there
is a need to add something to PGP/MIME.  For example to split a long
message so that a (mobile) device does not need to download the entire
message for a summary view.  But well, that would affect S/MIME as well
so might be better taken up by the MAIL WG (in case that WG exists).

Shalom-Salam,

   Werner

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 01 Jun 2015 13:40:37 -0400

On Mon 2015-06-01 13:15:17 -0400, Werner Koch wrote:
> lead to confusion.

I think i'm still not convinced by this -- can you give an example of
what kind of confusion you're hoping to avoid?

> In the past it was easy to decide what kind of key you have.  A v5
> packet format also makes it easier to change the implicit available
> preferences (e.g. 3DES) because applications supporting a v5 would
> also support the new preferences

Users can infer that keys using new algorithms will implicitly have the
new preferences; But we can also indicate the new preferences explicitly
within the old format.

I think the main difference you're offering with a v5 format is the
ability to explicitly disavow the 4880 MTI algorithms.  Is that right?
Maybe there are other ways that implementations can explicitly disavow
the 4880 MTI algorithms, that can be done without introducing a v5
format?  What's the advantage of introducing a mandatory
incompatibility?

> so might be better taken up by the MAIL WG (in case that WG exists).

Yes, i think this kind of thinking and work is good to do, but i don't
think we should focus on it in this WG until we're comfortable with a
4880bis.  If folks want to discuss it elsewhere, and it turns out there
are pieces needed in 4880bis to make it work right, then we should
include those pieces in 4880bis.  But i do think that touches on S/MIME
as well, so it'd be nice to keep that perspective in the loop.

        --dkg

---

From: Werner Koch <[email-masked]>
Date: Mon, 01 Jun 2015 21:19:10 +0200

> what kind of confusion you're hoping to avoid?

Alice reads her 40 hex digit fingerprints on the phone using oldtool;
Bob comapres it using his newtool, which shows a different fingerprint.
Both don't know anything about fingerprint details but have been advised
to compare them character by character.  Their conclusion will be that
this is not the right key.

Even though I am not working on a helpdesk I have had phone conversions
to check X.509 fingerprints which ended into me explaining the different
types of fingerprints in use for X.509.

For ECC, being pretty new, we could easily switch to a new format but
what shall we keep on using the old for RSA keys?

Note that I do not insist on binding a new fingerprint format to the
public key format version, it is just something which needs to be
discussed. 

> new preferences; But we can also indicate the new preferences explicitly

Which new algorithms?  I doubt that we will add a new cipher algorithm
to replace 3DES.

> ability to explicitly disavow the 4880 MTI algorithms.  Is that right?

Yes.  So that we won't need to support all old algorithms till 2106.

BTW, why do you and some others use the term MTI?  That term seems to
mean mandatory-to-implement and comes from Jabber, to me this sounds
very much like MUST (cf. RFC-2119).

> format?  What's the advantage of introducing a mandatory

Not sure.  However, we are right now discussing the charter ;-)

Salam-Shalom,

   Werner

---

From: "Derek Atkins" <[email-masked]>
Date: Mon, 1 Jun 2015 15:32:53 -0400

Werner,

> this is not the right key.

Well, most likely the new fingerprint will not be 40 hex digits, it would
be a different length.  So oldtool and newtool would have different
lengths and, as a result, they would (hopefully) know they were looking at
different values.

That doesn't necessarily help them figure out how to get newtool to output
something that oldtool can verify.

> very much like MUST (cf. RFC-2119).

The term MTI (Mandatory to Implement) is used to differentiate it from MTU
(Mandatory to Use).  I.e., an MTI algorithm is one that you're guaranteed
to be ABLE to use, but there is no requirement that you actually DO use
it.

-derek

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

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 1 Jun 2015 21:40:43 +0200

> > BTW, why do you and some others use the term MTI?  That term seems
> > to mean mandatory-to-implement and comes from Jabber, to me this
> > sounds very much like MUST (cf. RFC-2119).
> 
> The term MTI (Mandatory to Implement) is used to differentiate it
> from MTU (Mandatory to Use).  I.e., an MTI algorithm is one that
> you're guaranteed to be ABLE to use, but there is no requirement that
> you actually DO use it.

I think there is also a possible orthogonal Mandatory to Deploy so you
would have:

MTI: Code needs to be written

MTD: Code that was written need to be enabled in deployment

MTU: Code that was written actually need to be used

The distinction between the two latter is when a protocol has several
MTD algorithms, which is the typical case.

/Simon

---

From: Watson Ladd <[email-masked]>
Date: Mon, 1 Jun 2015 13:03:56 -0700

> MTD algorithms, which is the typical case.

But I don't want to expose this choice to users, any more then signing and
encryption ordering. There are real usability and deployment issues that
need to get solved, that require changes to what is going on behind the
scenes.
>
> /Simon
>
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 2 Jun 2015 09:18:20 +0200

Den Mon, 1 Jun 2015 13:03:56 -0700
skrev Re: [openpgp] Proposed WG charter:

> > > > BTW, why do you and some others use the term MTI?  That term
> > > > seems to mean mandatory-to-implement and comes from Jabber, to
> > > > me this sounds very much like MUST (cf. RFC-2119).
> > >
> > > you're guaranteed to be ABLE to use, but there is no requirement
> > > that you actually DO use it.
> >
> > I think there is also a possible orthogonal Mandatory to Deploy so
> > you would have:
> >
> > The distinction between the two latter is when a protocol has
> > several MTD algorithms, which is the typical case.
> 
> But I don't want to expose this choice to users, any more then
> signing and encryption ordering. There are real usability and
> deployment issues that need to get solved, that require changes to
> what is going on behind the scenes.

Users aren't involved in the two first parts.  Users are involved in
the MTU step since ultimately they own the authority to chose their
preferred algorithm -- assuming the protocol allows more than one
choice, of course.  How they are involved, i.e., whether
implementations expose the choices or not, is an UX issue.  Certainly
there are challenges there, but I don't see the IETF has a lot to
contribute around UX.

/Simon

---

From: ianG <[email-masked]>
Date: Tue, 02 Jun 2015 11:43:21 +0100

>>> several MTD algorithms, which is the typical case.

Interesting, thanks for the explanation!

The thing that I would see as being different from MUST and the above 
three MTx is that the latter (Jabber?) has thought about how to deploy 
changes.  It would seem to imply there is someone somewhere pulling the 
strings on the puppet to make the migration happen.  There is a 
foundation behind Jabber, maybe that's the puppetmaster.

This is something that IETF has shied away from, and OpenPGP is perhaps 
a leading proponent of not having any institutional push on the choice 
of crypto.

I think the reality of OpenPGP's lifecycle is that we are going to be 
dealing with legacy implementations and algorithms anyway, and just 
specifying MUST(s) will probably be sufficient.  The challenge is to 
really get that list down below 3.  Beyond that, distinctions such as 
MTI and MTD are going to be seen as legacy deployment.

tl;dr - I suspect we can stick to MUST rather than MTx.

>> what is going on behind the scenes.

I'm with you!

> there are challenges there, but I don't see the IETF has a lot to

Which is a cop out.  Users are not typically capable of making that 
choice, and in the making of that choice, they cause network problems 
for everyone.  Obviously we can give them that choice and wrap it up in 
some form of crypto-freedom argument, but we can also give them a 
pencil, paper and a one time pad.  The purpose of the system is to 
deliver security, not crypto-purity, and everything we know about 
security points to the protocol author making the crypto decisions for them.

(But this is an old debate, everyone knows it, and the charter on the 
ground is moving OpenPGP forward, not recasting it entirely.)

iang

---

From: Werner Koch <[email-masked]>
Date: Tue, 02 Jun 2015 14:13:31 +0200

> dealing with legacy implementations and algorithms anyway, and just

I don't think that "legacy" is an appropriate term here.  In contrast to
many other protocols (e.g. IP) we need to care about data at rest.
There are huge amounts of encrypted or signed data on disks and tapes
which eventually need to be decrypted. 

It might be good to think of OpenPGP data like the tar format and not
like http/smtp/xmpp.

Salam-Shalom,

   Werner

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Jun 2015 10:32:45 -0400

> this is not the right key.

This is a good point that I had not considered earlier but turns out is
covered in my UDF proposal which guarantees that the leading digit of a UDF
fingerprint is M or S and thus an invalid hex digit :)

There are two issues that I believe we should separate:

1) The method of constructing the fingerprint

2) The method of constructing what is fingerprinted.

The first can be set in stone for a century or more. The second must be
changeable.

Right now we are discussing a v5 key packet format. It would be foolish to
imagine it is going to be the last. We should expect the key packet format
to change albeit infrequently. A new version every ten years or so.

We should also expect and encourage people to fork the key packet format if
that is necessary for their particular application. I am currently using
fingerprints to S/MIME and DNSSEC but I have absolutely no interest in
using the OpenPGP format there and I am certain that those communities
won't either.

This separation is achieved by the construct:

UDF = Base32d (H ( <Content-Type> + ':' + H (Content)))

Lets say that we are working only with OpenPGP keybindings and we are doing
OpenPGPv8. We have three different keybindings that we might encounter

application/openpgp-keybindingv5
application/openpgp-keybindingv7
application/openpgp-keybindingv8

Easy enough to cycle through all three to see if we have a match.

Alternatively, put a version identifier field in the keybinding and we can
use just one identifier.

The reason I think this is going to matter a lot is because I use
fingerprints to specify a root of trust in any identifier. So for example,
let us say you want to say 'go to www.example.com validating the entries
via the DLV root with fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ-SV75J':

www.example.com.MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ-SV75J

With this type of construct, I can deploy a DNSSEC hierarchy that is
entirely under my control. No control for 'non-profits' whose million a
year head has told me a stone cold lie to my face.

I also want to be able to use strong email addresses for PGP and S/MIME
without the user having to know which is going to be used.

The PPE Key manager is almost done. Run the keymanager and it will
automatically enable Windows Live Mail to use S/MIME to send and receive
end-to-end encrypted with absolutely no additional user interaction.

Under the covers, we create a new email address, a 'strong' email address
of the form:

<fingerprint>?<username>@<domain-name>

Where <fingerprint> is the fingerprint of a trust root under which the
intended recipient's email encryption preferences are set. Obviously, one
of those preferences can be 'send S/MIME mail version X encrypted under
cert Y'. But I also intend to add 'send OpenPGP mail version P encrypted
under key Q'.

The point is that the end user does not need to know whether their email
client is doing OpenPGP or S/MIME or whatever next gen mail system we do.
And so the fingerprint format should not make a commitment to one single
specification.

I believe we have at minimum two types of content that we want to take
fingerprints of:

* Code distributions
* Keys

For keys, I believe there are at least four format families that may be
encountered.

* OpenPGP
* PKIX Certificate / KeyInfo
* DNSSEC
* Whatever JSON based scheme replaces all the above.

So what I think the charter should give as deliverables are:

1) A new Key package format for OpenPGP keys.
2) A fingerprint mechanism that is content neutral with OpenPGP as the
initial use case.

---

From: ianG <[email-masked]>
Date: Tue, 02 Jun 2015 22:17:16 +0100

> which eventually need to be decrypted.

Good point.

> It might be good to think of OpenPGP data like the tar format and not

Which really does put the point on cipher suite choices.  We should be 
thinking in terms of decades ahead.

I wonder if implementations could add a re-encrypt mode to bring old 
archives into the new formats?

iang

---

From: christopher liljenstolpe <[email-masked]>
Date: Wed, 03 Jun 2015 15:58:56 -0700

those seem like reasonable issues to identify. Daniel, do you want to edit 
the
gist, and send me a pull?

On Mon, Jun 01, 2015 at 6:52 AM, Daniel Kahn Gillmor < 
[email-masked] [[email-masked]] > wrote:

* updated fingerprints

--dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 03 Jun 2015 21:46:39 -0400

On Wed 2015-06-03 18:58:56 -0400, christopher liljenstolpe wrote:
> those seem like reasonable issues to identify. Daniel, do you want to
> edit the gist, and send me a pull?

It's not clear to me how to give you a pull request on a gist via
github's interface.  I just mailed you a wordsmithing patch, which i'm
also including here.

Regards,

        --dkg

>From 7b367bdf517820bc97ef6d348d4c728e36148e5f Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 3 Jun 2015 21:03:15 -0400
Subject: [PATCH] wordsmithing

---
 openpgp-charter.md | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/openpgp-charter.md b/openpgp-charter.md
index 1617533..263a29a 100644
--- a/openpgp-charter.md
+++ b/openpgp-charter.md
@@ -44,15 +44,17 @@ produce a revision of RFC4880 to address issues that have been
 identified by the community since the working group was originally
 closed.
 
-Some of the revisions might include, but are not limited to:
+These revisions will include, but are not limited to:
 
-* inclusion of the CFRG elliptic curves
+* Inclusion of elliptic curves recommended by the CFRG
 
-* proper AEAD symmetric crypto
+* A symmetric encryption mechanism that offers modern message
+  integrity protection (e.g. AEAD)
 
-* updated mandatory-to-implement algorithms
+* Revision of mandatory-to-implement algorithm selection and
+  deprecation of weak algorithms
 
-* updated fingerprints
+* An updated public-key fingerprint mechanism
 
 The Working Group will perform the following work
 -------------------------------------------------
-- 
2.1.4

---

From: Werner Koch <[email-masked]>
Date: Thu, 04 Jun 2015 10:35:24 +0200

> * inclusion of the CFRG elliptic curves

Does that mean we can finish the goal only if we include these curves
(as MUST algorithms)?

Salam-Shalom,

   Werner

---

From: Derek Atkins <[email-masked]>
Date: Thu, 04 Jun 2015 11:50:34 -0400

> archives into the new formats?

I personally would love such a feature...  But that's out of scope for
the OpenPGP WG as it's completely an implementation detail.  Also, it
only works if the signature is inside the encryption ;)

-derek

---

From: Werner Koch <[email-masked]>
Date: Thu, 04 Jun 2015 18:23:05 +0200

> I personally would love such a feature...  But that's out of scope for

Do you mean a feature to change the bulk encryption mode but keeping the
same session key, right?  Everything else wwould only work if you do it
just for one public key (i.e. the one where you own the secret key) and
remove the other PKESKs.

Updating the PKESK or adding new PKESKs or SKESKs would a different but
also useful feature.

Salam-Shalom,

   Werner

---

From: "Derek Atkins" <[email-masked]>
Date: Thu, 4 Jun 2015 12:30:31 -0400

> Updating the PKESK or adding new PKESKs or SKESKs would a different but

For me it would be completely replacing the bulk encryption and possibly
also the public-key encryption.  For example, I have messages that are
IDEA-encrypted to my (old) RSA key, and I'd like to re-encrypt them using
AES to e.g. an ECC key.

but again, this is getting way far off topic for this list.

-derek

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 04 Jun 2015 13:18:56 -0400

> Does that mean we can finish the goal only if we include these curves

I don't think this says anything about MUST algorithms (that'd be part
of the MTI update decisions, which the charter doesn't make any
statement about).  I personally think that a 4880bis without at least
one of the CFRG curves in it would be a bit of a shame, but that's with
no hats on.

If the group disagrees with that (if we're generally ok with the value
of a 4880bis without any updated curves) then we should loosen the
language in the charter so that it's not a requirement for 4880bis.

Do we want to do a rough straw poll on this?

Do you think that a 4880bis should include some specification for how to
use at least one of the new CFRG curves?

      --dkg

---

From: ianG <[email-masked]>
Date: Thu, 04 Jun 2015 18:26:58 +0100

On 4/06/2015 16:50 pm, Derek Atkins wrote:
> the OpenPGP WG as it's completely an implementation detail.

Well, we could put in the draft a comment that providing a re-encrypt 
mode would be very useful for helping us all to deprecate old crappy 
algorithms?

> Also, it

Hmmm... yes.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 4 Jun 2015 13:28:24 -0400

> Do we want to do a rough straw poll on this?

No. absolutely not.

We are in a charter discussion. At this point all we need to know is if
this is something people may want to discuss when CFRG is finished.

I think it is obviously something the WG will probably want to consider and
if not, the AD should come and slap people with a wet fish till they do.

So all we need to do at this stage is to ask if anyone objects to
discussing the CFRG curves as MTI. It should be called out in the charter
because it is a cross-WG, cross-IETF/IRTF issue but we can't make a
decision on it right now.

---

From: ianG <[email-masked]>
Date: Thu, 04 Jun 2015 18:30:36 +0100

> use at least one of the new CFRG curves?

Personally, I think the draft should specify one curve, chosen from 
what's out there, and it should be the best judgement we can come up 
with about the future of curves.  For that, I'd be prepared to wait a 
year or so if the CFRG gives us that confidence.

Then, ditch the rest...  But you all know how I think by now...

iang

---

From: Werner Koch <[email-masked]>
Date: Thu, 04 Jun 2015 21:54:49 +0200

> year or so if the CFRG gives us that confidence.

or two ...
or three ...
or until Lilliput and Blefuscu are united.

scnr,

  Werner

---

From: Werner Koch <[email-masked]>
Date: Thu, 04 Jun 2015 21:55:48 +0200

> mode would be very useful for helping us all to deprecate old crappy

That is not an protocol issue.

Shalom-Salam,

   Werner

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 04 Jun 2015 21:39:31 +0100

> if not, the AD should come and slap people with a wet fish till they do.

Now where did I leave that wet fish? I know it's around
here somewhere.... :-)

FWIW, I'm fine that this be considered later or or that
the chairs prefer to "bank" a few easy decisions early
on. Either is fine.

S.

---

From: "Christopher LILJENSTOLPE" <[email-masked]>
Date: Fri, 05 Jun 2015 08:58:47 -0700

Greetings,

	To avoid being slapped by a misplaced (hence probably very stinky fish), I've updated the charter again.  Gist, as before is at:

https://gist.github.com/liljenstolpe/a4a45477d1b89ea45e09

I THINK I have captured the consensus of the group, so we're going to do a negative control on this one.  If there is no opposition before 12:00 UTC Saturday, I'm going to ask Stephen to start the chartering process (or actually, am doing so right now).

However, please voice your support if you feel strongly :)

	Christopher

-- 
李柯睿
Avt tace, avt loqvere meliora silentio
Check my PGP key here: http://www.asgaard.org/cdl/cdl.asc
Current vCard here: http://www.asgaard.org/cdl/cdl.vcf
keybase: https://keybase.io/liljenstolpe

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 09 Jun 2015 15:28:50 +0200

> It might be good to think of OpenPGP data like the tar format and not

It might help to suggest (in the specification) that OpenPGP
implementations MAY implement decrypt support for older crypto
algorithms but MUST NOT encrypt using them.

Otherwise I suspect that implementations might accidentally (or not) end
up implement both encrypt and decrypt because that is the natural way of
implementing crypto, and supporting both variants simplify testing (you
can test roundtrips).  However doing that is bad for security.

/Simon

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 10 Jun 2015 16:54:01 -0400

> can test roundtrips).  However doing that is bad for security.

I agree with this approach for encryption algorithms (something like MAY
decrypt, MUST NOT encrypt), and probably with something analogous for
outdated signature algorithms (e.g. MAY verify, MUST NOT sign).

We'd also want to provide guidance that encourages signalling to the
user somehow that while the decryption was successful, the
confidentiality of the content can't be assured.  Some similar semantics
should be exposed about the verified signature being unreliable due to
known-weak crypto.

           --dkg

---

From: [email-masked]
Date: Thu, 11 Jun 2015 13:11:38 -0400

On 6/10/2015 at 4:54 PM, "Daniel Kahn Gillmor" <[email-masked]> wrote:

>We'd also want to provide guidance that encourages signalling to 
>the user somehow that while the decryption was successful, the
>confidentiality of the content can't be assured.  Some similar 
>semantics should be exposed about the verified signature being unreliable 
>due to known-weak crypto.

=====

There are also some other issues which might be useful to bring to the user's attention.
Here is one, but am not sure if the 4880 revision is the place for it, or if it belongs more in some tutorial.

When GnuPG/PGP symmetrically encrypts a message, there is no padding added to the plaintext before encryption.
As a result it is possible to tell from PGPDump if the plaintext of two different symmetrically encrypted messages differ by only one character.

Here are some examples of PGP symmetrically encrypted messages consisting of only the word 'no' or only the word 'yes' :

Checking the messages in PGPdump,  http://www.pgpdump.net/, and
looking at the 'Symmetrically Encrypted Data Packet' analysis,
instantly distinguishes between plaintexts of different lengths.

Here are 3 sets of PGP symmetrically encrypted ciphertexts, each set
consisting of 'no' and 'yes', followed by the PGPdump analysis.

*****

plaintext: no

Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
        New version(4)
        Sym alg - Twofish with 256-bit key(sym 10)
        Iterated and salted string-to-key(s2k 3):
                Hash alg - SHA256(hash 8)
                Salt - 1f bd c5 c5 cc d1 11 4a
                Count - 65536(coded count 96)
New: Symmetrically Encrypted and MDC Packet(tag 18)(69 bytes) <--
        Ver 1
        Encrypted data [sym alg is specified in sym-key encrypted
session key]
                (plain text + MDC SHA1(20 bytes))

*****

plaintext: yes

PGPdump Results

Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
        New version(4)
        Sym alg - Twofish with 256-bit key(sym 10)
        Iterated and salted string-to-key(s2k 3):
                Hash alg - SHA256(hash 8)
                Salt - 1f ff 48 e0 19 17 f9 f7
                Count - 65536(coded count 96)
New: Symmetrically Encrypted and MDC Packet(tag 18)(70 bytes) <--
        Ver 1
        Encrypted data [sym alg is specified in sym-key encrypted
session key]
                (plain text + MDC SHA1(20 bytes))

******

plaintext: no

PGPdump Results

Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
        New version(4)
        Sym alg - AES with 256-bit key(sym 9)
        Iterated and salted string-to-key(s2k 3):
                Hash alg - SHA256(hash 8)
                Salt - 1b 5d c7 e9 05 ef f6 2e
                Count - 65536(coded count 96)
New: Symmetrically Encrypted and MDC Packet(tag 18)(69 bytes)<--
        Ver 1
        Encrypted data [sym alg is specified in sym-key encrypted
session key]
                (plain text + MDC SHA1(20 bytes))

*****

plaintext: yes

PGPdump Results

Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
        New version(4)
        Sym alg - AES with 256-bit key(sym 9)
        Iterated and salted string-to-key(s2k 3):
                Hash alg - SHA256(hash 8)
                Salt - bf 1b 7f 17 77 d1 78 66
                Count - 65536(coded count 96)
New: Symmetrically Encrypted and MDC Packet(tag 18)(70 bytes)<--
        Ver 1
        Encrypted data [sym alg is specified in sym-key encrypted
session key]
                (plain text + MDC SHA1(20 bytes))

*****

plaintext: no

PGPdump Results

Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
        New version(4)
        Sym alg - Triple-DES(sym 2)
        Iterated and salted string-to-key(s2k 3):
                Hash alg - SHA256(hash 8)
                Salt - 4e 98 7d a9 aa 33 4b 0e
                Count - 65536(coded count 96)
New: Symmetrically Encrypted Data Packet(tag 9)(38 bytes)<--
        Encrypted data [sym alg is specified in sym-key encrypted
session key]

*****

plaintext: yes

PGPdump Results

Old: Symmetric-Key Encrypted Session Key Packet(tag 3)(13 bytes)
        New version(4)
        Sym alg - Triple-DES(sym 2)
        Iterated and salted string-to-key(s2k 3):
                Hash alg - SHA256(hash 8)
                Salt - ef 9b 8f bd 4f 37 97 fd
                Count - 65536(coded count 96)
New: Symmetrically Encrypted Data Packet(tag 9)(39 bytes)<--
        Encrypted data [sym alg is specified in sym-key encrypted
session key]

*****

As an additional oddity in the PGP armoring, for PGP symmetrically
encrypted texts, it is possible to distinguish between 'no' and 'yes'
just by briefly *looking* at the ciphertext.

The 'no' ciphertext has a padding character added, '=' to the end of
the ciphertext, on the line before the checksum, while  the 'yes'
texts do not.
 (In the 3DES example, there is an 'extra' '=' for the 'no'.

Have tested this for several 'either/or' messages  of different
lengths :
(accept, decline),  (pardon, execute),  (pass, recommend), etc.
and it is always possible to distinguish between them in PGPdump, even
when the messages is signed and encrypted to a public key.

For a third party checking PGP messages, it is easy to encrypt these
plaintext sets to any public key, and check the length of the
Symmetrically Encrypted Packet in PGPdump, and reasonably infer which
of the either/or set is sent.

There is a simple workaround to prevent this type of analysis:

Just press the spacebar to add empty characters to a decided length  (e.g.  no followed by 6 spaces or 'yes' followed by 5 spaces).

Again,

Sorry if it does not belong in the 4880 revision,
but wanted to bring it up to hear where the best place is to alert users to it, 
who might otherwise thing that conventional encryption of short messages does not offer a way to make a good guess at the content.

vedaal

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 11 Jun 2015 14:27:55 -0400

> There are also some other issues which might be useful to bring to the

I think the issue you're raising here can be summarized as
"content-length hiding for encrypted messages"

It seems to me that this would fit in 4880bis, at the very least in the
security considerations section.

The way people usually try to defend against this sort of attack is to
pad the content up to some common boundary size (this doesn't help if
your two messages straddle a boundary, of course).  Your example of "hit
the spacebar" is a very domain-specific instance of this suggestion,
though it assumes that the recipient will interpret "pardon " the same
as "pardon", which may or may not be true depending on the make and
model of the lethal machinery interpreting the governor's directive.

The literature on the efficacy of padding algorithms suggests that
statistical modeling attacks (on datasets more complex than your
pardon/execute example) can defeat simple padding schemes a
non-negligible percent of time, for example:

   http://arxiv.org/abs/1403.0297

That said, entirely non-padded mechanisms fail even more often :)

An interesting approach would be to look at the existing standard and
common implementations to see whether there is a way to provide a more
generic padding mechanism using only existing packet types.  Have you
tried to do that?

           --dkg

---

From: Werner Koch <[email-masked]>
Date: Thu, 11 Jun 2015 22:25:48 +0200

> common implementations to see whether there is a way to provide a more

OpenPGP does not define any _content_ padding rules and thus this can't
be implemented.  Without a strict standard on this we would also open a
large hidden channel.

Actually, you can't solve that on the OpenPGP protocol level because it
is application specific.  In contrast to transport encryption we can't
use filler traffic.

This is similar to meta data and should be solved in that context (or at
the application level).

Salam-Shalom,

   Werner

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 11 Jun 2015 17:28:04 -0400

> be implemented.  Without a strict standard on this we would also open a

hmm... just brainstorming, and all within RFC 4880...

What if you did:

A Sym. Encrypted Integrity Protected Data Packet
   containing three packets:
B    Literal Data packet (message)
C    Literal Data packet (padding)
D    Modification Detection Code packet

How would this be interpreted byexisting implementations?

Alternately, what if C was an entirely new packet type (e.g. "Padding
packet", with a new type assignment).  How do existing implementations
deal with such a sequence?  Could updated implementations be designed to
ignore/discard the contents of C ?  What are the risks of the hidden
channel here?  the hidden channel could be constrained by requiring that
padding packets contain a certain required sequence of octets (e.g. all
0s), though that still leaves the hidden channel that is just the size
of the padding used.

> This is similar to meta data and should be solved in that context (or at

Certainly the application layer is going to have a better understanding
of the general characteristics of similar messages, and so can make a
better guess at what kinds/patterns of padding make sense in this
context.  But we can define a padding mechanism within OpenPGP that
application layers could operate, leaving the policy of the padding
mechanism to the layer that knows most about it.

          --dkg

---

From: [email-masked]
Date: Thu, 11 Jun 2015 18:45:24 -0400

>> OpenPGP does not define any _content_ padding rules and thus 
>this can't  be implemented.  Without a strict standard on this we would also 
>open a  large hidden channel.

.....

>D    Modification Detection Code packet

.....

> But we can define a padding mechanism within OpenPGP that

=====

But could it be made backward compatible ?

Another possible workaround that would be both backward compatible, and not tamper at all with the plaintext content,
would be to simply do:

Encrypt,  then  Sign and Encrypt

The first layer of encryption provides more than enough beautiful padding.

Any analysis of the Sym. Encrypted Integrity Protected Data Packet of the final  [S&E ( E)] message
would show a large enough length to be infeasible to determine the original plaintext length and content.

It's not necessary to change any standards, only to mention it in the security considerations, with possible simple workarounds,
and leave it up to the user.

(Don't you guys already have more than enough work ?    ;-)    )

vedaal

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 12 Jun 2015 11:24:51 -0400

On Thu 2015-06-11 18:45:24 -0400, [email-masked] wrote:
>>> OpenPGP does not define any _content_ padding rules and thus this
>>> can't be implemented.  Without a strict standard on this we would
>>> also open a large hidden channel.
>
> .....
>

My proposal above might actually be backward compatible -- have you
tried it with existing implementations?  i haven't, i'm just suggesting
it as a possible mechanism.  It may turn out that part C needs to be
something other than a Literal Data packet to make it work, but that
might *still* be backward compatible with many OpenPGP implementations,
i haven't checked.

> Another possible workaround that would be both backward compatible,
> and not tamper at all with the plaintext content, would be to simply
> do:
>

this is backward-compatible only in the sense that existing tools can
process it -- but it wouldn't produce the cleartext with:

   gpg --decrypt foo.pgp

because you'd need an extra layer of decryption to make that work.

> The first layer of encryption provides more than enough beautiful padding.

It's not a question of "enough" padding -- if the padding size is
constant each time, you'll still see the offset.  Have you actually
tried this scheme with your "pardon" and "execute" examples?  the
difference in size is still visible:

0 dkg@alice:~$ echo pardon | gpg --encrypt -r $PGPID | gpg --sign --encrypt -r $PGPID > x.pgp
0 dkg@alice:~$ echo execute | gpg --encrypt -r $PGPID | gpg --sign --encrypt -r $PGPID > y.pgp
0 dkg@alice:~$ ls -l
total 8
-rw-r--r-- 1 dkg dkg 1843 Jun 12 11:19 x.pgp
-rw-r--r-- 1 dkg dkg 1844 Jun 12 11:20 y.pgp
0 dkg@alice:~$ 

> Any analysis of the Sym. Encrypted Integrity Protected Data Packet of
> the final [S&E ( E)] message would show a large enough length to be
> infeasible to determine the original plaintext length and content.

If you know how many layers of encryption have been done, the length is
still computable.

> It's not necessary to change any standards, only to mention it in the
> security considerations, with possible simple workarounds, and leave
> it up to the user.

If that turns out to be the best way forward, i'm fine with that too.

  --dkg