Openpgp comments

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.

-derek


 Hi.  I'm sorry it has taken so long but I needed to spin
up to speed
 on openpgp standards, read the old 2440, read the new doc,
understand
 some of the political history and then talk to Russ.

I'm Basically done with the new doc.  I want to work
through the
description of PGP CFB mode, but that's all I have left.

However Russ and I have two large issues that we need fixed
before I can bring the document to the IESG.

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


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.


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.






-- 
       Derek Atkins                 617-623-3745
       derekihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

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

On Mon, Sep 18, 2006 at 11:02:44AM -0400, Derek Atkins
wrote:

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

Does the MDC actually need collision resistance?  I was
under the
impression that (like the secret key "S2K 254"
use of SHA-1) this was
essentially a checksum and the recent attacks against SHA-1
did not
apply.

David

David Shaw wrote:
> On Mon, Sep 18, 2006 at 11:02:44AM -0400, Derek Atkins
wrote:
> 
>> 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.
> 
> Does the MDC actually need collision resistance?  I was
under the
> impression that (like the secret key "S2K
254" use of SHA-1) this was
> essentially a checksum and the recent attacks against
SHA-1 did not
> apply.


Yes, that was my question too.

iang

On Tue, 19 Sep 2006 02:39, Jon Callas said:

> 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

I concur with your reasoning to stay with SHA-1 and to allow
(MAY) for
a v2 MDC packet using SHA-256.  If you have some text to
explain for
what we use the MDC it would be good to see it in the
security notes.


Shalom-Salam,

   Werner

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

On Mon, Sep 18, 2006 at 05:39:14PM -0700, Jon Callas wrote:

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

What troubles me is that this is attempting to fix a
perceived problem
that isn't really a problem.  Fixing perceived problems is
sometimes
harder than fixing real ones.  For example, if the mere use
of SHA-1
is the problem, there are also a number of other places
where SHA-1 is
hardcoded (which aren't a problem either) that aren't
"resolved" by
this.

It will take a very long time (at least a year, if not
longer) before
a MDC2 and MDC3 are widely supported, and until then we run
the risk
of interoperability problems.  It probably won't be as bad
as some of
the interoperability problems in the past as the preferences
and
feature flags are more widely implemented now, but it's
still a change
with the usual risks of change.

I suggest we at least push back a little bit, and send your
excellent
explanation of the issue to the appropriate people at the
IESG.  After
that, if they still want a hash upgrade, I will not object.

David

On Tue, 19 Sep 2006 14:19, David Shaw said:

> It will take a very long time (at least a year, if not
longer) before
> a MDC2 and MDC3 are widely supported, and until then we
run the risk

Given all the communication problems we had in the past with
other
cryptographers on the use of the MDC, it might indeed be
easier to
just add an MDCv2 as a MAY or SHOULD.

Even if we would flag an MDCv2 as a SHOULD feature, we as
implementors
may still decide not to use it for a good reason (e.g.
performance).
However the IESG rules are satisfied 

The more interesting question is what we are going to do
about the
SHA-1 requirement for a fingerprint and things like
designated
revokers - this is a more troublesome use of SHA-1. Oh,
sorry, I was
just thinking loudly.


Salam-Shalom,

   Werner

On Tue, Sep 19, 2006 at 03:33:30PM +0200, Werner Koch wrote:

> The more interesting question is what we are going to
do about the
> SHA-1 requirement for a fingerprint and things like
designated
> revokers - this is a more troublesome use of SHA-1. Oh,
sorry, I was
> just thinking loudly.

This is exactly my point.  If we reopen the SHA-1 issue for
the MDC,
what stops someone from wanting a change in fingerprints or
the secret
key protection format, or the "hash of last
resort" or any of the
other hardcoded uses of SHA-1 in the standard?

The request to remove SHA-1 from the MDC seems to be just a
misunderstanding.  It's worth an email to try and resolve
the
misunderstanding before we get into design, much less code,
changes.

A simple email to resolve a misunderstanding seems like the
easiest
"fix" here.  If that doesn't work, or it turns
out not to be a
misunderstanding, then we can go on and do the design
changes, no harm
done.

David

David Shaw wrote:
> On Tue, Sep 19, 2006 at 03:33:30PM +0200, Werner Koch
wrote:
> 
>> The more interesting question is what we are going
to do about the
>> SHA-1 requirement for a fingerprint and things like
designated
>> revokers - this is a more troublesome use of SHA-1.
Oh, sorry, I was
>> just thinking loudly.
> 
> This is exactly my point.  If we reopen the SHA-1 issue
for the MDC,
> what stops someone from wanting a change in
fingerprints or the secret
> key protection format, or the "hash of last
resort" or any of the
> other hardcoded uses of SHA-1 in the standard?


Yes.  But at the end of the day, regardless of
whether we leave the doc as it is, or fix the MDC,
or fix the above things, I'd suggest that the
difference is the same:  minimal.

That is, a far better result is getting the doc
finished and out the door ... partly because this
appears to be a "herding" change of no great
security impact, and partly so we can start on
an updated / rewired / rewritten / reviewed doc.

To my mind, then, it comes down to an optimisation
problem in determining how to get the doc out the
door.  Security, common sense, and all that are
out the window.


> The request to remove SHA-1 from the MDC seems to be
just a
> misunderstanding.  It's worth an email to try and
resolve the
> misunderstanding before we get into design, much less
code, changes.


If you are confident of that, perhaps have a shot
at drafting that email?  As "plan B."

This might leave Jon free to concentrate on the
"plan A" approach of adding MDC-v2,3.

(Just a thought ... I'm not clear enough on the
minutia to be confident enough to draft the email,
myself.)

> A simple email to resolve a misunderstanding seems like
the easiest
> "fix" here.  If that doesn't work, or it
turns out not to be a
> misunderstanding, then we can go on and do the design
changes, no harm
> done.

Perhaps the phone conference as suggested?  I
can see how that might get a result more quickly,
as it allows misunderstandings to be cleared up
more easily than an email cycle.

Just throwing ideas around, here.  Feel free to
ignore.

iang