Bill Stewart <stewarts(_at_)ix(_dot_)netcom(_dot_)com> writes:
At 11:50 AM 10/29/1997 GMT, Adam Back wrote:
This approach to extensions leads to compatibility problems -- you
send to sales(_at_)acme(_dot_)com and it will bounce your mail if it is set
up
strictly.
The PGP Inc. SMTP filter offers a medium-wide range of options;
it can be set to reject unencrypted mail, or reject encrypted mail,
or reject unsigned mail (of course it can't decrypt, so it can only
tell whether unencrypted mail is also unsigned), etc.
If the administrator doesn't write adequately explanatory bouncegrams,
unlucky senders are going to get hosed anyway.
Yes.
In particular, one of the postings I read on this list said that if
the sender's PGP public key ring doesn't already have the CMRK key,
it will ignore the CMRK KeyID request, so you'll get hit with this anyway.
I'm not sure but I think this may be limited to pgp5.0.
To guarantee compatibility, your choices as implementor are:
- send garbage in second recipient field
- send valid second recipient
Unfortunately, it does look like the new format uses 64-bit KeyIDs
for these fields, and a 0xdeaddeaddeadbeef attack is a few billion
times harder than a 0xdeadbeef attack, which could otherwise fool it :-)
I think it's much harder to fool than you're thinking -- it doesn't
decrypt the data, and so it can't attempt in anyway to verify the
contents of the PKE. (It could somewhat with binding cryptography,
but I understand this is not currently used).
So I think if you get an ARR request for 64 bit key (or 128 bit key,
or whatever) 0x12345781234578 well you just create the second
recipient PKE field like so:
[ARR key-id][length-header][garbage]
and it will go flying through, right? No 0xdeadbeef or longer cousin
attacks required.
(Suggestions for human readable ASCII to put in the garbage field
accepted on a postcard:-)
- ignore additional recipient request (it does say "request"), and
have confused users who can't interoperate even though both using
OpenPGP compliant appliactions.
doesn't seem very good from an interoperability point of view, unless the
standard says that pgp5.5 should not bounce mail.
PGP5.5 doesn't handle mail, so it can't bounce it. SMTP filters do,
and they're outside the scope of OpenPGP. Mail User Agents may
call PGP, but by then it's delivered, though I suppose the MUA could
bounce it if PGP returns an appropriate failure code, like "Can't decrypt".
(Returning predictable and useful failure/success indicators _is_
part of OpenPGP's scope.)
The CMRK enforcement could be moved in to the MUA -- not as usefully
though, because then the recipient must manually send the bounce
message.
The correct way to implement extensions I think is to detect extension
capability based on public key, and only use it where it is available.
(Such as SMTP extensions, browser capability negotiation, SSL
algorithm negotiation, etc). Same as symmetric cipher capability
flags in public keys (which are already defined -- I think?)
Do you mean look up the extension information in some keyserver?
Or do you mean what it sounds like you mean, which is determine
whether to use a given extension based on flags in the public keys records?
If the latter, that's _precisely_ what the CMR feature _does_...
Almost, but not quite. The enforcer, I attempted to argue, could
determine from the public key of the sender, or from the version
number of the message whether the sender was able to comply with the
ARR request. If the sender was unable to comply, there is no point
bouncing messages because the sender has _no way to_ comply (short of
downgrading his software to some CMR enabled software).
What you are talking about is the CMR flag in the recipients key. It
is the sender who's mail will be bounced if his software silently
ignores the ARR request.
This approach to extensions would dictate that pgp5.5 policy enforcer
SMTP agent would only ever bounce mail where the keys indicated they
were generated by software which advertises being capable of
understanding ARRs.
The PGP5.5 message format doesn't differentiate between recipients
who were included because the sender wanted them or because of ARRs,
and the PGP Inc. implementation of the SMTP incoming enforcer can't tell.
Yes. The multiple recipients all look the same regardless of whether
they got there because they are on the Cc: line, or because the
recipients key was created by PGP 5.5 for business.
On the other hand, the only people who would install such a silly thing (:-)
are companies whose users have been told to use PGP Business Version>=5.5,
and if you _want_ to enhance the filter to check each KeyID, it'll find
their CMRK recipient KeyIDs and be happy.
That's what I was suggesting above, yes. Probably easier to define a
flag in the message, or a version number, or extension mechanism which
allows the policy enforcer to notice that the sender has no way to
comply with ARRs because his software has no idea what to do with
them.
I guess there's still the outgoing email policy enforcer, which
_could_ hang on to each outgoing encrypted message while it tries to find
the KeyID on some keyserver that may not even be accessible to it
to make sure the recipient doesn't mind that the sender's company
kept a copy of the outgoing mail, but it sounds impractical to implement.
Different problem. The recipient can tell this after he's received
the mail if there are statement of intent of sender plaintext handling
flags attached to the senders key, or to the message.
Note I didn't say leave the CMR field in -- that's a security flaw,
CMR is dumb to start with, but it's even dumber to leave the CMR field
in after passing through an enforcer, it should strip it out for
security reasons.
I'm mostly surprised, because you seem to have agreed with 2/3 - 4/5 of
what PGP5.5 CMR does, and I thought you were more vehemently against it
than I am....
I am against it. It is a security design flaw, and it is basically
clipper implemented in software, with all the inherent risks of
government abuse.
However, if certain people on this list proceed to ignore these risks,
and can't be talked out of including the LEAF-like field at least we want
to ensure that software can interoperate in ways which ensure that
people who don't want to send to corporate keys can just fill in that
field with a nice big `FUCK YOU' in reply to the ARR request. I argue
for defining this in the standard as the correct behaviour. That
takes a lot of the sting out of CMR dangers -- if all the software
provides you with an option to bypass it for personal messages.
Note pgp5.0 and pgp5.5 for business and for personal use do not
currently do this (against strict settign SMTP enforcers). It would
be far friendlier to provide a "personal mail" or "official company
business mail" button which filled garbage into the requested
additional recipient field. It would also make the bouncing enforcers
kind of pointless...
Also interesting would be to include recommendations in the standard
for good security practice:
- use separate storage and encryption keys
- have short lived communication-only keys
- use forward secret transport level security where available
- use opportunistic forward secrecy (and show how to use existing
packets to support this)
PGP Inc do not currently seem to be interested in providing increased
security, nor in following good security principles, nor in adding
increased resistance to unauthorised third party snoopers (be they
industrial espionage, or rogue governments, or rogue government
agents.)
I think that the standard should do what it can to encourage good
security practice. I hope someone won't tell me this is outside the
charter! (Surely it's pointless defining a security standard which
encourages sloppy security practice.)
It might be worth documenting, or making suggestions in the standard
on a method to implement extensions, so that we don't get more
problems like this.
Yep. I'm especially annoyed at this one, since we _had_ the source
and basically nobody noticed these features were there until PGP
announced what PGP 5.5 did with them, and I'm not sure if anybody
even noticed the more blatant ViaCrypt GAK features until then.
(But I did send you my copy of the source using cheap slow-mail :-)
Sorry -- that's the problem with 1 foot of source code -- people run
out of energy reading it :-)
Then people who don't want ARR for security and political reasons can
interoperate.
OpenPGP definitely shouldn't encrypt to ARRKs without some indication from
the sender that it's OK, whether it's a command-line flag or checkbox
or failing to drag the red blinking icon out of the dialog box
or config file / preferences setting or something.
That's not generally possible for reasons you gave below (batch
processing, etc.).
Simpler, either:
- allow the sender to interogate the recipient key to find out ahead
of time and give instructions with the encryption request
- define a choice as an extra flag to the encryption process -- is
this a personal message (say `FUCK YOU' to ARR requests) or a
corporate message (put up with security risk to help company deal
with your request promptly even though company is using software
with poorly designed message snooping software)
So for personal messages, if there is an ARR request, define the
action to be to fill the field with garbage (you could actually say
"ADDITIONAL RECIPIENT REQUEST DENIED" in the PKE place-holder, or less
polite variants :-)
For official company messages define the action to be to fill the
field with the encrypted message key.
Adam
--
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`