Re: [Sam Hartman] Openpgp comments

[Jon Callas <[e-mail]>]

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