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