|
Re: [Sam Hartman] Openpgp comments
2006-09-18 18:06:14
On 18 Sep 2006, at 8:02 AM, Derek Atkins wrote:
Forwarded with permission.
It looks like we still have some work to do on rfc2440bis.
Do we need a meeting in San Diego? If so, I need to
request it today.
I don't think you need to request a meeting; if you do, we'll just
get up with a slide that goes over what we say on the list.
The first is the lack of IANA registries. I understand this is left
over from 2440. Back then, the IESG was much more willing to approve
documents without IANA registries. Even in recent times the IESG has
done this--for example, RFC 4120 doesn't have IANA registries created.
It's actually my negative experience with RFC 4120 as well as changes
in IESG membership that cause me to be quite certain that PGP needs
IANA registries for all its parameters. This is doubly true if we're
closing down the working group. You can use standards action as the
registration policy if you are concerned about interactions with the
rest of the spec. Take a look at RFC 2434. The one caution I'd
suggest is that if you use the IESG approval registration policy,
please give the IESG clear guidelines on what we should look for.
"Evaluate using the same criteria as standards actions" is a fine
criteria as is something like "avoid security and interoperability
problems."
I am happy with either using standards action, or IESG handling it
with the same criteria as standards actions. What I perceive to be
the consensus of this working group is that we want that, anyway.
What would the IESG prefer?
I have read RFC 2434, and there isn't boilerplate in it. I can
replace the existing text with a sentence or three that matches this.
I *have* gone and read RFC 4120, the Kerb 5 RFC, to see what they
have in their IANA considerations. I can come up with something
analogous for us.
The second issue is the encryption with integrity packet. Today this
is hard-wired to use SHA-1. That's not OK. We need an upgrade path
for that and I think we need to support SHA-256 now.
Well. I don't see the problem, but let's discuss that in a moment,
because I also have a solution.
I realize both of these issues are large.
I'd be happy to get together with you and the authors on a conference
call if that would be useful.
Neither are really large. They'll take me about an hour each, and the
IANA one is harder, only because I have to guess as to what to say.
Going on to the MDC issue, I want to make a couple comments, and then
propose a change.
The MDC system has as its only requirement on the hash function that
it be one-way. It is similar to an "authenticated cipher" but not
even that, really.
If you want an authenticated message, there is a perfectly good
mechanism in OpenPGP for authenticating a message --- you sign it.
However, there are many times when people do not want to sign
messages, for a large number of reasons. (They don't want the
signature to be taken as a commitment to content; they want the
message to be "deniable;" etc.) Without some sort of integrity
protection, CFB or CBC mode can be modified undetectably. The goal of
the MDC is to be a fancy checksum; checksums like CRC do not have
good characteristics when mixed with cryptography. The MDC does *not*
rely on collision-resistance. The smart way someone attacks a
deniable cryptosystem is to just create a forgery out of whole cloth.
Thus, there really is no need to use anything other than SHA-1 in the
MDC system. The weaknesses in SHA-1 are in qualities that the MDC
does not use. I believe that taking these comments and putting them
in a paragraph in the Security Considerations section is warranted
because people keep misunderstanding the MDC.
Having said that, I don't want to argue. I have a proposal for an
upgrade of the MDC, and frankly, it is going to be less work for me
to put this into 2440bis that it would be to defend not putting it
in. In the interests of just getting this done, here's my proposal
for the WG.
I propose that we create an MDC V2 packet. Formally, this is the
"Sym. Encrypted Integrity Protected Data Packet (Tag 18)" which is in
section 5.13. The V2 packet differs from the V1 packet only in that
it uses SHA-256 instead of SHA-1. Obviously, there has to be a
corresponding change to the "Modification Detection Code Packet (Tag
19)" packet so that it uses the natural length of the hash in the tag
18 packet.
I also propose a V3 packet that uses SHA-512. We might as well do it
now.
The advantage of this solution is that it provides minimal upset to
the current way of doing things. At the protocol level, it's just
like the current system, just with another hash. For implementers,
the same advantage holds. There's no new architectural changes, just
an algorithm change. It also does not require secondary protocol
changes (like having a features bit to announce that you implement
it). A features bit is an advantage, but not necessary. Oh, what the
heck. I'll write in the features bit, too, for completeness.
The only downside that I see of this approach is that it is a very
slight abuse of the version number of the packet. If we only added in
SHA-256, it would be a straightforward upgrade, but putting in V2 and
V3 is a wee bit hokey.
However, one of the items that is on our list of things to do for
post 2440bis is to examine a complete upgrade of symmetric encryption
and use some form of HMAC or authenticated encryption. Just adding in
MDCs with SHA-256 and 512 will give us an answer to the SHA-1 issue
without causing major disruption to the protocol.
So -- my question for the WG: Is this alright with you? I want to get
2440bis done. I think that answers the perception that SHA-1 isn't
good enough, without causing us to do a lot of work. If y'all think
this is good, I'll do it in the next few days.
Jon
|
|