Hi,
"Imad R. Faiad" <matic(_at_)cyberia(_dot_)net(_dot_)lb> 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(_at_)cyberia(_dot_)net(_dot_)lb> 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(_at_)ihtfp(_dot_)com www.ihtfp.com
Computer and Internet Security Consultant