Subject: Final comments on draft-ietf-openpgp-2440bis

From: Sam Hartman <[email-masked]>
Date: Thu, 28 Sep 2006 20:40:48 -0400

Hi.

Previously I had passed along two comments on the openpgp spec to the chair:

* Concerns about the MDC

* A desire for an IANA section.

I'm evaluating the response to my concerns about the MDC.  It's
definitely true that I did not think through the use of the MDC in
detail, although even after doing so, I'm still uncomfortable.
I'm trying to talk to other security experts and get a second opinion; expect to hear back from me on this issue within a few days.

I'm working the IANA issue with the chair.

I have two minor comments about the security considerations section;
these comments will round out my review of the spec.

1) random oracle is used instead of oracle every time the word oracle
    is used.  An oracle is a construct with special computational
    ability (access to a key, access to extra storage, ability to
    perform long-running operations in one time step) that is useful
    in analysis of computability, complexity or security
    constructions.  A random oracle is an oracle that has a random
    function in it and exposes this function.

2) RFC 1750 is obseleted.  Please update to  4086.

thanks much,

--Sam

From: Sam Hartman <[email-masked]>
To: [email-masked]
Subject: Final comments on draft-ietf-openpgp-2440bis
Date: Thu, 28 Sep 2006 20:40:48 -0400
Sender: [email-masked]

Hi.

Previously I had passed along two comments on the openpgp spec to the chair:

* Concerns about the MDC

* A desire for an IANA section.

I'm evaluating the response to my concerns about the MDC.  It's
definitely true that I did not think through the use of the MDC in
detail, although even after doing so, I'm still uncomfortable.
I'm trying to talk to other security experts and get a second opinion; expect to hear back from me on this issue within a few days.

I'm working the IANA issue with the chair.

I have two minor comments about the security considerations section;
these comments will round out my review of the spec.

1) random oracle is used instead of oracle every time the word oracle
    is used.  An oracle is a construct with special computational
    ability (access to a key, access to extra storage, ability to
    perform long-running operations in one time step) that is useful
    in analysis of computability, complexity or security
    constructions.  A random oracle is an oracle that has a random
    function in it and exposes this function.

2) RFC 1750 is obseleted.  Please update to  4086.

thanks much,

--Sam

Date: Fri, 22 Sep 2006 15:41:04 +0300
From: "Marko Kreen" <[email-masked]>
To: "Werner Koch" <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
Cc: "Anton Stiglic" <[email-masked]>, "Daniel A. Nagy" <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 9/20/06, Werner Koch <[email-masked]> wrote:
> On Wed, 20 Sep 2006 13:40, Anton Stiglic said:
> > NIST is planning to phase out SHA-1 by 2010, they are going with SHA-224,
> > SHA-256, SHA-384 and SHA-512.
> > http://csrc.nist.gov/hash_standards_comments.pdf
> >
> > In Canada, CSE will phase out SHA-1 for protected C information by 2008.
>
> A note to describe why we use SHA-1 with the MDC would really be
> appropriate.  We are not using it for authentication but to detect
> manipulation of data.  This is commonly known as a checksum.  Thus,
> the acronym MDC and not MAC.  To me detection and authentication have
> different semantics.
>
> It has been said a few times: The MDC is not what we need to care
> about when thinking of SHA-1 vulnerabilities.  There are other usages
> of SHA-1 we need to rethink.

And that reasoning should be in 2440bis.

I think it's too early to get excited about politics.  The issue is
much simpler - non-experts are in no position to 'evaluate' OpenPGP's
use of SHA-1, they depend on the opinion on experts whether an algorithm
is generally secure.

So if 2440bis wants to appear secure by today's standards (for
general public), it needs to either use generally known safe algorithms
or explicitly document that the weaknesses in older algorithms it uses
are taken account of.

-- 
marko

To: [email-masked]
Path: not-for-mail
From: Lutz Donnerhacke <[email-masked]>
Newsgroups: iks.lists.ietf-open-pgp
Subject: Re: [Sam Hartman] Openpgp comments
Date: Wed, 20 Sep 2006 13:58:06 +0000 (UTC)
Organization: IKS GmbH Jena
Lines: 9
NNTP-Posting-Host: belenus.iks-jena.de
NNTP-Posting-Date: Wed, 20 Sep 2006 13:58:06 +0000 (UTC)
Sender: [email-masked]

* Werner Koch wrote:
> I have not heard about any plans to switch to SHA-2.  At least Germany
> is still using RIPME-MD160 out of fear that SHA-1 has been developed
> in the U.S.  I don't think that this algorithm is any better than
> SHA-1 but some people decided in the past to use an European algorithm
> (another layer 9 issue).

With respect to the (not so) recent attacks of hash functions, RIPEMD is a
better choice then just another SHA variant.

From: Werner Koch <[email-masked]>
To: "Anton Stiglic" <[email-masked]>
Cc: "'Daniel A. Nagy'" <[email-masked]>, "'OpenPGP'" <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 20 Sep 2006 14:46:29 +0200
Sender: [email-masked]

On Wed, 20 Sep 2006 13:40, Anton Stiglic said:

> NIST is planning to phase out SHA-1 by 2010, they are going with SHA-224,
> SHA-256, SHA-384 and SHA-512.  
> http://csrc.nist.gov/hash_standards_comments.pdf
>
> In Canada, CSE will phase out SHA-1 for protected C information by 2008.

A note to describe why we use SHA-1 with the MDC would really be
appropriate.  We are not using it for authentication but to detect
manipulation of data.  This is commonly known as a checksum.  Thus,
the acronym MDC and not MAC.  To me detection and authentication have
different semantics.

It has been said a few times: The MDC is not what we need to care
about when thinking of SHA-1 vulnerabilities.  There are other usages
of SHA-1 we need to rethink.

Over the last 8 years since rfc2440 we have talked several times about
things we want to address in the future.  There is actually a long
list.  We can't keep important OpenPGP features - which address actual
vulnerabilities - any longer in an I-D state just for the sake of
getting rid of SHA-1 now.  We need time to address all these items
properly and not do some ad-hoc solutions.  In the meantime 2440bis
needs to get out.  Whether with or without an MDCv2 political option, I
don't care.

> I don't know what is going on in Europe and the rest of the world, but I
> would be surprised if they were going with SHA-1 in the long term.
> You cannot ignore these decisions if you want openpgp to be successful.

I have not heard about any plans to switch to SHA-2.  At least Germany
is still using RIPME-MD160 out of fear that SHA-1 has been developed
in the U.S.  I don't think that this algorithm is any better than
SHA-1 but some people decided in the past to use an European algorithm
(another layer 9 issue).

Salam-Shalom,

   Werner

From: "Anton Stiglic" <[email-masked]>
To: "'Daniel A. Nagy'" <[email-masked]>, "'OpenPGP'" <[email-masked]>
Subject: RE: [Sam Hartman] Openpgp comments
Date: Wed, 20 Sep 2006 07:40:35 -0400
Sender: [email-masked]

NIST is planning to phase out SHA-1 by 2010, they are going with SHA-224,
SHA-256, SHA-384 and SHA-512.  
http://csrc.nist.gov/hash_standards_comments.pdf

In Canada, CSE will phase out SHA-1 for protected C information by 2008.

I don't know what is going on in Europe and the rest of the world, but I
would be surprised if they were going with SHA-1 in the long term.
You cannot ignore these decisions if you want openpgp to be successful.

--Anton

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Daniel A. Nagy
Sent: September 19, 2006 6:13 PM
To: OpenPGP
Subject: Re: [Sam Hartman] Openpgp comments

On Tue, Sep 19, 2006 at 06:55:32PM -0400, David Shaw wrote:

> I'm not against a SHA-256 or 512 based MDC.

This would make encryption/decryption measurably slower, for no benefit
whatsoever. SHA1 provides a comfortable security margin even taking all
recent developments into consideration.

-- 
Daniel

Date: Wed, 20 Sep 2006 01:13:13 +0200
To: OpenPGP <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

--SUOF0GtieIMvvwua
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 19, 2006 at 06:55:32PM -0400, David Shaw wrote:

> I'm not against a SHA-256 or 512 based MDC.

This would make encryption/decryption measurably slower, for no benefit
whatsoever. SHA1 provides a comfortable security margin even taking all
recent developments into consideration.

--=20
Daniel

--SUOF0GtieIMvvwua
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--SUOF0GtieIMvvwua--

Date: Tue, 19 Sep 2006 18:55:32 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Tue, Sep 19, 2006 at 08:55:08PM +0200, Ian G wrote:

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

I know you're not serious, but if anyone wants to discard "security,
common sense, and all that", then they should really just be silent.

I'm not against a SHA-256 or 512 based MDC.  I'm just noting that this
issue seems to be a misunderstanding between this WG and the ADs, and
it might be nice to know what is going on and ensure we understand
what the objection is before we change the design.

Sam Hartman offered to speak on the phone.  I'd be happy to make that
call, though Jon Callas or Hal Finney would probably be a better
choice.  All I ask for is a 10 minute phone call.  We've already spent
many times that in this discussion.

David

Date: Wed, 20 Sep 2006 00:45:38 +0200
To: [email-masked]
Subject: Re: [Sam Hartman] Openpgp comments
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

--liOOAslEiF7prFVr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Sep 18, 2006 at 10:33:32PM -0400, David Shaw wrote:
>=20
> On Mon, Sep 18, 2006 at 11:02:44AM -0400, Derek Atkins wrote:
>=20
> > 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.
>=20
> 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.

I have just discussed this issue with my students at our cryptography
seminar. The general consensus is that MDCs do not need collision
resistance. Thus, SHA1 is secure with a huge security margin. The recent
weakening of SHA1 means that finding a pre-image takes approx 2^138
attempts, which is still comfortably beyond reach for today's and tomorrow's
technology. Introducing longer hashes would make it slower, while not
improving security. If you insist, I can provide the complete reasoning why
collision-resistance is not required for MDC.

 If anything, I would consider RIPEMD128, as it is faster than SHA1 and
offers about the same level of security while being a bit shorter. But
then again, there's no reason to mess with the standard as it is.

--=20
Daniel

--liOOAslEiF7prFVr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--liOOAslEiF7prFVr--

From: Jon Callas <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
Date: Tue, 19 Sep 2006 14:45:57 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

I agree with Ian. Remember those t-shirts they used to sell with the  
nine-layer ISO model? Layer 8 is the Financial Layer and Layer 9 is  
the Political Layer. There's an arrow pointing to Layer 9 with the  
message, "You are here."

I think it's worthwhile to have a phone call or perhaps even better a  
Jabber meeting. I'm in other working groups that do semi-regular  
Jabber conferences. A major reason for a Jabber conference is that it  
is my perception that it is the consensus of this working group that  
we disagree with the ADs. I think they need to talk to the working  
group as a whole. Jabber would be great for that.

On the other hand, we're at the political layer, and I'm happy to put  
in a SHA-256 MDC, if that will get us done. Furthermore, it may turn  
out that in five years we'll be happy we did. Heck, it could always  
turn out that SHA-1 isn't one-way enough. OpenPGP has always been  
forward-thinking, and we are known for being more on top of these  
issues than anyone else. Consequently, if we put in a new MDC and say  
that you MAY do it, the implementers don't have to do it until they  
are in the mood. Even if we say SHOULD accept and MAY generate, it's  
a small burden.

I think that coming up with a true replacement for the MDC is work we  
ought to do. It's on my list of things to do post-2440bis. I think  
this gets in the way of that, but if that's what it takes us to  
finish, it's what it takes us to finish.

	Jon

Date: Tue, 19 Sep 2006 20:55:08 +0200
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: OpenPGP <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
Sender: [email-masked]

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

Date: Tue, 19 Sep 2006 10:40:37 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

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

From: Werner Koch <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 19 Sep 2006 15:33:30 +0200
Sender: [email-masked]

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

Date: Tue, 19 Sep 2006 08:19:14 -0400
From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
Mail-Followup-To: OpenPGP <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

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

From: Werner Koch <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 19 Sep 2006 10:44:30 +0200
Sender: [email-masked]

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

Date: Tue, 19 Sep 2006 10:46:37 +0200
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
Sender: [email-masked]

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

Date: Tue, 19 Sep 2006 10:19:25 +0200
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Subject: Re: [Sam Hartman] Openpgp comments
Sender: [email-masked]

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

Date: Mon, 18 Sep 2006 22:33:32 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: [Sam Hartman] Openpgp comments
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

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

From: Jon Callas <[email-masked]>
Subject: Re: [Sam Hartman] Openpgp comments
Date: Mon, 18 Sep 2006 17:39:14 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

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

To: [email-masked], [email-masked]
Subject: Re: [Sam Hartman] Openpgp comments
Date: Mon, 18 Sep 2006 12:43:08 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Derek forwards from Sam Hartman of IETF:
> 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....

It sounds like we can use some boilerplate language here without much
difficulty.

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

This is a major setback.  It took years to get this change in place, the
whole issue of compatibility and installed base of software that doesn't
recognize the new packet formats.  I wonder if we could add a new set of
MDC packets as the "upgrade path" while retaining the old ones.  Then we
can gradually switch over to using the new ones over the next few years.
In that case we could change the draft expeditiously without commiting to
an immediate changeover in fielded implementations.

If we do pursue this, given the subsequent cryptographic progress since we
designed the MDC mechanism, we should probably look at the now-standard
mechanism of doing a keyed MAC over the ciphertext, rather than using
an encrypted hash of the plaintext.  The MAC could be HMAC with a hash
algorithm specifier for future upgrade.  The paper that first analyzed
this construction is: http://www-cse.ucsd.edu/~mihir/papers/oem.html .
It uses CBC mode, however the proof probably goes through for CFB mode
as well - the modes have similar security properties.

Hal Finney

From: Derek Atkins <[email-masked]>
To: [email-masked]
Subject: [Sam Hartman] Openpgp comments
Date: Mon, 18 Sep 2006 11:02:44 -0400
Sender: [email-masked]

--=-=-=

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

--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

From: Sam Hartman <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: [email-masked]
Subject: Openpgp comments
Date: Mon, 18 Sep 2006 10:33:27 -0400
Lines: 39
MIME-Version: 1.0

 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
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

--=-=-=--