From: Adam Back <aba@dcs.ex.ac.uk>
Date: Tue, 14 Oct 1997 03:34:02 +0800
To: whgiii@invweb.net
Subject: Re: D-H Forward Secrecy for E-Mail?
In-Reply-To: <199710131045.GAA20731@users.invweb.net>
Message-ID: <199710131652.RAA02526@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




William Geiger <whgiii@invweb.net> writes:
> >I think this is taking it too far.  Have you considered how much traffic
> >DNS handles right now?  I would have thought it would be many orders of
> >magnitude more than forward secret email is going to cause. Web traffic
> >is the bulk of network communications, just imagine the DNS lookups
> >caused by 50 million netters clicking away. 
> 
> Yes but everyone's Ip's aren't changing every week. It's not just a matter
> of the multitude of requests that would be required in this systems as
> everyone will need to update all their keys on a weekly basis but also the
> DNS records will be having this turnover. the DNS system has enough
> problems as it is let alone what would happen with the implementation of
> forward secrecy would cause (my best guess that within a week or two the
> whole thing would crash and burn).

Your argument neglects that it was you who was arguing for DNS
distribution of keys.  I was never too keen on this idea.  Your
descriptions of the near breaking point reaffirms my dislike, though
I'm not sure I agree with your crash and burn predictions.  Mind, DNS
maintenance is not something I have a great deal of familiarity with.

My comparison was intended to be "implementing forward secrecy by
storing comms keys on keysevers using ad-hoc distribution of
distributed keyservers would cause orders of magnitude less traffic in
total than current DNS requests".  I think that sounds entirely
reasonable.

By ad-hoc distribution of key-servers I mean key servers which don't
have replication but rather store keys for some designated set of
users within a set of domains.  The DNS would be a good place to store
the resolving mechanism for deciding where the keyservers live.
Similar perhaps to the way you use a DNS MX record to find a mail
exchanger for the domain name you're trying to send to.  Use DNS
keyserver extension record to find keyserver IP address.

With that architecture, the whole thing sounds pretty scalable, and
adds negligble extra overhead to the DNS system.  Storing the keys
themselves directly into DNS is something people get interested in for
IPSEC, and for that application it seems more reasonable.

> >Bear in mind also that once the new key has been issued, you could also
> >release a deletion request for the previous one on the keyserver in the
> >form of a revocation certificate.
> 
> You would have to otherwise you would run out of storage very quickly.

Indeed!

> The best I can think of handleing the key distribution problem is to
> attach a copy of your key to every correspondence and then have the client
> automatically check and see if it has changed and update the keyring as
> needed. 

My thoughts also.  In fact for particularly short lived keys I have a
scheme worked out where key servers are not used at all.  I haven't
really described this scheme yet, as people seem to be raising enough
objections over the logical uses of current PGP functionality.

> If find both the automatic processing & sending the key with every
> messages quite bothersome (these are PKS implementation issues that
> should be covered in a different thread).

Well I thought it was a neat idea.  Perhaps that is because you have
the world view that every email recipient has a direct IP or at least
a dialup with flat rate connection charge, and also another reason I
thought it was neat was because I was considering it as a mechanism to
enable per message forward secrecy in a manner which I still haven't
explained in any detail.

> [protecting against users who store keys on sticky notes]
> 
> Well IMHO this scenario does not forward your cause much. If the physical
> security is that bad (unrestricted access to equipment, weak passphrases,
> Post-it-Notes, ...ect) then the information an attacker is looking for is
> more than likely going to be available to him without messing with the PGP
> keys. 

Yeah, well perhaps it wasn't that great an example.  However you can
see that extra security is being imparted even into this less than
ideal scenario.  These security problems are representative of the
problems some real life businesses face.  Most company employees do
not extract as much fun from the arcane fine points of best security
practice as we do.  They probably view security as an inconvenient
imposition, forcing them to learn things they don't want to know
about.

> If the reverse is true and the physical security is strong the the
> case for short-term separate keys is gone as the risk of exposure to
> a long term key is greatly reduced.

Ooh no.  It's not gone at all.  I think you are being a tad closed-
minded here.

If you have excellent security practice, you are still vulnerable to a
number of attacks which my proposal gives extra protection from:

1. being blackmailed, or having the password for your encryption key
   with 1 year expiry period rubber-hosed from you

2. having a keyboard sniffer installed by the Feds burgling your house
   whilst you are out.

3. having a virus installed by an attacker remotely or directly
   infecting your machine

With all 3 of these cases your security is blown wide open, despite
your 100 bit entropy pass-phrase and crypto-anarchist 'tude: "you'll
get my key when you pry it my cold dead fingers", and apparent
reasonable security precautions you will have blown your security.  If
your key had a 1 year expiry that might mean the Feds get up to 1
year's worth of the plaintext from the encrypted traffic they had been
meticulously collecting from their collaboration with invweb.net.

Now consider what happens to the above attacks when you have forward
secrecy:

1. blackmail/rubberhose .. it's kind of hard to not notice black mail
   or having passwords rubber hosed from you.  So as you have used my
   recommendations of the most paranoid forward secrecy setting (1 new
   key per message, sent in message) the attacker gets zip.  He gets
   nothing.  With a key update time of 1 day, your attacker gets up to
   one days plaintext, or with 1 week update up to 1 weeks comms.

2. keyboard sniffer .. presuming that you don't notice it, the
   attacker gets traffic going forward in time, but doesn't get old
   traffic

3. virus .. presuming that you don't notice it, the attacker gets
   traffic going forward in time, but doesn't get old traffic

I think that is a security advantage, wouldn't you agree?


There are quite a lot of precedents for using forward secrecy... for
example SSH, SSL, and some of the IPSEC protocols.  They aren't using
forward secrecy for phun, they're using it to increase security also.

Granted it's easier to do interactive forward secrecy with IP
connections than email, but forward secrecy is just another term which
describes something we are all already very familiar with: key expiry.

Consider why does PGP provide you with a mechanism to expire keys.
The reason is because it's acknowledged that it's a good idea to
change the keys now and then -- because this provides you with forward
secrecy -- the longer you use the same key the more the risk that it
is compromised accumulates, and the more value it will have to the
attacker because of the larger number of messages it is protecting.

So all I am really saying is that shorter key expiry times give you
more security... not that radical a statement I don't think.

> >That much as such doesn't need any modifications to the current PGP
> >standard.  It's an implementation issue.  Another vendor could easily
> >already implement this type of functionality.
> 
> I have some serious reservations of the security implications of frequent
> changes to the keys. It has the potential for the user to disregard all
> changes to the keys (think how quick the warning pop-ups in Netsacpe get
> ignored and/or disabled by the user). The other possibility it to make the
> key changes transparent to the user which I do not like at all for obvious
> reasons (I do not see complete isolation of the user from the cryptosystem
> as a Goodthing(TM) ).

Heh.  Well there is where we part company then, because I do think
hiding some parts of the crypto innards where this is appropriate is a
good thing.  I think the generation of new transient keys is one such
case.

You are already using this mechanism every day anyway: your SSL
enabled web browser will be setting up key exchanges using short lived
communications keys with secure web servers.  You do see notices when
you haven't agreed to trust this organisation before, but you will
observer that netscape asks you if you would like to trust this
organisation this session only, or for all further sessions.

What I am proposing is the same "for all further sessions", applied to
PGP.  I reckon it is more secure because you have the PGP WoT to help
guide you in your decisions, where as I currently find a lot of web
sites using uncertified server keys, and I'm not sure how much
security the very limited numbers of hierarchical server certifcate
issuers provide in practice.  I prefer the PGP WoT where I can get
face to face transfer of keys with people.  The trust is much more
immediate.

> >Also I'm arguing for separate communications and storage keys, I think
> >this is almost essential once PGP starts to work with escrow schemes,
> >because there are similar arguments for separating storage and
> >communications keys as there were for creating separate signature and
> >encryption keys from the original single key.
> 
> Well I have been thinking more on this. I still am not sold that separate
> keys are needed but even if they are I am inclined to believe that PGP is
> not the place for them. I am leaning towards the opinion that file
> encryption should be handled by the files system along with other disk
> security features. This seems more appropriate than having your e-mail
> client doing individual file encryption.

I agree with you there.  That is way the most appropriate place to put
storage encryption.  However (and this is my point also in another
form), if you were to do this, you would want to use a different key
than the one you use for protecting communications keys, because the
storage key may have different expiry requirements, and different
escrow requirements.

But... we have a circular dependency in our argument here, because
when I was arguing that you didn't need to encrypt the contents of
your mail folders 10 messages back or so, you jumped in and said that
you kept email communications encrypted in your mail folder.

I accepted your point, and countered that if you wanted to encrypt
messages in your mail folder, that you should use a storage key to do
so.  (Otherwise you couldn't sensibly make use of the expiry feature
on your communications key, as when your comms key expired, so would
your access to your mailbox!)

I agree with your above suggestion that it is actually easier, safer
etc, to use disk level encryption systems.  However I do think we have
to face that these are not that widely deployed yet, and that people
like yourself a few days back are correct in arguing that there may be
a case for building the functionality of encryption of stored traffic
in folders.  As PGP Inc is fielding integrated Mail clients which have
mail folders managed by the mail client, this gives us the case for
separate storage and communications keys.

This also gives a convenient place to put escrow -- you escrow the
storage key.

This implementation would completely avoid all arguments about PGP 5.5
being GAKware.

> >I also personally prefer people to send me keys in email, because the pay
> >per second phone lines here at home mean that I tend want to avoid doing
> >too many online key lookups, so I think this would be an individually
> >useful feature.
> 
> I do my keylookups automatically durning the msg filtering process which
> is done in parallel to the message Dl's. 

A clever optimisation to be sure.

> The outbound message lookups are a little more time consuming but is
> compensated by fewer keys to look for both because fewer messages on
> the outbound side and the use of key caches on the client machine
> for the most used keys for sig verification and encryption. 

I don't have a key cache, and my keyring is only 216k.  But I'm
curious about your automated process .. are you also checking all
signatures that you can by downloading the keys and checking out the
WoT for all received mailing list traffic etc?  This would cleary
result in a much bigger key ring.

> Also logging of e-mail addresses that do not use PGP cuts down on
> the number of lookups needed

Good optimisation.  It sounds really as if your OS/2 setup is more
advanced than a lot of other stuff around.

My setup is GNU emacs with Pat LoPresti's mailcrypt.el PGP and
remailer support lisp extension for emacs RMAIL and emacs GNUS
(newsreader).  I love it to bits.  It is totally excellent.  It
doesn't have a couple of your optimisations, but other than that it's
pretty good.  When you send messages, if you don't have the key it
will fetch it for you by trying keyservers, then finger user@domain.
It can snarf keys out of mail messages, paste keys into them, sign,
encrypt, check signatures, use remailers (type I and mixmaster).

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@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`