[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Suggestion for the signing subkey problem
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