Re: Suggestion for the signing subkey problem

[Derek Atkins <derek@xxxxxxxxx>]

Hi,

"Imad R. Faiad" <matic@xxxxxxxxxxxxxx> writes:

> 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.

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.

> 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".

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
> with subkeys...

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
> will prove me right.

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.

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

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.

> Best Regards
> 
> Imad R. Faiad

-derek

> On 01 Jul 2003 11:57:13 -0400, you wrote:
> 
> >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....
> >
> >"Imad R. Faiad" <matic@xxxxxxxxxxxxxx> writes:
> >
> >> 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.
> >
> >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.
> >
> >> 10) Alice and Bob thinking that the other
> >>     party must have generated yet another
> >>     subkey update their copy from the servers.
> >
> >Except they wont think this, because the subkey wont validate on
> >Eve's replacement keys.
> >
> >> 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.
> >
> >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.
> >
> >> 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.
> >
> >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.
> >
> >> Why shouldn't subkeys be regarded like any other
> >> keys.  What applies to key, should apply to them
> >> too.
> >
> >In what way are subkeys not regarded like master keys?
> >
> >> my 2c
> >> 
> >> Best Regards
> >> 
> >> Imad R. Faiad
> >
> >-derek
> >
> >> 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.
> 
> 

-- 
       Derek Atkins                 617-623-3745
       derek@xxxxxxxxx             www.ihtfp.com
       Computer and Internet Security Consultant