Subject: Split Implementations of PGP

From: Eric Burger <[email-masked]>
Date: Fri, 11 Mar 2005 12:04:59 -0500

Background:
I am a co-chair of the lemonade work group in the IETF
<http://www.ietf.org/html.charters/lemonade-charter.html>.

One thing we would like to do is enable a remote client to fetch the
encrypted session key from an IMAP server, decrypt the key using the
client's key, and then handing back the clear session key to the IMAP server
to decrypt or verify a message or body part.

So, the question is, are there implementations of PGP where one can:
1. Extract the encrypted session key from the PGP-encrypted object
2. An API for handing over the encrypted session key and the client key,
returning the clear session key (this would run on the remote client).
3. An API that takes the clear session key and the PGP-encrypted object and
returns the cleartext object.

Note that this is different from the normal case of an API that takes the
client's key and the PGP-encrypted object and simply returns the cleartext
object.

We have heard from the S/MIME community that there are API's that allow this
functionality over S/MIME.

Thanks.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 11 Mar 2005 16:55:53 +0000

> functionality over S/MIME.

I am currently working on an implementation that could easily include 
this functionality. Feel free to nag me about it.

---

From: Werner Koch <[email-masked]>
Date: Fri, 11 Mar 2005 19:16:49 +0100

> returns the cleartext object.

GnuPG provides this for many years.

    SESSION_KEY  <algo>:<hexdigits>
	The session key used to decrypt the message.  This message will
	only be emitted when the special option --show-session-key
	is used.  The format is suitable to be passed to the option
	--override-session-key

Use it together with --status-fd n.

Shalom-Salam,

   Werner

---

From: David Shaw <[email-masked]>
Date: Fri, 11 Mar 2005 13:32:56 -0500

> client's key and the PGP-encrypted object and simply returns the cleartext

GnuPG can do this.  The feature was originally intended as a
workaround for places that have laws about compelled production of
keys, but it can be used for what you discuss.

David

---

From: Jon Callas <[email-masked]>
Date: Fri, 11 Mar 2005 16:06:21 -0800

We can also do this at PGP Corporation, as well. Not a problem.

	Jon

---

From: Bill Frantz <[email-masked]>
Date: Fri, 11 Mar 2005 17:15:02 -0800

>to decrypt or verify a message or body part.

I understand, from Derek's draft minutes of the OpenPGP meeting, that the problem is that the remote client is in a low-bandwidth environment, such as a cell phone.  I understand this statement to mean that the communication link is low bandwidth.  However, PGP encrypted messages are close to the size of the corrisponding plain text, so I don't see how having an IMAP server decrypt the message is going to help.

If, on another hand, the remote client is limited in CPU power, this system seems to place the largest CPU load, the public key operation to extract the plain text key, on the client, and the relatively low CPU load of the private key operations to decrypt the message on the IMAP server.

I conclude from this reasoning that I don't understand the problem.  Could you please explain.

Thanks - Bill

-----------------------------------------------------------------------
Bill Frantz        | gets() remains as a monument | Periwinkle 
(408)356-8506      | to C's continuing support of | 16345 Englewood Ave
www.pwpconsult.com | buffer overruns.             | Los Gatos, CA 95032

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 11 Mar 2005 22:08:23 -0500

Hi Bill,

--On Friday, March 11, 2005 05:15:02 PM -0800 Bill Frantz 
<[email-masked]> wrote:

> I understand, from Derek's draft minutes of the OpenPGP meeting, that the
> problem is that the remote client is in a low-bandwidth environment, such
> as a cell phone.  I understand this statement to mean that the
> communication link is low bandwidth.  However, PGP encrypted messages are
> close to the size of the corrisponding plain text, so I don't see how
> having an IMAP server decrypt the message is going to help.
>
> If, on another hand, the remote client is limited in CPU power, this
> system seems to place the largest CPU load, the public key operation to
> extract the plain text key, on the client, and the relatively low CPU
> load of the private key operations to decrypt the message on the IMAP
> server.
>

Consider the case of a message with a small text part and a large 
attachment. On your mobile device you might want to only read the text 
without paying the penalty of downloading the attachment. If the message 
data is unencrypted the client can use the IMAP protocol to download only 
the text part. However, if the message is encrypted in one single 
multipart/encrypted part, then the client has to download all the data in 
order to decrypt and extract only the text.

A better solution would be to have the message decrypted on the server and 
stored in its unencrypted form with multiple parts - then the client can 
fetch just the text.

Same principal applies for a message that is only signed, and the mobile 
device wants to read only the text part, but verify the signature.

There are similar considerations for the client when it wants to create a 
signed or encrypted message with parts that already reside on the server.

-- 
Cyrus Daboo

---

From: Bill Frantz <[email-masked]>
Date: Fri, 11 Mar 2005 22:15:01 -0800

On 3/11/05, [email-masked] (Cyrus Daboo) wrote:

>...

Thanks for the clear explanation.  While perhaps out of scope here, I certainly hope that the link between the client and the IMAP server is secured.  The idea of a message that the sender thought needed to be encrypted, being sent out in the clear, over a cell phone transmitter, is a bit disquieting.

Cheers - Bill

---

From: Ingo Luetkebohle <[email-masked]>
Date: Sat, 12 Mar 2005 12:24:50 +0100

> stored in its unencrypted form with multiple parts - then the client can 

Even better would be to have individually encrypted parts.  This is
possible with PGP/MIME but not current practice.  Trouble being, of
course, that the sender would have to know this is in advance.  

It is one more example of the sender having to know what the receiver
requires without a good means of finding out.

So far, these things have been mere nuisances but the suggested solution
is clearly a big step down in security.  I do not know an answer but it
might be interesting to think about the bigger picture for once and come
up with something this simple, yet flexible enough.

In any case, I would suggest for implementors of the server-based
decryption to re-format the message into multiple individually encrypted
parts instead of just storing decrypted messages -- smaller window of
attack.

Ingo

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 12 Mar 2005 09:08:11 -0500

Hi Bill,

--On Friday, March 11, 2005 10:15:01 PM -0800 Bill Frantz 
<[email-masked]> wrote:

> Thanks for the clear explanation.  While perhaps out of scope here, I
> certainly hope that the link between the client and the IMAP server is
> secured.  The idea of a message that the sender thought needed to be
> encrypted, being sent out in the clear, over a cell phone transmitter, is
> a bit disquieting.

Agreed, TLS or mobile equivalent would have to be used. In addition you 
also have to have more trust in your server (or more accurately your server 
admin or whoever has 'root' access to the server) as a clear-text version 
of the message will be stored there, even if only on a temporary basis.

-- 
Cyrus Daboo

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 13 Mar 2005 16:33:52 +1300

>returns the cleartext object.

Why not have the client decrypt the session key, re-encrypt it with the
server's public key, and send it back?  Any version of PGP supports this, and
it solves the difficult problem of "an API for [...] the client returning the
session key".

Peter.

---

From: Jon Callas <[email-masked]>
Date: Tue, 15 Mar 2005 12:12:33 -0800

> course, that the sender would have to know this is in advance.

Better for whom?

One of the reasons that practice is to not have individually encrypted 
parts is that that has not been considered as good, meaning not as 
secure. It isn't as convenient for an entity who doesn't have the keys 
to process such a message, and that's been considered a feature rather 
than a bug.

	Jon

---

From: Ingo Luetkebohle <[email-masked]>
Date: Wed, 16 Mar 2005 00:39:37 +0100

> Better for whom?

Better for a recipient who, for whatever reasons, does not want to
transfer the whole for decryption.

> to process such a message, and that's been considered a feature rather 

I concur -- for the usual case.  However, whats better in the case under
discussion:  Decrypting the full thing on a machine not under your
control and then transferring only what you can afford, or transfer it
(encrypted) and decrypt it on the local machine (mobile device)?  For
this case, I'd say the latter is preferable.  Maybe I'm paranoid about
server security but isn't that why we're using PGP-based end-to-end
encryption?

regards

Ingo

---

From: Ben Laurie <[email-masked]>
Date: Wed, 16 Mar 2005 00:41:04 +0000

> to process such a message, and that's been considered a feature rather 

I'm struggling to understand this - how does this make it any easier for 
an attacker? (Other than log_2(n), where n is the number of parts, for 
the brute force attack).

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Jon Callas <[email-masked]>
Date: Wed, 16 Mar 2005 01:46:37 -0800

Something that would help those of us doing crypto and IMAP would be 
for IMAP to be less fussy about message size.

We have the problem that while SMTP and POP consider size information 
about a message to be advisory, IMAP considers it to be definitive. 
When you have a message that is compressed, encrypted, signed, base64 
encoded, put into quoted-printable, etc., it can be very hard to answer 
the question, "How big is that message?" definitively.

While POP, for example, will accept the answer "Um, around 15K" and 
copes just fine with the real answer being either 3K or 50K, IMAP does 
not. The IMAP client will expect the size reported to be accurate down 
to the byte. If there is more, the client will never ask for it, and if 
there's less, the client hyperventilates and breaks down sobbing.

If there is anything that further work on IMAP, be it Lemonade, or 
anything else does that could help security, it would be to break 
IMAP's prissiness about message length. The main advantage that this 
sesson-key decrypting protocol has is that it exposes the server to 
relatively little of the actual plaintext. However, while this is a 
theoretic benefit, the practical benefit is lessened by the length 
requirements.

Let's suppose I connect to my server and have ten new messages, all of 
which are encrypted, say five with OpenPGP and five with S/MIME. My 
client program is going to display the lengths of the messages, but 
that isn't knowable without decrypting them. So immediately with the 
headers, all ten of those messages have to be decrypted and processed 
so that the lengths will be accurate. This slows the system down, 
because it requires a complete round-trip of session key decryption for 
each message as well as preliminary processing of the message on the 
server. If that client program is a mobile device, this is especially 
bad because the heavy lifting (the public key crypto) is being done on 
the light device, and the easy lifting (the bulk crypto processing) is 
being done on the powerful device. What happens is that this 
architecture maximally slows the email processing down, with relatively 
low security gains, because the server has gotten the session key for 
all ten messages, even though I've read exactly zero of them.

I'd like to see a change to IMAP that allows for the message's length 
to be advisory until it's actually read. It's relatively easy to do -- 
you have to have a way to ask the server simply, "Is there more?" as 
well as the server to be able to return a short (even zero-length) glob 
of message text.

This gives a slightly counter-intuitive display on the client. I might 
look at a list of messages and see that one is 8K long, and when I read 
that message its length updates to 13K. But in return, we'd be able to 
defer the cryptography to when a message is actually read, rather than 
when it enters my inbox.

	Jon

---

From: Ingo Luetkebohle <[email-masked]>
Date: Wed, 16 Mar 2005 14:14:21 +0100

> for IMAP to be less fussy about message size.

[...]

It would be very usefull, for me at least, if you could re-state your
use-case here.  I'm getting the impression that I'm missing something
fundamental.

I'm always reading about server-side decryption.  Some people seem to
see it as a solution for the "one big chunk of ciphertext" problem.  I'm
not sure what else it would be good for.

For me, server-side decryption is a nightmare.  Pure and evil.  

It conflicts with my beliefs about how an end-to-end crypto solution
should work.  Its not a solution, its a kludge and I'd much rather
address the *real* problem.

The server is completely untrusted.  Much too much of my personal data
is on other's servers already.  Organizations or people, who might have
different priorities in protecting it than I have.   Thats why I use
end-to-end encryption when it matters.

If people say, adressing the real problem would require influencing the
senders behaviour, and we can't do that, and so we need a work-around
now -- fine.  I can understand that.  But still, shouldn't that prompt
us to think about wether we *need* to be able to influence the senders
behaviour in more ways than we can now?

P.S. Regarding IMAP and message sizes:  If I get an encrypted message,
the size of the attachment *is* the message size.  That decryption
yields a different size doesn't matter because it occurs on the client,
after download.

Regards

---

From: Lars Eilebrecht <[email-masked]>
Date: Wed, 16 Mar 2005 14:55:59 +0100

> yields a different size doesn't matter because it occurs on the client,

I assume Jon is talking about on-the-fly decryption of incoming
messages, i.e., when the decryption happens before the data hits
the MUA?  A MUA usually includes the size of an 'object' in a
request and only expect that many bytes in the response. However,
the size after decryption is almost always different.
IMHO, this is not directly an issue with IMAP, but with the
actual implementation/interpretation of IMAP. 
The message size handling is just one of the issues with IMAP ...
e.g., think about bodystructure requests and on-the-fly decryption.

But I have to admit that I'm not sure what this has to do with
the original topic of this thread? :-)

ciao...
-- 
Lars Eilebrecht
[email-masked]

---

From: Jon Callas <[email-masked]>
Date: Thu, 17 Mar 2005 01:33:10 -0800

On 15 Mar 2005, at 4:41 PM, Ben Laurie wrote:

>> One of the reasons that practice is to not have individually 
>> encrypted parts is that that has not been considered as good, meaning 
>> not as secure. It isn't as convenient for an entity who doesn't have 
>> the keys to process such a message, and that's been considered a 
>> feature rather than a bug.
>
> I'm struggling to understand this - how does this make it any easier 
> for an attacker? (Other than log_2(n), where n is the number of parts, 
> for the brute force attack).
>

It's a small thing, but if message A has one attachment, 
"Attachment.pgp", and message B has two attachments, "Text.pgp" and 
"ZeSecretPlans.doc.pgp" -- which each decompose to the same mail 
message -- one could argue that message A is more secure than message B 
because it leaks less information about its internal structure.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Thu, 17 Mar 2005 01:42:34 -0800

> e.g., think about bodystructure requests and on-the-fly decryption.

That's precisely what I'm talking about.

However, it is an issue with IMAP itself. IMAP has a core assumption 
that a message has a size that is constant and knowable even when all 
you're getting is the headers. An IMAP server must reply accurately and 
precisely the message size when it first informs the client about the 
message.

If that message needs lots of transformations including decryption, 
this makes determining the precise message size an interesting problem.

> the original topic of this thread? :-)

I'm giving a warning that simply passing session keys around may not 
give obvious solutions to the problem being solved. We've spent a lot 
of time with advanced IMAP features at PGP Corporation. Admittedly, in 
our case, we're building proxies and proxies don't have liberties that 
client-server systems do. If IMAP were less fussy about message size, 
then some of the difficult problems would have obvious solutions.

	Jon

---

From: Ben Laurie <[email-masked]>
Date: Thu, 17 Mar 2005 11:42:32 +0000

Jon Callas wrote:
> "ZeSecretPlans.doc.pgp" -- which each decompose to the same mail message 
> -- one could argue that message A is more secure than message B because 
> it leaks less information about its internal structure.

Are attachment names really not encrypted? If they are (as they should 
be) then the only threat is that an attacker knows the number and 
(compressed) size of the attachments. I find it hard to get excited 
about that.

---

From: "Brian G. Peterson" <[email-masked]>
Date: Thu, 17 Mar 2005 06:44:27 -0600

> (compressed) size of the attachments. I find it hard to get excited

Implementations differ.  I've seen some implementations that split out the 
mime parts that obfuscate the attachment names and others that just add .pgp 
or .asc to the attachment names.

I think that one of the larger issues is that if the mime parts are separate, 
an attacker could remove a single attachment,  effectively changing part of 
the meaning of what the original sender wanted to say by removing part of the 
message.

Regards,

  - Brian

---

From: Ian G <[email-masked]>
Date: Thu, 17 Mar 2005 12:58:39 +0000

> it leaks less information about its internal structure.

Right.  But, given the mobile platform limitations,
Message A is unusable therefore its security argument
is null & void;  the user has to make *some compromise*
in order use the system, and that may well be "giving
up a little security."

I'm curious as to whether there is a hard proposal for
the group behind this?

iang
-- 
News and views on what matters in finance+crypto:
         http://financialcryptography.com/

---

From: Jon Callas <[email-masked]>
Date: Thu, 17 Mar 2005 17:39:08 -0800

On 17 Mar 2005, at 3:42 AM, Ben Laurie wrote:

>> message -- one could argue that message A is more secure than message 
>> B because it leaks less information about its internal structure.
>

No, they're not encrypted. This is part of MIME. The MIME part has a 
file name, and that file name is in the clear. The PGP products do what 
I described in my previous note; we name them AttachmentN.pgp, and 
inside the literal packet is the actual name of the resultant file.

A number of systems do not encrypt the file names, even when they are 
using OpenPGP/MIME.

	Jon

Cc: Ingo Luetkebohle <[email-masked]>, Cyrus Daboo <[email-masked]>, Eric Burger <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Split Implementations of PGP
Date: Thu, 17 Mar 2005 17:39:08 -0800
To: Ben Laurie <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 17 Mar 2005, at 3:42 AM, Ben Laurie wrote:

>> message -- one could argue that message A is more secure than message 
>> B because it leaks less information about its internal structure.
>

No, they're not encrypted. This is part of MIME. The MIME part has a 
file name, and that file name is in the clear. The PGP products do what 
I described in my previous note; we name them AttachmentN.pgp, and 
inside the literal packet is the actual name of the resultant file.

A number of systems do not encrypt the file names, even when they are 
using OpenPGP/MIME.

	Jon

Date: Thu, 17 Mar 2005 12:58:39 +0000
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Jon Callas <[email-masked]>
CC: Ben Laurie <[email-masked]>, [email-masked], Ingo Luetkebohle <[email-masked]>, Cyrus Daboo <[email-masked]>, Eric Burger <[email-masked]>
Subject: Re: Split Implementations of PGP
Sender: [email-masked]

iang

From: "Brian G. Peterson" <[email-masked]>
To: [email-masked]
Subject: Re: Split Implementations of PGP
Date: Thu, 17 Mar 2005 06:44:27 -0600
Sender: [email-masked]

Regards,

  - Brian 

Date: Thu, 17 Mar 2005 11:42:32 +0000
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: [email-masked], Ingo Luetkebohle <[email-masked]>, Cyrus Daboo <[email-masked]>, Eric Burger <[email-masked]>
Subject: Re: Split Implementations of PGP
Sender: [email-masked]

Cc: Ingo Luetkebohle <[email-masked]>, OpenPGP <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Split Implementations of PGP
Date: Thu, 17 Mar 2005 01:42:34 -0800
To: Lars Eilebrecht <[email-masked]>
Sender: [email-masked]

	Jon

Cc: [email-masked], Ingo Luetkebohle <[email-masked]>, Cyrus Daboo <[email-masked]>, Eric Burger <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Split Implementations of PGP
Date: Thu, 17 Mar 2005 01:33:10 -0800
To: Ben Laurie <[email-masked]>
Sender: [email-masked]

	Jon

Date: Thu, 17 Mar 2005 00:42:20 +0100
From: Ingo Luetkebohle <[email-masked]>
Subject: RE: Split Implementations of PGP
To: Eric Burger <[email-masked]>
Cc: OpenPGP <[email-masked]>
Sender: [email-masked]

--=-O4oUR7Rf/6OxWJJ4kibX
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Am Mittwoch, den 16.03.2005, 16:19 -0500 schrieb Eric Burger:
> Note that I *chose* to trust the server FOR THIS MESSAGE ONLY.  That is w=
hy
> we asked the question about split implementations.  It would be VERY BAD =
if
> we had to trust the server with our private key.

I like the selectivity and it appears that, given current PGP/MIME
practice, your suggestion is the best one can do.

I'd like to suggest something in addition to that:  Allow for
*replacement* of the session-key packet, instead of decryption.  Here's
how it would work:

The client receives the encrypted session key from the server, decrypts
it, *immediately recrypts* using the recipients public key and passes
the encrypted session-key back to the server.  The server then proceeds
to *replace* the encrypted session key in the message (without ever
decrypting it!) and forwards it to the intended recipient.  Because the
session key stays the same, the recipient can decrypt it.

When used with separately encrypted attachments, it would enable
forwarding something without ever downloading it, and without the server
ever seeing the decrypted content.  This wouldn't be terribly useful
right now, because all clients encrypt the whole message and I would
have trouble making a forwarding decision without looking at the
content, but when a client ever implements a different PGP/MIME usage,
the combination would be terrific, in my very humble opinion.

There's one possible gotcha:  I don't know about the security
implications of encrypting the same plaintext (here, the session key)
with two different public keys.  I can't think of any problems right
now, but wouldn't exclude the possibility of a leak to occur.  I hope
there's enough cryptographers here to shout in that event, though :)

Ingo

--=-O4oUR7Rf/6OxWJJ4kibX
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

--=-O4oUR7Rf/6OxWJJ4kibX--

From: Eric Burger <[email-masked]>
To: Ingo Luetkebohle <[email-masked]>
Cc: OpenPGP <[email-masked]>
Subject: RE: Split Implementations of PGP
Date: Wed, 16 Mar 2005 16:19:17 -0500
Sender: [email-masked]

Forward without download: I've got a 100MB document and a piece of text
saying, "here is the very important document you need to send to foo".  I
*chose* to trust the server, this time, to decrypt the message for me and
tell me the body structure (a big document and a piece of text).  I download
the text, and I decide to forward the document.  I tell the server to do the
forwarding for me on my behalf.

Note that I *chose* to trust the server FOR THIS MESSAGE ONLY.  That is why
we asked the question about split implementations.  It would be VERY BAD if
we had to trust the server with our private key.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ingo Luetkebohle
> Sent: Wednesday, March 16, 2005 8:14 AM
> To: Jon Callas
> Cc: OpenPGP
> Subject: Re: Split Implementations of PGP
> 
> 
> 

Date: Wed, 16 Mar 2005 14:55:59 +0100
From: Lars Eilebrecht <[email-masked]>
To: Ingo Luetkebohle <[email-masked]>
Cc: Jon Callas <[email-masked]>, OpenPGP <[email-masked]>
Subject: Re: Split Implementations of PGP
Sender: [email-masked]

ciao...
-- 
Lars Eilebrecht
[email-masked]

Subject: Re: Split Implementations of PGP
From: Ingo Luetkebohle <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: OpenPGP <[email-masked]>
Date: Wed, 16 Mar 2005 14:14:21 +0100
Sender: [email-masked]

[...]

Regards

From: Jon Callas <[email-masked]>
Subject: Re: Split Implementations of PGP
Date: Wed, 16 Mar 2005 01:46:37 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

	Jon

Date: Wed, 16 Mar 2005 00:41:04 +0000
From: Ben Laurie <[email-masked]>
To: Jon Callas <[email-masked]>
Cc: Ingo Luetkebohle <[email-masked]>, [email-masked], Cyrus Daboo <[email-masked]>, Eric Burger <[email-masked]>
Subject: Re: Split Implementations of PGP
Sender: [email-masked]

Date: Wed, 16 Mar 2005 00:39:37 +0100
From: Ingo Luetkebohle <[email-masked]>
Subject: Re: Split Implementations of PGP
To: Jon Callas <[email-masked]>
Cc: [email-masked], Cyrus Daboo <[email-masked]>, Eric Burger <[email-masked]>
Sender: [email-masked]

--=-uY1zi1JcW4FR5eDTVwcZ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

> One of the reasons that practice is to not have individually encrypted=20
> parts is that that has not been considered as good, meaning not as=20
> secure. It isn't as convenient for an entity who doesn't have the keys=20
> to process such a message, and that's been considered a feature rather=20
> than a bug.

regards

Ingo

--=-uY1zi1JcW4FR5eDTVwcZ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

--=-uY1zi1JcW4FR5eDTVwcZ--

Cc: [email-masked], Cyrus Daboo <[email-masked]>, Eric Burger <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Split Implementations of PGP
Date: Tue, 15 Mar 2005 12:12:33 -0800
To: Ingo Luetkebohle <[email-masked]>
Sender: [email-masked]

Better for whom?

	Jon

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Split Implementations of PGP
Cc: [email-masked]
Date: Tue, 15 Mar 2005 21:23:44 +1300
Sender: [email-masked]

Eric Burger <[email-masked]> writes:

>The problem is that the client does not want to download the object at all,
>either because they only want to look at a particular body part and the
>entire message is encrypted (Cyrus' example) or they wish to forward the
>message without downloading it to their client.

You don't download it, the server sends out the RSA/Elgamal-encrypted message
encryption key (MEK) from the message (and nothing else) and the client
returns the MEK re-encrypted with the server's public key.  This works with
anything (including for example crypto hardware like smart cards that won't
reveal a key), has minimal messaging overhead, and doesn't require any
additional security measures to protect the MEK.

Peter.

From: Eric Burger <[email-masked]>
To: Ingo Luetkebohle <[email-masked]>
Cc: [email-masked], "Glenn Parsons (E-mail)" <[email-masked]>, "Stephane Maes (E-mail)" <[email-masked]>
Subject: RE: Split Implementations of PGP
Date: Sun, 13 Mar 2005 17:24:16 -0500
Sender: [email-masked]

The problem is we cannot change sender behavior.  If we could, we would
simply say, "Send the message encrypted with both the client's and IMAP
server's key."  That way, the server already would be a recipient.

I do like the idea of being a model of good behavior.  We should put that
into the lemonade profile.

> -----Original Message-----
> From: Ingo Luetkebohle [mailto:[email-masked]]
> Sent: Saturday, March 12, 2005 6:25 AM
> To: Cyrus Daboo
> Cc: [email-masked]; Eric Burger
> Subject: Re: Split Implementations of PGP
> 
> 

From: Eric Burger <[email-masked]>
To: pgut001 <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: Split Implementations of PGP
Date: Sun, 13 Mar 2005 17:24:15 -0500
Sender: [email-masked]

The problem is that the client does not want to download the object at all,
either because they only want to look at a particular body part and the
entire message is encrypted (Cyrus' example) or they wish to forward the
message without downloading it to their client.

> -----Original Message-----
> From: pgut001 [mailto:[email-masked]]
> Sent: Saturday, March 12, 2005 10:34 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Split Implementations of PGP
> 
> 

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Split Implementations of PGP
Cc: [email-masked]
Date: Sun, 13 Mar 2005 16:33:52 +1300
Sender: [email-masked]

Peter.

Date: Sat, 12 Mar 2005 09:08:11 -0500
From: Cyrus Daboo <[email-masked]>
To: Bill Frantz <[email-masked]>
cc: Eric Burger <[email-masked]>, [email-masked], "Glenn Parsons (E-mail)" <[email-masked]>
Subject: Re: Split Implementations of PGP
Sender: [email-masked]

Hi Bill,

-- 
Cyrus Daboo

Date: Sat, 12 Mar 2005 12:24:50 +0100
From: Ingo Luetkebohle <[email-masked]>
Subject: Re: Split Implementations of PGP
To: Cyrus Daboo <[email-masked]>
Cc: [email-masked], Eric Burger <[email-masked]>
Sender: [email-masked]

--=-lwj993Gubp9qj1/CfkJO
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Am Freitag, den 11.03.2005, 22:08 -0500 schrieb Cyrus Daboo:
> A better solution would be to have the message decrypted on the server an=
d=20
> stored in its unencrypted form with multiple parts - then the client can=20
> fetch just the text.

Even better would be to have individually encrypted parts.  This is
possible with PGP/MIME but not current practice.  Trouble being, of
course, that the sender would have to know this is in advance. =20

Ingo

--=-lwj993Gubp9qj1/CfkJO
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

--=-lwj993Gubp9qj1/CfkJO--

Date: Fri, 11 Mar 2005 22:15:01 -0800
From: Bill Frantz <[email-masked]>
Subject: Re: Split Implementations of PGP
To: Cyrus Daboo <[email-masked]>
cc: Eric Burger <[email-masked]>, [email-masked], "Glenn Parsons (E-mail)" <[email-masked]>
Sender: [email-masked]

Cheers - Bill

Date: Fri, 11 Mar 2005 22:08:23 -0500
From: Cyrus Daboo <[email-masked]>
To: Bill Frantz <[email-masked]>, Eric Burger <[email-masked]>
cc: [email-masked], "Glenn Parsons (E-mail)" <[email-masked]>
Subject: Re: Split Implementations of PGP
Sender: [email-masked]

Hi Bill,

-- 
Cyrus Daboo

Date: Fri, 11 Mar 2005 17:15:02 -0800
From: Bill Frantz <[email-masked]>
Subject: Re: Split Implementations of PGP
To: Eric Burger <[email-masked]>
cc: [email-masked], "Glenn Parsons (E-mail)" <[email-masked]>
Sender: [email-masked]

Thanks - Bill

Cc: [email-masked], "Glenn Parsons (E-mail)" <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Split Implementations of PGP
Date: Fri, 11 Mar 2005 16:06:21 -0800
To: Eric Burger <[email-masked]>
Sender: [email-masked]

	Jon

Date: Fri, 11 Mar 2005 13:32:56 -0500
From: David Shaw <[email-masked]>
To: Eric Burger <[email-masked]>
Cc: [email-masked], "Glenn Parsons (E-mail)" <[email-masked]>
Subject: Re: Split Implementations of PGP
Mail-Followup-To: Eric Burger <[email-masked]>, [email-masked], "Glenn Parsons (E-mail)" <[email-masked]>
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

David

To: Eric Burger <[email-masked]>
Cc: [email-masked], "Glenn Parsons (E-mail)" <[email-masked]>
Subject: Re: Split Implementations of PGP
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Fri, 11 Mar 2005 19:16:49 +0100
Sender: [email-masked]

Shalom-Salam,

   Werner

Date: Fri, 11 Mar 2005 16:55:53 +0000
From: Ben Laurie <[email-masked]>
To: Eric Burger <[email-masked]>
Cc: [email-masked], "Glenn Parsons (E-mail)" <[email-masked]>
Subject: Re: Split Implementations of PGP
Sender: [email-masked]

From: Eric Burger <[email-masked]>
To: [email-masked]
Cc: "Glenn Parsons (E-mail)" <[email-masked]>
Subject: Split Implementations of PGP
Date: Fri, 11 Mar 2005 12:04:59 -0500
Sender: [email-masked]

Background:

Thanks.

From: Derek Atkins <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Draft Minutes of OpenPGP Meeting
Date: Thu, 10 Mar 2005 12:10:23 -0500
Sender: [email-masked]

--=-=-=

Here are the draft minutes of the (short) OpenPGP Meeting here in
Minneapolis.

-derek

--=-=-=
Content-Disposition: attachment; filename=ietf-62-minutes.txt
Content-Description: OpenPGP Minutes

Open PGP Minutes

- Chair Derek Atkins
- Tues March 8 2005

1.  Agenda Bashing - none

2.  AD - Sam Hartman - 

Sam requested time on the agenda to discuss a proposed new work item for this working group.  The Lemonade group is looking at doing e-mail type operations in some new service environments.  One type of environment that they are looking at is low bandwidth devices (such as cell phones) where different types of operations might be desirable.  Examples of such operations might be to distill or use incremental download of messages for display on the device. 

Currently the issues of end-to-end security have been avoided by the Lemonade group.  Open PGP and S/MIME are the two different secure messaging work groups in the IETF and the Lemonade group would like to get guidance and help from the two groups about different ways of providing end-to-end security within the lightweight receivers.

One possible method of dealing with the problem is to require that the server be a recipient on the message.  No desirable in some circumstances because the server cannot be trusted.  A second method is to require the device to deal with secure messages.  This is beyond the capabilities of some devices.  The current method under exploration would be to allow the server to extract a correct encrypted key blob, send it to the device for decryption, and then the server would decrypt the bulk message and process it for display.

Glen Parsons (co-chair of the Lemonade group) stated that in addition guidance was desired on some of the security issues the server would need to deal with.  An example would be how long should a server keep the decrypted message in a cache for processing, as oppose to decrypting the message each time a new section of the document was desired by the display device. 

One proposed method of dealing with this might be to look at the device as a cryptographic module and just implement normal PGP on the server.  This would need to be looked at further.

3.  Draft-ietf-openpgp-rfc2440bis status

The document editor did not provide a presentation for the meeting.  There has not been a recent update of the document, however there has been substantial activity on the list recently which has solve several open issues.  The following open issues still remain:

Editorial type changes that will probably just be accepted by the editor
    - V2 PKESK advice is not correct (Dave Shaw)
    - Call V4 V4 (Dave Shaw)

Two cryptographic issues that need to be looked at:

- CFB "Broken" 
  Researches have presented a break of CFB where about 25% of the message can be obtained using a fairly small work load under some circumstances.  Details of the attack can be found at:

- SHA-1 "Broken"
  There have been several recently announced attacks against SHA-1.  The biggest result was one of lowering the work of finding a duplicate hash from 2^80 to 2^69.  Still a substantial work factor.  Sam stood up and said that the issue will be discussed at the SAAG meeting on Thursday, but the current advice from the ADs is not to panic yet.  They are searching for a unified method of dealing with the problem along with the question of whether the new longer SHA algorithms are going to be affected as well.

3.  PFS - Presenter was not present in the room.

--=-=-=

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

--=-=-=--

From: Jon Callas <[email-masked]>
Subject: Re: Tighter MPI spec
Date: Thu, 3 Mar 2005 07:59:28 -0800
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 27 Feb 2005, at 2:21 PM, Florian Weimer wrote:

> * Jon Callas:
>
>> This language has been sitting in 2440 and followons since '97. No one
>> has ever had a problem implementing it, no one has had an
>> interoperability issue with bignums. Not PGP, nor GnuPG, nor Hushmail,
>> nor Cryptix, nor Forum, nor Bouncy Castle, nor anyone else.
>
> Not true.  GnuPG had a bug in MPI handling because it followed the
> language in RFC 2440 too verbatim. 8-)
>
> (You added a hint to 2440bis a few years ago, so others hopefully
> won't make the same mistake.)
>

Thanks. Mea culpa.

However, I think with the explicit note that unused bits must be zero, 
we're real clear on it.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: [ISSUE] Minor language nits
Date: Thu, 3 Mar 2005 07:58:32 -0800
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 25 Feb 2005, at 12:48 PM, David Shaw wrote:

>
> Three minor language nits:
>
> In section 5.2.3. Version 4 Signature Packet Format:
>
>      - Two-octet scalar octet count for following hashed subpacket
>        data. Note that this is the length in octets of all of the
>        hashed subpackets; a pointer incremented by this number will
>        skip over the hashed subpackets.
>
> There needs to be a "the" between "for" and "following".  Note also
> the same problem one paragraph later for the item discussing the
> unhashed subpacket data.
>

Got them.

> =============================
>
> Throughout the document, references to RFCs are written
> inconsistently.  For example, there are 3 references to "RFC 1991"
> (with the space), and 2 references to "RFC1991" (without the space).
> I like it with the space, though I really don't care which way things
> go so long as it is consistent.  (It's not just 1991 - all the RFC
> references in the draft are mixed between the two styles).
>

Okay, here's what I did. All text referring to an RFC is now "RFC xxxx" 
-- with a space. But a reference in brackets such as [RFCxxxx] has no 
space. That just seemed like the right thing.

> =============================
>
> There are a few spots in the draft where "PGP" is used when "OpenPGP"
> should have been used (when referring to the standard, rather than the
> product):
>
>   Section 2.3 (Compression) has one in the second paragraph.
>

Fixed.

>   Section 5.2.1 (Signature Types) has one in the discussion of the 0x13
>   signature class.
>

Also fixed. There was also one in the 0x10 signature types.

>   Section 5.7 (Symmetrically Encrypted Data Packet) has one when
>   discussing "PGP's variant of Cipher Feedback (CFB) mode".
>
>

I contemplated this for a bit. I finally concluded that both you and my 
lawyer (who is on a Proper Trademark Usage campaign) agree and 
therefore no further thought is needed. :-)

	Jon

Date: Tue, 01 Mar 2005 19:36:04 +0100
From: Ingo Luetkebohle <[email-masked]>
Subject: Re: PGP Partitioned Encoding Format
To: Werner Koch <[email-masked]>
Cc: "\"Hal Finney\"" <[email-masked]>, [email-masked]
Sender: [email-masked]

--=-DSG4wfAhWk6maiyAmLnZ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Am Dienstag, den 01.03.2005, 17:18 +0100 schrieb Werner Koch:
> Won't work either with Outlook.=20

Sorry, I didn't mean to imply it would.  I know that all sorts of
work-arounds have to be done for Outlook.

The only thing I have an issue with is the implication that this sort of
encoding might actually be good for other purposes.   For the example
given (mobile devices), a different usage pattern for PGP/MIME should do
the trick just as well.

Ingo

--=-DSG4wfAhWk6maiyAmLnZ
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

--=-DSG4wfAhWk6maiyAmLnZ--

To: Ingo Luetkebohle <[email-masked]>
Cc: "\"Hal Finney\"" <[email-masked]>, [email-masked]
Subject: Re: PGP Partitioned Encoding Format
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Tue, 01 Mar 2005 17:18:35 +0100
Sender: [email-masked]

On Tue, 01 Mar 2005 12:17:21 +0100, Ingo Luetkebohle said:

> Instead of putting in a notation requesting "partitioned", you might
> request the "other way" of packaging a MIME-message just as well.

Won't work either with Outlook. You need at least a way to display
signed message even to users without the ability to check the
signature.  All PGP/MIME stuff does not work with that beast unless
someone figures out how their MAPI can be forced to do certain things.
It is really a pitty that for just one MUA one need to resort to such
pragmatic workarounds.

Shalom-Salam,

   Werner

Date: Tue, 01 Mar 2005 15:36:56 +0000
From: Ben Laurie <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: Forward Secrecy
Sender: [email-masked]

Hal Finney wrote:
> I think we had some discussion of this a few years ago, but I don't
> have my records handy.  I do like the idea of forward secrecy but I
> think there are a few problems with the proposals in the draft
> http://www.links.org/dnssec/draft-brown-pgp-pfs-04.txt.
> 
>    Using a series of encryption keys, each with a short lifetime,
>    reduces the information revealed by the compromise of any one private
>    key because each key protects less data.  If expired keys are
>    securely deleted, attackers will never be able to retrieve them to
>    decrypt captured ciphertext.  Therefore when a public encryption key
>    expires, an OpenPGP client MUST securely wipe the corresponding
>    private key [4].
> 
> I don't agree that OpenPGP clients MUST always securely wipe expired
> private keys.  In the context of a user who wants PFS, this makes sense.
> But for a user who wants to be sure he can decrypt his messages, this
> is a bad policy.  For example, some mail systems may store the messages
> in encrypted form, and he needs to keep the key around in order to read
> those messages in the future.
 >
> We would need to make the wording clear that this is only for clients
> operating in "PFS mode".

Agreed.

I have changed to this:

"Therefore when a public encryption key used for forward secrecy 
expires, an OpenPGP client MUST securely wipe the corresponding private 
key."

>    Deletion should take place once all messages that could have been
>    sent before expiry have been received and decrypted.  For example, as
>    a user logs on, their mail client SHOULD retrieve and decrypt all
>    messages from their mail server before deleting any newly-expired
>    private keys.  A "panic mode" MAY bypass this step.
> 
> I guess that "panic mode" means some command the user could give to
> immediately delete all expired decryption keys.
> 
> But this leads to a larger concern, which is that much of this draft
> specifies client behavior in a manner which has traditionally been out
> of scope for our working group.  We would not normally propose to give
> guidelines for UI such as the existence of a panic mode, and how clients
> should respond to it.  For example, we do not attempt to prescribe how
> client software should display signed messages, what information should
> be shown from a signature, or how to depict messages which are partially
> signed and partially unsigned.
> 
> The PFS draft is full of detailed recommendations about client behavior.
> Here, it describes how and when clients should access the mail server.
> Later, it talks about clients sending various warnings to each other,
> generating keys in the background, and revoking keys before exporting
> the private part.  The main thrust of the draft is towards specifying
> client behavior.

Since some client behaviour must be specified for PFS to work, I don't 
see that that is avoidable. However, I do agree that it should be kept 
to just that behaviour that is actually necessary. Secure deletion of 
private keys is necessary for PFS, and so that should remain. Retrieving 
(and decrypting) messages encrypted with that key before deleting is a 
good idea, but I agree is probably not something to be mandated by this 
draft.

> My principle concern is that since we have eschewed such specifications
> even for the more fundamental task of communicating securely via email,
> does it make sense to go into such detail for a rather more specialized
> sub-task, of achieving PFS in the process?  Here is another example:
> 
>    Clients receiving messages encrypted with a revoked key MUST warn the
>    sender that they should not use that public key again.  Any relevant
>    key revocation certificates MUST be included in the warning.
> 
> This is not really PFS specific, and it may be a good idea, but it is
> exactly the kind of thing which we have left out of the OpenPGP spec.
> There are too many issues involved in the design of a mail user agent
> for a secure email system, for us to try to capture them in a spec.

I agree.

> I won't try to go through the rest of the draft at this time.  As I said,
> I support the goal of PFS, but I am skeptical about whether it makes
> sense for our WG to promulgate such detailed advice on a relatively
> narrow aspect of security.

I am more interested in the parts of the draft that require 
standardisation (such as marking [and transmitting] one-time keys). I 
would be more-or-less happy to remove the "advice" parts of the draft 
and find another venue for them, if that's what the WG wants.

Cheers,

ben.

Subject: Re: PGP Partitioned Encoding Format
From: Ingo Luetkebohle <[email-masked]>
To: "\"Hal Finney\"" <[email-masked]>
Cc: [email-masked]
Date: Tue, 01 Mar 2005 12:17:21 +0100
Sender: [email-masked]

Am Montag, den 28.02.2005, 15:35 -0800 schrieb "Hal Finney":
> One other example where Partitioned Encoding is often the best encoding to
> use is when sending PGP email to mobile devices. Because the two primary
> standard formats for secure email, PGP/MIME and S/MIME, encrypt the entire
> body of an email including attachments as one part, a mobile device is
> prevented from downloading only specific segments of the message which
> can be very desirable in low-bandwidth scenarios.

Thats current practice but you make it sound as if its required by the
standard.  From my reading of RFC3156, it is not.  While the
"multipart/encrypted" part has to have exactly one encrypted subpart, it
may occur several times in any given message.

Both approaches have their drawbacks -- its certainly more telling to
have every attachment encrypted seperately and its also more work for
the handling application.  In any case, its hard to tell what will be
more appropriate for the recipient.  However, advocating a non-MIME
format because of assumptions about the recipient seems ill-advised to
me.  

Instead of putting in a notation requesting "partitioned", you might
request the "other way" of packaging a MIME-message just as well.
If, however, you want to document "partitioned" purely as a backwords-
compatibility thing, please don't put in language that makes it sound
like it might be a good idea for future use.

Sorry, but I've had one too many inline-PGP vs. PGP/MIME discussions to
stay calm here ;-)

regards