Subject: Re: meeting in San Francisco?

From: Rodney Thayer <[email-masked]>
Date: Wed, 05 Mar 2003 16:29:28 -0800

At 03:28 PM 2/19/2003 -0500, Derek Atkins wrote:
 >Rodney Thayer <[email-masked]> writes:
 >
 >> Is there a meeting planned in San Francisco?  Is there an agenda?
 >> Is there a call for an agenda?  Is there interest in a meeting?
 >
 >I dont know.  No.  There should be.  Good question..
 >
 >Feedback?

A cypherpunks meeting is a separate topic, I was talking about an IETF
WG meeting.  So I'm not ignoring that.

Things I think we should discuss:

- draft 07bis or 08 or whatever it's at (Jon?  does this make sense?)

- the key server protocol activity that the keyserver-folks and Peter Gutmann
have been discussing.  I think I'm in the midst of volunteering to do a short
presentation on that, so I would like to ask for a 15 minute slot

- ben laurie's perfect forward secrecy draft.  which he kept trying to bring
up as a discussion topic.  I'm not claiming it's perfect or anything but I 
think
we should at least discuss it.  I'm sure we can rope someone into doing
a short presentation on this.

- deprecating pgp 2 keys.  I don't happen to like the idea myself, but lots of
people (Len?) have strong opinions about this and therefore I think the WG 
should
discuss it, at least a little bit, at least to form a "wg opinion".

---

From: Derek Atkins <[email-masked]>
Date: 05 Mar 2003 20:27:08 -0500

Well, at this point is it too late to get a meeting slot in SF.  Sorry.

-derek

Rodney Thayer <[email-masked]> writes:

> up as a discussion topic.  I'm not claiming it's perfect or anything
> but I think
> people (Len?) have strong opinions about this and therefore I think
> the WG should

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

---

From: Jon Callas <[email-masked]>
Date: Wed, 05 Mar 2003 18:07:28 -0800

> - draft 07bis or 08 or whatever it's at (Jon?  does this make sense?)

Bis-07 was sent to the editor last weekend.

> discuss it, at least a little bit, at least to form a "wg opinion".

IETF discussions are open to anyone who wants to discuss them, really.

All three of those things are reasonable to discuss, and so the relevant
persons should discuss them.

Lots of people say to me "The WG should discuss X." My standard response is,
"What a good idea, bring it up." Very few people do that. It is my opinion
that someone who is unwilling to commit to a few email messages doesn't
*really* want to discuss it, they want to complain about how the WG doesn't
want to do their cool thing. That's fine, too. I sometimes like to go off on
how if I were King, the world would be so much better, too.

There's nothing that stops Ben's PFS draft from becoming an informational
RFC. There's little that stops that from becoming standards track -- this
group merely has to agree that it's in our domain. Obviously, it'd be
optional, but.

The easiest of all (assuming that there's WG agreement) is deprecating old
keys. Get rough consensus, and it's about a half-hour work from me.

    Jon

---

From: David Shaw <[email-masked]>
Date: Wed, 5 Mar 2003 22:14:29 -0500

On Wed, Mar 05, 2003 at 06:07:28PM -0800, Jon Callas wrote:

> There's nothing that stops Ben's PFS draft from becoming an
> informational RFC. There's little that stops that from becoming
> standards track -- this group merely has to agree that it's in our
> domain. Obviously, it'd be optional, but.

Speaking of domains - I have documented the HTTP keyserver protocol
with a few extensions to handle some things that were not needed back
when the protocol was created.  I was planning on pushing it towards
an informational RFC, but if the folks here think it would be better
as standards track, then I can certainly do that.

David

---

From: David Shaw <[email-masked]>
Date: Wed, 5 Mar 2003 22:26:04 -0500

On Wed, Mar 05, 2003 at 06:07:28PM -0800, Jon Callas wrote:

> The easiest of all (assuming that there's WG agreement) is
> deprecating old keys. Get rough consensus, and it's about a
> half-hour work from me.

While I have frequently complained to myself about some odd corner
case involving v3 keys, and life would undoubtedly be simpler without
them, I do wonder what practical difference deprecating v3 keys would
have.

GnuPG already refuses to generate new v3 keys, and PGP asks the user
to reconsider before making one.  I doubt any OpenPGP program could
stop supporting existing v3 keys any time soon.  Last I looked, over
90% of the keys on the public keyservers were v4.  I think the natural
evolution of OpenPGP has already deprecated v3 keys for us..

David

---

From: Werner Koch <[email-masked]>
Date: Thu, 06 Mar 2003 11:10:25 +0100

> discuss it, at least a little bit, at least to form a "wg opinion".

I don't think that it is really required to deprecate v3 keys.  Almost
all applications do create v4 keys and it should be up to the
implementor to support them or not.  There are still enough v3 keys
alive so that implementors must still handle keyIDs and fingerprints
separately.

The real problem is the continued use of IDEA, especially to protect
secret keys.  A strong word that the use of IDEA is deprecated would
be helpful.

Shalom-Salam,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Thu, 06 Mar 2003 14:37:08 -0800

> secret keys.  A strong word that the use of IDEA is deprecated would

It is my opinion that deprecating IDEA (which I would be happy to do) is
about the same as deprecating V3 keys.

The reason I say that is that the only reason for a V3 key is to
interoperate with PGP 2.6. PGP 2.6 has only IDEA.

Deprecating IDEA deprecates PGP 2.6, and that makes V3 keys unnecessary.

Personally, I'd love to deprecate PGP 2.6. Almost all the interoperability
problems we have revolve around it.

    Jon

---

From: Len Sassaman <[email-masked]>
Date: Thu, 6 Mar 2003 14:42:13 -0800 (PST)

> about the same as deprecating V3 keys.

Agreed.

> problems we have revolve around it.

I fully agree with Jon. As long as v3 is in the spec, expect to see new
implementations including it. There needs to be very strong language in
the spec that says v3 should not be implemented any further. Or, remove it
from the spec entirely and make it its own document.

I think it was a mistake from the start to offer v3 - v4 interoperability.
It's now time to kill v3 and eliminate a large body of interop problems.

---

From: Derek Atkins <[email-masked]>
Date: 06 Mar 2003 17:47:23 -0500

Hey, I still use a v3 key...  And I have a LOT of mail encrypted with
it.  I would highly object to taking compat out of the spec.

Adding verbiage to the extent of "you MUST NOT generate a v3 key" is
fine with me, however implementation SHOULD (if not MUST) be able to
parse a v3 key.

-derek

---

From: Len Sassaman <[email-masked]>
Date: Thu, 6 Mar 2003 14:54:28 -0800 (PST)

> it.  I would highly object to taking compat out of the spec.

Then use an implementation that speaks both RFC 1991 and OpenPGP. Don't
add cruft into OpenPGP because you have an emotional attachment to a dead
key format.

> fine with me, however implementation SHOULD (if not MUST) be able to

All of this is beside the point. "PGP Desktop", or whatever it is being
called today, could implement both RFC 1991 support, and OpenPGP support,
and not violate OpenPGP even if v3 keys weren't in the spec. It's just
doing two different protocols. (Just like OpenPGP says nothing about disk
encryption, but it's in PGP Desktop.)

The only thing that would have to change, functionally, is that people may
have to start encrypting messages twice if they are to a large number of
users: once for the people with v3 keys, and once for the people with v4
keys. Unfortunately, that is the state of the world now in some cases,
where IDEA is the cipher for v3, and 3DES is the cipher for v4. Not to
mention the v3 interop bugs in GnuPG, which, while resolved now, still
linger in old versions. Better that the protocol not try to handle these
cases, and instead leave it up to the application. (This change could be
implemented invisibly to the user.)

--Len.

---

From: Adam Back <[email-masked]>
Date: Thu, 6 Mar 2003 23:10:59 +0000

I agree, please do not take v3 keys out.

Adam

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 7 Mar 2003 14:45:41 +0100

> Deprecating IDEA deprecates PGP 2.6, and that makes V3 keys unnecessary.

No.  PGP is not just about encryption, there's also signatures (in
particular, certification signatures).

-- 
Bodo Möller <[email-masked]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036

---

From: "Michael Young" <[email-masked]>
Date: Fri, 7 Mar 2003 12:22:09 -0500

From: "Werner Koch" <[email-masked]>
> secret keys.  A strong word that the use of IDEA is deprecated would

My guess is that this is a reaction to IDEA's patent encumberment.
If so, I disagree with Werner.  The spec should certainly point
out the patent issue, but that shouldn't be grounds for deprecation.
Those using v4 keys can express their preference for other
algorithms.  Most v3 key users are stuck with IDEA anyway, so
marking it deprecated won't sway them.

(If Werner's talking about the non-S2K protection of secret
keys, that is already described as deprecated.)

Or, perhaps there has been a recent vulnerability discovered
in IDEA that I've missed.  If so, could someone provide a reference?

From: "Jon Callas" <[email-masked]>
> problems we have revolve around it.

Are you talking about merely marking it deprecated, or are you
contemplating removing some of the PGP2 interoperability
discussion?

Three are lots of v3-based signatures out there.  They're a major
contributor to the "web of trust".  I think it's important to
retain at least the key and signature format material.

The PGP2 handling of symmetric-key message encryption is already
marked as deprecated.

I'd be happy to see more of the PGP2 idiosyncracies moved out of the
mainline into an interoperability section, but I think it would be a
great disservice to drop them entirely.

---

From: Len Sassaman <[email-masked]>
Date: Fri, 7 Mar 2003 11:24:21 -0800 (PST)

> particular, certification signatures).

I do not think the web of trust would be significantly altered if V3 keys
were depricated. (I'd like to see Drew Streib's key analysis run with the
v3 keys excluded to test this theory). More important to the users is
individual trust changes. Perhaps this could be addressed by stating that
key certifications "MAY" but "SHOULD NOT" be v3 format (and reference RFC
1991)? (Am I correct in assuming that v3 as described in OpenPGP is
identical to v3 in 1991?)

I'd also be happy just cutting the v3 web loose.

---

From: Jon Callas <[email-masked]>
Date: Fri, 07 Mar 2003 10:33:39 -0800

> particular, certification signatures).

So we're no longer recommending against MD5? To my mind, MD5 is already a
reason not to use V3.

    Jon

---

From: Werner Koch <[email-masked]>
Date: Fri, 07 Mar 2003 21:50:01 +0100

> My guess is that this is a reaction to IDEA's patent encumberment.

Sure.  Implementing IDEA is trivial but as it is now, it is not
possible to use any software without paying royalities to Ascom.  Also
IDEA is kind of optional in OpenPGP - due to the use of v3 keys it is
practically a must-have. 

I had the same thing in mind as Bodo when I asked for removing IDEA:
There are still a lot of v3 keys with valuable signatures (I have
signed countless v3 keys using my v4 key) it might change the WoT when
we entirely ban v3 keys.  Deprecating IDEA might have the effect, that
only key signatures are to be used.

So, lets ask Drew Streib to run a key analysis with skipped v3 keys
and compare it to the full analysis.

Depending on the result, it would be perfectly okay for me to either
drop v3 or only allow v3 for key signatures.

Salam-Shalom,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Fri, 07 Mar 2003 21:50:01 +0100

Salam-Shalom,

   Werner

---

From: Bodo Moeller <[email-masked]>
Date: Sat, 8 Mar 2003 03:42:28 +0100

> So we're no longer recommending against MD5? To my mind, MD5 is already a

The problem with MD5 is that it might become possible to find
collisions; but it doesn't look as if MD5 were not preimage-safe.

So there's nothing wrong about verifying *old* MD5-based signatures.
It's just not a good idea to generate *new* MD5-based signatures
unless you can be sure that the data to be signed has not specifically
been generated to exploit a collision in MD5.  And RFC 2440 already
warns that

   V3 keys SHOULD only be used for backward compatibility [...]

---

From: Jason Harris <[email-masked]>
Date: Sat, 15 Mar 2003 18:57:14 -0500

> I'd also be happy just cutting the v3 web loose.

A v4-only analysis, otherwise using the same data as the full analysis
for the same date, is at:

  http://keyserver.kjsl.com/~jharris/ka/2003-03-09-v4only/

Summary:  strong and reachable set sizes are reduced by about 50%.

Of 1,829,065 keys, 1,662,070 are v4, ~91%.

-- 
Jason Harris          | NIC:  JH329, PGP:  This _is_ PGP-signed, isn't it?
[email-masked] | web:  http://jharris.cjb.net/

---

From: Werner Koch <[email-masked]>
Date: Sun, 16 Mar 2003 15:51:49 +0100

> Summary:  strong and reachable set sizes are reduced by about 50%.

Frankly, I expected such a result.  So we have a good reason not to
deprecate v3 keys used for key signature.  "an existing v3 key MAY be
used for key certification" sounds reasonable.

Many thanks for running this analyze job, Jason.

Salam-Shalom,

   Werner

---

From: Jon Callas <[email-masked]>
Date: Mon, 17 Mar 2003 01:23:37 -0800

> used for key certification" sounds reasonable.

Again -- I want to say more about what "deprecate" means. It does *not* mean
to get rid of things. It means, in plain words, "Don't do this any more,
because it's going away."

Deprecating V3 keys would mean something like saying that they ought not (I
pick that because I don't want to presume a SHOULD or MUST) be created. One
ought not make any *new* ones.

It could also mean that we would say that existing V3 keys ought not certify
keys -- or that such certifications ought to be V4. There's nothing wrong
with making a V4 signature with a V3 key, don't you know.

I think it is far more significant that 91% of all keys are V4. This tells
me that we can safely deprecate V3.

It is my opinion that any information about "set sizes" is a canard for
several reasons.

* Since no one is saying that deprecating means eliminating said keys, this
is a straw man argument.

* OpenPGP does not specify a trust model, and "reachability" is not even
part of the traditional PGP Web of Trust. Such discussions are
extra-OpenPGP.

* This does not take into account another factor -- that of the "security"
of the keys. This is also one of the things that is beyond OpenPGP and even
any discussion of public key cryptography.

There's a paradox we deal with. On the one hand, the most secure keys are
the new ones. Older keys are more likely to have become compromised. On the
other hand, older keys are the ones that are more connected. They have to
be.

I'll bet that if you look at the most connected V3 keys, you'll find few if
any of them less than a year old. Even less than two years old. An analysis
of "reachability" that does not consider key age at all is flawed, unless
you subscribe to the radical notion that the age of keys doesn't matter.
(Now, to be fair, I have in the past argued this notion myself, but I know
I'm being a radical when I do that.)

However, that's not germane to this discussion. Let me repeat myself.
Deprecating V3 keys does not mean saying existing keys should be immediately
swept away. Eventually, sure. But I'd say that the date at which we should
declare existing V3 keys to be no longer viable should be *after* a
reasonable lifespan of a key.

    Jon

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 17 Mar 2003 11:39:12 +0100

On Mon, Mar 17, 2003 at 01:23:37AM -0800, Jon Callas wrote:

> [...]         Older keys are more likely to have become compromised. [...]

> you subscribe to the radical notion that the age of keys doesn't matter.

So as key expiry does not really work, now we are expiring key data
formats instead? :-)

[I haven't seen any replies to my recent proposal
     http://www.imc.org/ietf-openpgp/mail-archive/msg04950.html
which should finally solve that issue ...]