Announcing httpsy://, a YURL scheme

[Perry E. Metzger]

Tyler Close <tyler at waterken.com> writes:
> On Monday 14 July 2003 20:04, Perry E. Metzger wrote:
> > Tyler Close <tyler at waterken.com> writes:
> > > I have demonstrated the theory behind YURLs by providing an
> > > implementation, the Waterken Browser, and by explaining how two
> > > other widely used systems implement the theory.
> >
> > Having an implementation demonstrates nothing whatsoever about
> > security -- many implemented systems are, after all, insecure.
> >
> > If you wish to demonstrate the security of your system, one would
> > expect a detailed explanation of the threat model you're trying to
> > address, and why those threats are thwarted by the design.
> 
> The security properties enforced by a YURL implementation are
> clearly defined at:
> 
> http://www.waterken.com/dev/YURL/Definition/

I'm afraid they aren't clearly defined at all. I've read the page, and
I must admit that as peripherally interesting as it might be, for
example, for you to introduce us to the sociologist Mark Granovetter's
work on diagrams, etc., and as nice as it is for you to have lots of
references listed, you've not explained your threat model in a way
that I readily understand.

> If you doubt the value of this security model, I point out, as
> empirical evidence only, that SSH and PGP use the same security
> model.

Since I can't derive your security model from your short and not
particularly clear description on your web page, I'm afraid I can make
no such assessment at all.

I will say this: neither PGP nor SSH include key ids in destinations
as you do. I say "ssh some.host.com", not 
"ssh verylongnothumanrememberablestrignthatcanbeeasilyspoofed".
PGP does not force you to include a hash of someone's key in their
mail address.

The only thing like what you've done that I'm aware of is the
so-called "self-certifying file system" stuff (sfs), in which file
paths contain embedded hashes. I've seen similar schemes proposed
elsewhere. I wouldn't call them similar in their security model to PGP
or SSH. That is not to say, btw, that I love PGP and SSH's security
models either, but they appear to be rather different.

I must admit I don't particularly like "embed the hash in the thing
the user sees" schemes. There are lots of problems with them --
they're completely brittle with respect to key changes, and they work
very poorly with users who don't understand the security properties of
the system they're dealing with. Heck, I'm not sure they work well
with sophisticated people either.

> I asked Ed to provide an attack on the implementation because his

It isn't his job to attack your implementation, any more than it is up
to someone reading a paper for "The Lancet" to come up with proof the
author is wrong. It is up to the claimant to present a clear, concise
and straightforward summary of their work so people can assess it and
so that someone reasonably skilled in the field can come to
conclusions about its merits. At that point, it might be interesting
for someone else to try attacking it, but no one is under any
obligation to do so.

> arguments lacked focus and clarity.

I'm afraid that, in this instance, I'm not sure your web site contains
those things either.

> For example, he referred to MITM without specifying any details,
> such as what middle.

Well, I'll say this -- it seems trivial to substitute one HURL, er,
YURL, for another. I have no real way of knowing that I'm talking to
the actual server and key I want because I don't really know that the
HURL er YURL I've been given is valid in any way, and it is too
difficult for humans to detect a change in a hash by eye.

I've got lots of similar problems with the scheme.


-- 
Perry E. Metzger		perry at piermont.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com