At 10:19 AM +0200 10/12/99, Werner Koch wrote:
the list is very quite for a long time now. So I want to raise some
issues again which are still unsolved:
I'm starting the task of updating 2440. I need to find an uninterrupted day
or two to do it properly. However, the main thing the working group really
needs to do is get implementations up to 2440-compliance. There's a part of
me that is loathe to rush on with mods to 2440 presently. I'd rather see
2440 become a standard than slow the whole process down by adding features,
as much as I like them, and believe that they're desirable. I would rather
see 2440 go to Standard (or merely replace it with buffing of unclear
places) than see OpenPGP get bogged down in featuritis.
- There is a problem with dash-escaped text
(see my mail from Sep 15th)
I've read through your mail, Werner, and have another suggestion for the
problem.
A summary of the problem is that that 2440 does not cover the case where a
clear-signed message does not end with a CRLF or is of length zero.
My suggestion is this: Don't do that, you'll hurt yourself. Why don't we
just declare that that's bad? If a clear-signed message isn't
CRLF-terminated, add one. This also handles the zero-length case, because
that just becomes a single blank line.
I admit that it never occurred to me that you COULD have a clear-signed
message with no CRLF. This just strikes me as aesthetically bad that the
END header could dangle at the end of a line, and contrary to the intent of
cleartext, if not its stated or implied definition. This seems to me to
hinge on the definition of "canonical text-mode" text, and I always thought
that canonical text-mode text always ended with a line end. Am I wrong on
this?
- What happened to the MDC?
Silently ignoring this issue is not good - we had a lot of
discussion on this topic and some proposals. If we don't
come to a conclusion we should agree on a way to solve it.
Here's what has happened with it: many people seem to believe this is a
good idea. We've settled that out. However, the details of a design have
not been hashed out.
Remaining things to do are:
* One hash algorithm or many? My opinion is one, and that should be SHA-1.
We don't need the full capability of the hash algorithm the way signatures
do. SHA-1 is already required, and the contents of the hash are protected
by the cipher. Additionally, there are a number of subtle complexities that
get added if this is an option. We already have a hash-preferences packet,
but if there is an option on MDC packets, then the sender must not only
find a suitable cipher that the receivers speak, but also a suitable hash
algorithm. There's also the issue of what happens if an attacker attacks
the field that specifies the hash algorithm. I cannot help but believe that
all that will happen is that a lot of code will be executed that ends up
deciding to use SHA-1, the MUST-implement hash. I'll also note that even if
there's an option, the simplest thing for an implementation to do is just
plop down SHA-1 and not even give the user an option. I think I could even
write up an argument for why an implementation SHOULD just use SHA-1. I
think the correct thing to do is just plop 20 bytes of SHA-1 at the end of
the data.
* What cipher mode? I think we all agree that PGP-CFB mode is kinda hokey.
There is nothing wrong with it cryptographically, but no one else uses it.
There's a good argument that we should use standard CFB mode or even CBC
mode. However, I'm going to argue against that:
(1) CBC mode gives no more security than any of the other modes. It adds
complexity to the design, and complexity lowers security. There's a small
lure that possibly a CBC packet could be made to interoperate with S/MIME,
but the S/MIME people aren't interested in interoperating with us. We've
made several overtures to them to work together, and been rebuffed every
time. The last one required only that they change a MUST to a SHOULD on a
certificate specifier, and they refused. I have zero interest in lowering
our security by adding two code paths through the ciphers to interoperate
with people who don't want to interoperate with us. After all, it's in
*their* charter that they need to work with us, not ours.
(2) Regular CFB mode gives no more security than PGP-CFB mode. Adding in
another mode means more code, more things to review, more chances for an
error. If we have only one mode, there's only one thing to check out, and
all implementations are smaller. I'm mildly irked that PGP has to have its
own mode, but that's history. It works, it's secure. Eccentricity is not in
and of itself a bad thing. PGP-CFB mode is not there because the original
designers felt the need to be different, it's there because there was no
consensus at the time on how modes should be implemented, and PGP-CFB mode
has a genuine benefit -- it's easy to tell if you've used the wrong key on
a message, with errors at 2**-16. (And yes, yes, I know this sword has two
edges.)
Consequently, in spite of the fact that I have no particular love for
PGP-CFB mode, I say we just run with it, in the interests of simplicity and
speed.
The best thing to do would be for someone to write a PGP-CFB mode wrapper
that could be applied to a number of ciphers. Ideally, this would be
open-sourced. And no, I don't mean GPLed. I mean true open source, where
anyone could do anything with it.
* We have to design an Optional Features Subpacket. This is a subpacket
that goes in a self-signature that states that the certholder would
understand an MDC message should one be sent to them. It's not really that
big a deal. I see it as a vector of bytes, each denoting a feature. Feature
1 is MDC. Reserve feature FF as a tag, in case (perish the thought) we need
more optional features.
Here's my opinion:
The MDC packet looks exactly like the encrypted data packet, but it has 20
bytes of SHA-1 at the end. I've described the feature subpacket above.
- Other issues like large signature packets, new packet types
(non private ones) that PGP is now using should also be
discussed.
To show that I'm an equal-opportunity ox-gorer in the name of simplicity,
do we need the large signature packet? Do we need it now? My opinion is
that we need it, but not now. It's far more important that we get
implementations to support 2440 than anything else. I'm willing to put it
on the back burner for post-standard revisions of OpenPGP. Does anyone
object?
- There are some open tasks from the last Oslo meeting.
What are they? I know we're supposed to move ourselves along, and come up
with a list of things that an implementation has to do, so we can show we
have at least two interoperable versions. I think we have two that are
close. Tom Zerucha's reference implementation, and GnuPG. The main thing I
can think of for us to do is to show that they implement 2440, and
interoperate.
- Do we have a way to specify private extensions for the S2K
(I am thinking about hardware tokens).
No, we do not. Do we need them? Do you want to suggest an architecture?
Should I issue a plea for simplicity?
Jon