Subject: Re: Suggestion for the signing subkey problem

From: "Imad R. Faiad" <[email-masked]>
Date: Tue, 01 Jul 2003 16:45:51 +0200

Hello Ian,

Alice and Bob use OpenPGP to securely communicate
with each other.  They both are prolific with
their use of subkeys for signing and encryption.

1)  Eve obtains Alice's public key.
2)  Generates a Master Key with as many of
    the attributes as Alice's master key.
3)  She then extracts all the public subkey
    which are Alice's key and binds them
    to the Master Key generated in 1).
4)  She generates a signing subkey.
5)  She then generates an encryption
    subkey, in such a way so that it will
    be the most likely one to be used
    by an OpenPGP implementation.
6)  She performs steps 1) through 5),
    with Bob's key in mind.
7)  Both fake keys are then submitted to
    the keyserver.
8)  She sit in the middle intercepting
    and forwarding Alice's messages
    to Bob and vise versa.
9)  She sends a message to Bob, which
    is at least signed with the signing
    subkey of Alice's fake key.  Does
    the same with Alice using the signing
    subkey in Bob's fake key.
10) Alice and Bob thinking that the other
    party must have generated yet another
    subkey update their copy from the servers.
11) In both cases the message authenticates,
    giving credence to the respective fake keys.
12) In the worst case scenario, Alice
    and Bob, will start using the other's
    fake key, while each is ignorant
    that the other party is using his fake
    key.  Since, Eve is in the middle,
    decrypting the messages, then
    re-encrypting and forwarding them to
    the other party.

I know that the above may not be the
best.  But, I am sure, that someone,
with better skills than mine, can refine,
or come up with one which is a lot more
effective than the above.

The above sounds implausible to you?
Think again, while you think that you know
what you are doing, most OpenPGP users
don't, so don't trust that they do.
No fool is going to attack the cryptographic
aspect of OpenPGP.  Subkeys, used incorrectly,
gives yet another avenue for a would be attacker,
to exploit the vulnerabilities of the user.
Please read this:-
http://home.earthlink.net/~cortana/johnny.pdf
The users are finding hard to understand
the simple aspects of OpenPGP.
The user interface has yet to evolve
to present such simple aspects to the
user in an easily understood manner.
I wish that someone from say the PGP team,
can comment on the impact of the prolific
use of subkeys on the user interface of their
software.  OpenPGP is not a Diffie-Hellman
key exchange protocol, people are in the
middle of it, and they do err...
Now, which you do you prefer, more bells
and whistles, which will be mis-understood,
and mis-used, or less which is better
understood, and more likely to be used
in a more idiot proof manner.

There are a spectrum of solutions.
On the one extreme there is the scalpel school of
thought which believes that if something
is questionable, you get rid of it altogether,
to put my suggestion on the Master key/ one
subkey restriction, into perspective.  It does
not mean that I belong to the "scalpel school of
thought".  Nor do I profess such a proposed solution
as a religion...  I could care less what the adopted
solution is, as long as it addresses the root of
the problem to my satisfaction.

David Shaw's patch, does not solve the problem.

Why shouldn't subkeys be regarded like any other
keys.  What applies to key, should apply to them
too.

my 2c

Best Regards

Imad R. Faiad

On Sun, 29 Jun 2003 23:01:26 +0100, you wrote:

>
>> >I am amazed that this thread is still running several weeks 
>> after you 
>> >started it, with virtually every response refuting your arguments...
>> >
>> And what amazes me, is that you have yet to grasp what we are 
>> talking about!  Please re-read the thread, some issues have 
>> been addressed.  I sincerely hope that you re-read each and 
>> every message in that thread, because, you are taylor made 
>> for the kind of attacks which can be inflicted to your OpenPGP keys.
>
>I've read all the messages. Your request that subkey capability be
>essentially removed has been rejected by all of them.
>
>> >RFC 2440 was published five years ago. I look forward to your draft 
>> >removing multiple subkey capability from it.
>> I am no paper pusher, and do not have the funding or 
>> time/ability to publish RFC's
>
>So I guess this thread is at an end then, with the capability remaining.
>
>

---

From: Derek Atkins <[email-masked]>
Date: 01 Jul 2003 11:57:13 -0400

Ok, putting my chair hat on.

Removing subkeys from 2440bis is OUT OF SCOPE.  Fixing security
problems with subkeys is IN SCOPE.  The goal of 2440bis is to fix
security and interop issues, not remove functionality just because
some people have minimalist views.

While minimalism is a virtue, it (like all things) should be applied
in moderation.

Having said that, and taking my chair hat off....

>     subkey in Bob's fake key.

Except there is no subkey-signature from the signing subkey on the
fake-Alice master key, so Bob wont accept it as a valid subkey.

>     subkey update their copy from the servers.

Except they wont think this, because the subkey wont validate on
Eve's replacement keys.

>     re-encrypting and forwarding them to

Well, first, if Alice and Bob have signed each other's master key,
then they wont use the fake keys.  

> The above sounds implausible to you?

It sounds implausible in the face of a real WoT between
Alice and Bob.  It also sounds implausible once Alice and
Bob have keys in the local keyright.  It is certainly plausible
on a first-contact basis without a real WoT.

I will note that UI issues are out of scope here.  The UI issue
is an implementation issue and has nothing to do with interop.
The purpose of 2440bis is to fix security and interop problems;
how that is translated to a UI is implementation dependent and has
little to do with the protocol.

> the problem to my satisfaction.

As I have already stated, removing subkeys is out of scope.

> David Shaw's patch, does not solve the problem.

Can you please show an example where David's patch does not work?
In particular, the approach where the master key and subkey cross-sign
each other seems to protect against all the attacks you've proposed so
far...  The case where Alice does not know Bob's master key is a WoT
issue and has nothing to do with subkeys -- the subkey issue is knowing
what master key a subkey belongs to.

> keys.  What applies to key, should apply to them

In what way are subkeys not regarded like master keys?

> Imad R. Faiad

-derek

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

---

From: "Imad R. Faiad" <[email-masked]>
Date: Tue, 01 Jul 2003 20:18:55 +0200

Greetings,

Except that the human psyche does not function in the
manner in which your protocol thinks it should.
And that may be it's shortcomings.

Packets, protocols, and RFC's are meaningless, when
the limitations of the human mind are not taken into
consideration.  By UI, I do not mean an implementation,
I mean, the UI of your RFC, yes, RFC's have a UI...
UI does not only stand for "User Interface", it is
also what I call "Human Element".

You talk about the WoT, but, isn't that broken
with subkeys...

That is all I have to say, and only time
will prove me right.

If you do find me obnoxious, then, by all means
do let me know, I will then refrain for posting
anything to this forum.

Best Regards

Imad R. Faiad

---

From: Derek Atkins <[email-masked]>
Date: 01 Jul 2003 14:57:41 -0400

Hi,

> And that may be it's shortcomings.

The human psyche also doesn't remember 1024-bit numbers
or perform RSA encryptions.  That's why we have computers,
to do a lot of work that the human brain cannot do itself.
The point is that the computer does the hard work and
presents the information in a form that the human psyche
can understand.

> also what I call "Human Element".

Uh, no.  Sorry.  RFCs certainly have "operational requirements"
but there is no UI to an RFC.  An RFC is a description of a
protocol.  Different implementations can present that protocol
to users in VERY different ways.  Except in very limited ways
the RFC does not say how information should be presented to
users, and this is a Good Thing.

Yes, there is a "human element" in terms of usage constraints,
operational considerations, and even security implications,
and yes, the RFC can point implementors at a "best current practice"
to presenting information.  However that is all ancillary information;
the RFC is in general a protocol document.

> You talk about the WoT, but, isn't that broken

In general, no, it is not.  There is a particular problem with signing
subkeys not being able to securely refer to the master key (which is
what the current proposal is trying to fix), but no, in general there
is not a WoT problem with subkeys.

Walking through a normal WoT (in one direction -- the other is just a
mirror image).  Alice wants to send a message to Bob.  Alice gets
Bob's key and see's that Charlie has signed it.  Alice knows Charlie,
has verified Charlie's key, and trusts Charlie to properly verify
keys, so through the WoT Alice can now trust Bob's key.  Alice can now
encrypt a message to Bob's key and have some level of assurance that
it is correct.  An attacker could supply another key on a keyserver
with Bob's name, but it wouldn't have Charlie's signature

Now, let's look at encryption subkeys.  The beginning of the story
remains the same, except Charlie is signing Bob's master key.  Bob's
master key signs the encryption subkey, so Alice knows that Bob wants
to use that subkey.  An attacker couldn't add another encryption key
because it wouldn't be signed by Bob's master key.  An attacker could
claim an encryption key as their own, but to what end -- they couldn't
read the message anyways?  At best it provides plausible deniability
for the actual recipient of an encrypted message.

So we're perfectly safe so far.  Let's look at Bob signing messages
to Alice.

In a normal single-key (RSA or DSA) case we're in the same boat at the
first case.  Nothing new here.  The question is what happens when you
introduce signature subkeys?

Alice receives a message signed with 'key X'.  Bob's "keychain"
contains subkey X signed with his master key.  So, Alice knows that
Bob claims X is his key.  Alice knows the master key belongs to Bob
from Charlie's signature, so the master key is verified.  However,
there is a problem here (and in RFC2440).  Eve could strip out subkey
X from Bob's keychain, put it onto her own and self-sign the subkey
with Eve's master key.  Now (following 2440) Alice does not know
whether key X belongs to Bob or Eve.

HOWEVER, if we take a step forward in time and look at the current
proposal, where the master key and sub-key co-sign the binding.  With
the co-signature, key X signs "I belong to Bob's master key B" and
Bob's master key signs "key X belongs to me".  Now, just having key X
you can back-track to Bob's master key and the existing WoT for
verification.  Even if Eve extracts subkey X and puts it on her
keychain a 2440bis-compliant implementation wont accept it, because
the subkey wont be co-signed.

So signing subkeys are safe (with the change to cosign).

> That is all I have to say, and only time

Perhaps, but you have not provided the math to back yourself up.
Please, if you see a problem with this proposal please explain
it... Please provide the math showing how it doesn't work, or
the use cases where the key-bindings are insufficient.

We want to make 2440bis complete, and all input is welcome.
But please keep the topic to "fixing the subkey problem" instead
of "subkeys are bad -- get rid of them".  The latter is both
unhelpful and derailing, neither of which helps make forward progress.

> do let me know, I will then refrain for posting

I have not asked you to refrain from posting.  I have
asked that posts remain on topic and in-scope.  I do not
feel that is an unreasonable request.

-derek

---

From: "Imad R. Faiad" <[email-masked]>
Date: Tue, 01 Jul 2003 20:19:21 +0200

Greetings,

Best Regards

Imad R. Faiad