[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    Re: [cap-talk] Re: [web-calculus] YURL FAQ
From:       Al Gilman <asgilman () iamdigex ! net>
Date:       2003-08-31 20:43:10
[Download RAW message or body]

Please pardon the cross-posting of what is likely a novice outburst.

At 02:50 PM 2003-08-31, Mark S. Miller wrote:
>At 01:58 PM 8/29/2003  Friday, Ben Laurie wrote:
> >Mark S. Miller wrote:
> >
> >> At 07:06 AM 8/26/2003  Tuesday, Ben Laurie wrote:
> >>
> >>>Such as?
> >>
> >>
> >> Vulnerability to a third party.
> >
> >Explain? How do YURLs avoid this problem?
>
>
>Hi Ben, I'm not sure where we're failing to understand each other. I think
>this issue is important, as it is one of the foundations of the capability
>perspective on naming. (Because the issue is foundational, rather than YURL
>specific, I'm cross posting to the cap-talk list.) Since the problem may be
>something I mistakenly thought was obvious, but since I don't know which
>one, please excuse that I will proceed at times belaboring the seemingly
>obvious.
>
>But before I begin, in order to give the web-calculus and cap-talk lists
>shared context, I include below my reply to you on the cryptography list. I
>will proceed assuming you've read
>the reply included below,
>Tyler's http://www.waterken.com/dev/YURL/Why/ ,
>my own http://www.erights.org/elib/capability/pnml.html ,
>and Carl Ellison's http://world.std.com/~cme/usenix.html .
>Any guidance you can provide as to where we're missing each other would help
>to narrow the search space.
>
>Due to other claims on my time, please don't be frustrated if my responses
>come at a glacial pace, so anyone else who could help clarify should please
>jump in. Thanks.

No, I haven't absorbed the above three references.

But I had the same concern as Ben and now I think I *may* understand
what the answer may be.  So let me try to echo.

If someone puts an httpsy: scheme YURL in a document without protecting the
YURL/context binding in any way; any MITM attacker sniffing packets at IP
level can put a different httpsy: scheme YURL in its place and lure the
unsuspecting to an impostor site.  An httpsy: scheme YURL is not ipso-facto
trustworthy.  It could be from a goodie or a baddie -- the scheme has not
the power to enforce any distinction.

But there is a strong level of integrity between an httpsy: scheme YURL and
a signed document returned from an HTTPsy server as the claimed
representation of the resource identified by the httpsy: scheme YURL that
the requester received in some other transaction.

Subject to the ususal caveats about compromise of the private key in
question, it is considerably harder to synthesize a bogus
document+signature+publicKey triple that will match the hash in the YURL
than to create a matching triple if you indeed have the private key under
control that initiated the transform chain leading to the hash in the YURL.

So if an httpsy: scheme YURL is passed from 'the introducer' to someone else
in a document signed by the introducer, then the association between the
YURL and the cognitive context of the introducing message is intact with
some cryptographic strength, as strong as the signing of the introducing
context.  It's hard to fudge inside the signed document.

Compromise of the introducer's private key, F2F bogosity, and such threats
still hang over us but it's easier to trust that they haven't happened than
simply re-writing a web page in some ISPs caching proxy.

Is that close?  Warm?  Above absolute zero?

Al

>At 12:06 AM 7/16/2003  Wednesday, Mark S. Miller wrote:
>
>
> >>Ed Gerck wrote:
> >>
> >>>[...] Spoofing and
> >>> MITM become quite easy to do if you trust an introducer to tell you 
> where to go.
> >
> >At 03:52 AM 7/15/2003  Tuesday, Ben Laurie wrote:
> >>What is a CA other than an introducer?
> >
> >This is exactly backwards. Use of CAs are vulnerable to MITM attack by 
> prior
> >arrangement -- by enabling the CA to mount such an attack. Both the CA and
> >the introducer are equally able to place themselves (or an agent of
> >themselves) in the middle, but when an introducer does it, *by definition*
> >it isn't a MITM attack.
> >
> >By definition? A CA certifies to Bob that the key K corresponds to some
> >entity (Carol) that Bob might know by the name N. (In PGP, N is allegedly
> >Carol's email address.) Unaddressed and assumed away is the issue of how 
> Bob
> >came to know name N. In actuality, someone (Alice) who already knew Bob and
> >Carol told Bob about Carol as part of a message. This message gives 
> semantic
> >context to the introduction, so that Bob may choose how to regard Carol 
> based
> >on his relationship with Alice, and based on what Alice said in her
> >introduction message. This account is equally valid among objects in a
> >pure object programming system, and among people as described by 
> Granovetter.
> >
> >In the absence of someone like Alice performing such an introduction, how
> >did Bob come to know about Carol's existence? How did Bob come to regard
> >Carol with any prior properties (i.e., properties not derived purely by
> >interaction with Carol)? The Y property follows simply from the observation
> >that authenticity of initial introduction is simply for Bob to
> >know that the Carol he's talking to is the Carol Alice meant to introduce
> >him to; and that the introduction message as received is that which was 
> sent
> >-- that Bob can take into account what Alice says about Carol. By 
> definition,
> >Alice can't introduce him to an inauthentic party, because whoever Alice
> >introduces him to, that's who Alice introduced him to.
> >
> >However, between machines Alice can only send bits, not direct connections.
> >If Alice's message includes a conventional (non-self-authenticating) name N
> >for Carol, then Bob must resort to other means to attempt to ensure that 
> the
> >Carol he's talking to is the Carol Alice meant. Since these means rely on
> >third parties (typically CAs) for their correctness, they are vulnerable to
> >misbehavior by these third parties -- it is they who can mount a MITM 
> attack,
> >leading Bob to connect to someone other than who Alice meant. If Alice's
> >message instead designates Carol with a self-authenticating designator,
> >like a public key fingerprint, then there is no remaining MITM problem.
> >
> >Of course, Alice can still betray whatever trust Bob has in her by 
> introducing
> >Bob to Carol-the-thief saying "Here's Carol-the-saint". But this simply 
> means
> >that Bob's trust in Alice was misplaced. Since Bob only knows about Carol
> >from Alice, he should not invest any more trust in Carol than the trust he
> >has in Alice, no matter what assurance Alice includes as context in the
> >introduction message. If Carol fails to live up to Alice's statements about
> >her, that should tarnish Alice's reputation just as Alice's direct 
> misbehavior
> >would. (After all, for all we know, Carol may be a front for Alice.)
> >
> >Of course, the world isn't purely electronic. And by this analysis, the
> >purely electronic world cannot bootstrap trustable connectivity from
> >scratch. By this logic of introduction, only connectivity begets
> >connectivity, and most of the existing trusted connectivity in the world in
> >non-electronic. That's why PGP users often put their fingerprints on their
> >business cards -- at our current level of technology, the face to face
> >interaction where cards are transferred are beyond feasible MITM attack by
> >anyone other than the Mission Impossible team. Alice the physical person
> >introduces Bob the physical person to Alice's electronic presence Carol. 
> The
> >card is the message. Bob can't know that it's really Alice's electronic
> >presence that's been "named", but he know that it is the electronic 
> presence
> >that person at the party wanted Bob to think was herself.
> >
> >Much of the prior human connectivity that we must leverage is held together
> >by knowledge of human names in a multitude of name spaces. This means we
> >still have the correspondence problem CAs were built to solve, and which
> >SPKI and Pet Names do solve in a sound fashion. See
> >http://www.erights.org/elib/capability/pnml.html .
> >
> >With one further primitive, equality, we have reached the limits of what is
> >possible for key distribution.
> >
> >If Dana also introduces Bob to Carol by using Carol's same
> >self-authenticating designator K, Bob can compare these and see they are 
> the
> >same. As a result, the prior properties with which he may regard Carol are
> >the union of the prior properties resulting from Alice's introduction and
> >that resulting from Dana's introduction. Further, Bob knows that Carol is
> >*mutually acceptable* to both Alice and Dana as who they meant in their
> >respective messages. Depending on the specifics, this may enable Bob
> >to trust Carol in ways that he does not Alice or Dana individually. This
> >enables corroboration. See
> >http://www.erights.org/elib/equality/grant-matcher/index.html
> >
> >All key distribution schemes are repeated applications of introduction
> >and corroboration, and nothing more is possible. Once this is realized, 
> many
> >bad key distribution schemes should become obviously bad.
> >
> >
> >----------------------------------------
> >Text by me above is hereby placed in the public domain
> >
> >        Cheers,
> >        --MarkM
> >
> >
> >---------------------------------------------------------------------
> >The Cryptography Mailing List
> >Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
>
>
>----------------------------------------
>Text by me above is hereby placed in the public domain
>
>         Cheers,
>         --MarkM
>
>
>
>----------------------------------------
>Text by me above is hereby placed in the public domain
>
>         Cheers,
>         --MarkM
>
>_______________________________________________
>cap-talk mailing list
>cap-talk@mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk

_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]