public-key: the wrong model for email?

[Anne & Lynn Wheeler]

At 05:35 PM 9/16/2004, Adam Shostack wrote:
>Generate a key for "unknown-recipient at foocorp.com" encrypt mail to
>Bob to that key.  When Bob shows up, decrypt and send over ssl.


note there is still the issue of knowing it is bob ... whether before the 
"transmission" or after the "transmission" .... and, in fact, the 
"transmission" itself is somewhat arbitrary.

in the physical world ... the base point is that the sender pays to 
physically transmit something. there is threat model of taking physical 
possession of whatever is being transmitted. they then pay extra for 
countermeasures wrong person taking physical possession. they also pay 
extra for extra care in delivery to the correct person.

the current electronic world ... the base point is that the sender doesn't 
actually pay per transmission. with encryption, the threat model is changed 
to possession of the unencrypted information. encryption (shared-secret or 
digital signatures) is also used to help with the issue of "delivery" to 
the correct person (although the convention is converted to the correct 
person decrypts the data).

so what is the difference between the sender setting up facility so that 
"when bob shows up" .... bob gets a decrypted version .... and say sending 
a version to some trusted 3rd party that is encrypted with the 3rd party's 
key ... and direction to only let bob have it when bob shows up. how does 
the 3rd party know its bob ... any better than the originating sender? note 
also in standard ssl ... the recipient generates a random symmetric key and 
sends it to the server, encrypted with the server's public key. there is 
nothing about how the server knows that the bob making the contact ... and 
the bob that is suppose to receive the information .... is the same entity.

so the 3rd party keeps the pre-transmitted encrypted stuff with directions 
to only give it to any entity that shows the magic something (the movie 
stuff about tearing a bill in half and the person needs to have the 
appropriate torn half).  the 3rd party holds it until bob contacts the 
sender and gets the magic something ... which they they can give to the 3rd 
party. given the nature of electronic transmission ... is that really 
substantially different than the sender waiting until bob contacts them 
before doing the original transmission.

if it is purely electronic world ... how does the sender get the necessary 
information to the correct bob ... so that the correct bob can give the 
stuff to the 3rd party ... to proove that they are the correct bob.

so possibly the only distinction ... is that the email communication 
between bob and the sender is non-real-time ... and the SSL communication 
is considered possibly real-time .... so the scenario isn't actually the 
information being transmitted between the sender and bob that is the issue 
... it is possibly the mechanics of real-time vis-a-vis non-realtime?

so the sender at some point has to trust bob's authentication information 
(whether directly and/or outsourced to 3rd party) ... say digital signature 
public key and may or may not trust that same key for encryption.

common pgp flow ... which effectively is the same as ssl ....  same process 
steps ... but possibly not in real time. sender looks up in some directory 
the contact information for bob,
this directory is trusted to map the contact process for bob to bob .... 
the directory may or may not also provide some authentication information 
for bob.  if the sender doesn't have authentication information for bob ... 
they send message to bob requesting authentication information. when they 
get that back, they vet the authentication information before using it to 
make sure it is actually for bob. so now they have a process which has some 
assurance of contacting bob and some assurance that bob can be authenticated.
this is pretty much true whether the actual sender is responsible for the 
steps or has been outsourced to some 3rd party.

now the issue is wether or not the authentication information is also 
trusted to securely protect the classified information during transmission 
(aka public key).  possible scenario if sender  requires different 
encryption keys from authentication information:

1) sender sends message to bob saying classifed document is waiting. bob 
generates secret key, digitally signs it, encrypts it with the senders 
public key and returns it to the sender. this could be all email exchange 
... or possibly combination of email and ssl .... it could also be directly 
with the sender or a 3rd party agent on the sender's behalf.

2) the sender decrypts bob's message, validates the digital signature, 
encrypts the classified information with bob's secret key and sends the 
information to bob. the sender's process can be email or ssl ... and can 
either directly be the sender ... or a 3rd party acting on the sender's behalf.

for efficiency purposes .... the acquisition of bob's authentication 
information and possible encryption key might be collapsed into single 
round trip. sender (or 3rd party on sender's behalf) send bob a message 
that they need both bob's authentication information .... as well as a 
digitally signed, randomly generated secret key ... which is encrypted with 
the supplied public key. the sender/3rd party then has to vet bob's 
authentication information .... before using the randomly generated secret 
key. again, the exchange could be purely non-real-time email .... or 
combination of email and real-time ssl.

sort of practical issues:

given that the electronic paradigm have enuf differences from the physical 
world sending model (i.e. sender doesn't pay in the base case) .... can 
sender's be induced to pay 3rd party to outsource some of the operations?

given that the there are some number of other vulnerabilities and exploits 
in the overall infrastructure .... is the treat model specifically to 
trusting bob's public key for both authentication and confidential 
transmission .... sufficient to impose the extra processes (and/or convince 
sender's that they need to pay extra money for outsourcing to 3rd parties).

since the paradigm issue of securely transmitted has changed from secure 
physical movement to safe encryption .... a 3rd party may only have to 
provide a business of assuring recipients'  public keys for "safe" 
transmission (as opposed to actually doing the transmission). everybody 
gets to generate their own public/private key pair for authentication. the 
same key pair is not used for both authentication and encryption. people 
may also generate their own encryption key pair.

senders either trust a recipient's encryption key pair ... or they don't. 
if the sender doesn't trust a recipient's encryption key pair .... they ask 
for a encryption public key that has been issued by a trusted 3rd party ... 
and for which the 3rd party is willing to attest to. there is an issue of 
how the issued private key has gotten to the recipient ... but that isn't a 
whole lot of difference than the process of a recipient exchanging a real 
secret key for transmission. there is an issue of whether or not the 
recipient has continued to protect the encryption private key .... but that 
isn't a whole lot difference than whether or not the recipient has the 
facility to protect the unencrypted classified document (once they receive it).

the physical world has the sender outsourcing and paying for the actual 
secure physical movement .... and some assurance that it only goes to the 
intended recipient. translated to the electronic world ... the paradigm has 
been changed to the use of encryption to make sure wrong people don't have 
the unencrypted version ... and various kinds of authentication processes. 
so the critical processes has changed not from the actual movement of the 
data ... but the encryption process "gatekeepers" .... aka the integrity 
and management of keys used for authentication and decryption. so rather 
than focus on the actual electronic transmission processes .... focus on 
the issues related to the keys.

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/ 


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com