Subject: Re: [openpgp] Summary of WG status

From: "brian m. carlson" <[email-masked]>
Date: Thu, 10 Aug 2017 01:47:51 +0000

On Wed, Jul 12, 2017 at 10:38:52PM +0000, brian m. carlson wrote:
> Our charter includes several goals that we should accomplish.  I'm going
> to summarize where we are with each of them so we can see where we need
> to make progress.
> 
> If you're going to respond to one or more of these, please respond to
> each one in a separate thread so that we can have a logical set of
> discussions.
> 
> CFRG Curves
> -----------
> 
> We've included EdDSA with Curve25519.  I'd suggest including Curve448 as
> an additional option for EdDSA.  That might necessitate including
> SHAKE256 limited to this purpose only.
> 
> Curve25519 is defined for ECDH.  We probably also want to consider
> Curve448.  The work needed for this purpose is probably limited to
> including OIDs for the curve.

While I'm thinking about it, did anyone have any opinions on adding
Curve448 support?  If we decide not to add it now, we could always do an
update in a future RFC if we change our minds later.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Aug 2017 02:27:08 +0000

> If we decide not to add it now, we could always do an

We can't even make progress on the current draft! The WG seems to be in the midst of being shut down; both one of the co-chairs and one of the Security AD's has spoken in favor of this.

---

From: "Robert J. Hansen" <[email-masked]>
Date: Wed, 9 Aug 2017 23:02:47 -0400

> update in a future RFC if we change our minds later.

I am completely against even discussing this right now.  IMO, our #1
item right now is getting SHA-1 removed from the spec as thoroughly as
humanly possible.  The next is justifying the continued existence of the WG.

Everything else -- *everything else* -- is an afterthought.

---

From: [email-masked]
Date: Thu, 10 Aug 2017 11:41:52 -0400

On 8/9/2017 at 11:03 PM, "Robert J. Hansen"  wrote:I am completely
against even discussing this right now.  IMO, our #1
item right now is getting SHA-1 removed from the spec as thoroughly as
humanly possible.  The next is justifying the continued existence of
the WG.

=====

In light  of your recent post, what about deprecating 3DES, or at
least adding a cautionary note and the NIST reference ?
vedaal

---

From: "Robert J. Hansen" <[email-masked]>
Date: Thu, 10 Aug 2017 13:10:07 -0400

>     least adding a cautionary note and the NIST reference ?

3DES has already been pretty thoroughly downgraded in the most recent
draft Werner circulated.  I don't think we can do much more without
incurring substantial breakage with existing RFC4880 applications.

---

From: "brian m. carlson" <[email-masked]>
Date: Fri, 11 Aug 2017 01:01:01 +0000

On Thu, Aug 10, 2017 at 02:27:08AM +0000, Salz, Rich wrote:
> We can't even make progress on the current draft! The WG seems to be
> in the midst of being shut down; both one of the co-chairs and one of
> the Security AD's has spoken in favor of this.

Actually, we have an AEAD scheme and really just need a fingerprint
scheme to have a useful draft.  Until the working group closes, I'm
going to try to get us there.  Your input is of course welcome.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

---

From: "brian m. carlson" <[email-masked]>
Date: Fri, 11 Aug 2017 20:29:24 +0000

> Everything else -- *everything else* -- is an afterthought.

Okay.  Let me offer a fingerprint proposal, then: SHA-256.  Basically,
identical to Werner's proposal, except with the full SHA-256.  That
resolves all the issues over truncation.  SHA-256 is mandatory to
implement.

Opinions or counterproposals?
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

---

From: "Robert J. Hansen" <[email-masked]>
Date: Sat, 12 Aug 2017 11:03:34 -0400

> Opinions or counterproposals?

It's simple, easy to implement, and can be done right now.  I'm in favor.

Months upon months have gone by with us largely twiddling our thumbs
while we talk about the perfect fingerprint format.  Full SHA256 isn't
perfect but it'll do, and we're now at the point where a good it'll-do
solution is the magic bullet we need.

---

From: Derek Atkins <[email-masked]>
Date: Mon, 14 Aug 2017 11:39:09 -0400

> solution is the magic bullet we need.

No objection from me.

-derek

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

---

From: "Robert J. Hansen" <[email-masked]>
Date: Mon, 14 Aug 2017 12:06:45 -0400

> No objection from me.

We've now got three voices in favor.  I say we give objectors until the
end of this week (August 19th, five days hence) to speak up.  If we
don't hear objections, the beginning of next week we say the WG has
reached a consensus on fingerprint format.  At that point we talk with
the RFC sherpa (Werner?) to update the doc.

---

From: Vincent Breitmoser <[email-masked]>
Date: Tue, 15 Aug 2017 15:13:26 +0200

I'm conflicted about this.

Yes, moving away from SHA1 is a good idea. We should do that asap. But I
really dislike that this comes with an increased fingerprint size to 256
bits.

Looking at the use case we are trying to cover here, and the actual
requirements the fingerprint has to fulfill, even the 160 bits we had
before were "super-duper-safe because who knows what might happen"
terrain. And we are going to bolt another 96 bits on top of that.
People are going to read sixty-four hexadecimal characters to one
another to verify their keys.

On the other hand, I can see how the choice of just using SHA2-256 is
attractive for its simplicity, especially in a context where consensus
is hard to find.

 - V

---

From: "Robert J. Hansen" <[email-masked]>
Date: Tue, 15 Aug 2017 09:58:32 -0400

> I'm conflicted about this.

I understand there are downsides to it; however, we're facing an
imminent deadline.  The question isn't whether it's perfect; the
question is whether it's good enough.

I don't want to sound as if I'm trying to pressure you into saying yes
to this -- if you think this is a bad idea, I really hope you'll say so!
 But we *do* need to make a choice.

So -- yes or no?

---

From: Stephen Paul Weber <[email-masked]>
Date: Tue, 15 Aug 2017 11:45:07 -0500

> Yes, moving away from SHA1 is a good idea. We should do that asap. But I really dislike that this comes with an increased fingerprint size to 256 bits.

Wouldn't anything else require truncation, and thus not give us the extra safety we're looking for?

-- 
singpolyma, not a cryptographer

---

From: "Robert J. Hansen" <[email-masked]>
Date: Tue, 15 Aug 2017 13:10:31 -0400

> extra safety we're looking for?

Guys, I hate to be the cat-herder here (especially because nobody's
appointed me to be -- but we clearly need one), but the time for these
questions was *a year ago*.

We have a proposal on the table.  Let's keep the WG discussion focused
on yes or no to the proposal.  Let's not get sidetracked with other
discussions.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Aug 2017 18:35:06 +0000

The last we heard from the co-chairs and AD was that this group was going to be shut down.

Has anyone been in touch with them?

Has anyone volunteered to become a doc editor?

---

From: "Robert J. Hansen" <[email-masked]>
Date: Tue, 15 Aug 2017 14:47:13 -0400

> The last we heard from the co-chairs and AD was that this group was

Unless we can get a revision out, yes.  Did I miss a "no, it's too late,
we're shutting down" follow-up?

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Aug 2017 18:54:43 +0000

I haven’t seen the Werner post here; have I missed it?  What’s the expectation that any PR will actually get merged?

---

From: Vincent Breitmoser <[email-masked]>
Date: Fri, 18 Aug 2017 18:53:11 +0200

> > extra safety we're looking for?

No. The bit size has nothing to do with why we want to replace SHA1.

> on yes or no to the proposal.  Let's not get sidetracked with other

I would agree if this was some "other discussion". But we shouldn't
dismiss a discussion about precisely the proposal on the table. It's not
a very old proposal, and we shouldn't be comfortable going through with
a decision if we can't answer basic questions about why we went with a
particular approach.

>From discussions so far I seem to be alone in my doubts that increasing
the bitsize of the fingerprint even further is a bad idea. Still, I'm
gonna submit a nay to the record here.

 - V

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 18 Aug 2017 14:31:59 -0400

hi there--

> The last we heard from the co-chairs and AD was that this group was

Erstwhile co-chair here.  The OpenPGP WG is being closed due to lack of
progress in the intended charter, sadly.  It's hard to argue with the
facts there; I think we haven't had enough actual implementers to test
each others' code and make progress toward something interoperable that
everyone can live with (i think we might have more opinions than we have
implementers, which makes for more talk than progress, and we haven't
even had all that much talk).

However, my understanding is that the mailing list will not be shut
down, so discussion is still possible (as it was between the last
incarnation of the WG and this one), and if work resumes in a plausible
way, we can ask to spin the charter back up.

I strongly encourage everyone to continue with discussion and
implementation.  OpenPGP is in use today on the global network, and it
needs the crypto refresh that the WG was chartered to do, even if we're
late in getting there.

I understand that Werner is interested in continuing work on the draft.
I do not know whether he will be able to submit further drafts as
draft-ietf-openpgp-4880bis, but the title of the draft one way or the
other shouldn't affect our ability to read, implement, comment on, and
improve it.

If we can get a rough consensus and running, interoperable code on a
concrete proposal, I'm happy to try to turn the gears of the IETF
machinery again to get the formal status back.

Onwards,

          --dkg

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Fri, 18 Aug 2017 20:42:09 +0200

> other shouldn't affect our ability to read, implement, comment on, and

I would at least welcome a draft on the specifics of EdDSA for Ed25519
and ECHD for Curve25519 public keys, similar to RFC6637.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Aquila non capit muscas
The eagle does not hunt flies

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 18 Aug 2017 15:13:32 -0400

> and ECHD for Curve25519 public keys, similar to RFC6637.

i'd hope these will be included in whatever form the 4880bis document
takes, and not as a separate document.

        --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 18 Aug 2017 15:42:12 -0400

On Fri 2017-08-18 18:53:11 +0200, Vincent Breitmoser wrote:

> From discussions so far I seem to be alone in my doubts that
> increasing the bitsize of the fingerprint even further is a bad
> idea. Still, I'm gonna submit a nay to the record here.

<erstwhile chair hat off, mailing list participant hat only>

I've been looking at, and thinking about, fingerprints and other
identifiers a fair amount for the last several years.  I want to make a
couple observations:

 * most people don't see (or need to see) the fingerprint explicitly.
   for those people, this is a machine-readable value, and not something
   to expose.

 * for the minority who do actually want to "check fingerprints",
   fingerprint-matching need not be done by text string comparison
   today.  there are lots of other clever ways people can do this with
   modern machinery, and we don't need to specify those mechanisms here.

 * some cryptosystems already expose full sha256 values to users in
   marginal cases -- modern OpenSSH fingerprints are base64-encoded
   sha256sums, so there's precedent.

 * the difference in size (in terms of transit) between a 200-bit
   truncation and a full 256-bit SHA256 sum is 7 octets.

 * sha256 has had tons of cryptographic analysis.  Truncated sha256 has
   not had as much.  I don't think there's a risk here, but why deviate
   from what's been directly studied?

 * simplicity is good.

So in balance, i think i lean toward the full sha256.  I recognize that
the additional 7 octets is a downside in some extremely tight
circumstances.  But i think the balance comes out in favor of simplicity
and uniformity for implementations.

    --dkg

---

From: Werner Koch <[email-masked]>
Date: Wed, 23 Aug 2017 11:48:56 +0200

> identical to Werner's proposal, except with the full SHA-256.  That

I am a bit surprised that 5 months after the proposal and 6 weeks after
-02 we now get back to the fingerprint thing.  Given the lack of
comments I assumed we agreed on that.

Anyway, to move forward I agree to modify this and remove the
truncation.  I just pushed the commit below.

Salam-Shalom,

   Werner

======
commit b95774fb924743198c228d3b02a2e2263dca751d
Author: Werner Koch <[email-masked]>
Date:   Wed Aug 23 11:46:29 2017 +0200

    Use all 32 octets of a V5 fingerprint.

	Modified   middle.mkd
diff --git a/middle.mkd b/middle.mkd
index ec864c4..65c91a0 100644
--- a/middle.mkd
+++ b/middle.mkd
@@ -1280,11 +1280,11 @@ #### {5.2.3.14} Regular Expression
 
 #### {5.2.3.15} Revocation Key
 
-(1 octet of class, 1 octet of public-key algorithm ID, 20 or 25 octets
+(1 octet of class, 1 octet of public-key algorithm ID, 20 or 32 octets
 of fingerprint)
 
 V4 keys use the full 20 octet fingerprint; V5 keys use the
-leftmost 25 octets of the fingerprint
+full 32 octet fingerprint
 
 Authorizes the specified key to issue revocation signatures for this
 key.  Class octet must have bit 0x80 set.  If the bit 0x40 is set, then
@@ -1636,8 +1636,7 @@ #### Issuer Fingerprint
 64 bits of the fingerprint.
 
 Note that the length N of the fingerprint for a version 4 key is 20
-octets.  For a version 5 key the leftmost 25 octets of the fingerprint
-are used (N=25).
+octets; for a version 5 key N is 32.

 ### {5.2.4} Computing Signatures

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