Re: [Sam Hartman] Openpgp comments

Ian G <> Tue, 19 September 2006 09:33 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GPbyd-0000dv-QC for; Tue, 19 Sep 2006 05:33:15 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1GPbyc-0005fw-C2 for; Tue, 19 Sep 2006 05:33:15 -0400
Received: from (localhost []) by (8.13.5/8.13.5) with ESMTP id k8J8kbu3034956; Tue, 19 Sep 2006 01:46:37 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.13.5/8.13.5/Submit) id k8J8kbkV034955; Tue, 19 Sep 2006 01:46:37 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ([]) by (8.13.5/8.13.5) with ESMTP id k8J8kaPp034947 for <>; Tue, 19 Sep 2006 01:46:37 -0700 (MST) (envelope-from
Received: from [IPv6:::1] (localhost []) by (Postfix) with ESMTP id 877255D1DA; Tue, 19 Sep 2006 09:46:30 +0100 (BST)
Message-ID: <>
Date: Tue, 19 Sep 2006 10:46:37 +0200
From: Ian G <>
User-Agent: Thunderbird 1.5 (X11/20060317)
MIME-Version: 1.0
To: Jon Callas <>
Cc: OpenPGP <>
Subject: Re: [Sam Hartman] Openpgp comments
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632

Jon Callas wrote:
> 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.

(In the absence of any contention, I'd vote YES
without trying to figure this one out.)

(Fine analysis snipped.)

> 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.

(Concur with putting in the note;  indeed it might
be useful for historical purposes -- "why did they
bother with that??" -- to put in a note to effect
that the v2/v3 was added at request.)

> 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.

( Minor quibble.  What is left is the implementation
and testing time.  That's non-trivial, every new
feature is only a few hours to code and days and days
of kerfuffle getting everyone else on the same page
and dealing with the diverging versions.

If we were minded to do security rather than finish
the damned document, then a stiffly worded complaint
to the IESG about complexity and featurism would be
in order. )

> 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.

MDC V2 would be SHOULD, and MDC V3 would be MAY?

No, backtrack that.  You decide, I'll vote yes
whichever :)

> 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.

You mean here, *conceptually* this is an abuse as
versions should improve in time and older ones
should be deprecated?  And here you are proposing
to put in two versions at the same time?

I see no difficulty here -- it's what the flexibility
of versions is built for, dealing with unforeseen
circumstances.  They aren't always regular.

> 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.

I agree, do it.  If there is a neat and easy solution,
then put it in.