Announcing httpsy://, a YURL scheme

[Ian Grigg]

"Perry E. Metzger" wrote:

> 1) The "YURL" makes key management and replacement effectively
>    impossible.

Well, I would have said it suggests a different
method.

Instead of regimented, hierarchical and fixed
key management - an idea of poor track record -
the key management issue here is pushed back to
the user & client.  It relies on browser assistance
in caching, and correlation between many introducers.

In comparison to the CA regime, there is additional
trust from the people who send out URLs with this
information embedded.  If you trust the introducers
then you can trust their information.  That doesn't
mean that it is perfect, it just adds more security
than an absence of information.

I grant you that an either/or approach is a tough
sell.  The YURL would be improved if it explicitly
included a method to reference the hash of a CA-cert,
and to incorporate that additional information into
its trust display to the user, IMHO.  More information
is generally better.

(In comparison to the HTTP regime, as opposed to the
HTTPS regime, this is much better method than having
no trust at all.)

> 2) It leads to situations in which you have no way to know what sort
>    of trust relationship you have for the documents you're looking at.

I don't understand this.  If Alice sends Bob a URL with
a hash in it, then Bob can apply the same trust that
he would apply to anything that Alice sent.

The same metric applies to an attachment.  If Alice sends
some thing.exe around, Bob will have the same procedure
in deciding whether to trust it as not-a-virus, or in
how to increase your level of trust.

Alternatively, if the URL with hash arrives from some
unknown source, yes, this is untrusted!  But, it is
no more untrusted than the previous scenario sans hash.

How can that be a problem?  We've gone from untrusted
to untrusted in one seamless step.  I wouldn't pay
for that as a feature, but I wouldn't grumble about
it either.

> 3) It is impossible for people to determine that a "YURL" actually is
>    what it claims it is, given that most people can't actually
>    remember one hash, let alone large numbers of them, etc.


Right.  I don't think the YURL really meant for
people to read the things.  It could be better
explained, the browser has to record and correlate
the hashes.

Which is, really, how it is now for most use cases,
as we see long complex URLs all the time (click on
amazon for example) and without the browser to
interpret these things, we in userland are lost
already.

> Those are just some of the more obvious issues.

I think it is a mistake to compare the URL+hash
idea to some existing security model such as is
purported by, for example, https.  It really sits
closer to raw HTTP - which is where most of the
live usage is, and where all of the problems lie.

>From that pov, it adds security, in absolute and
relative senses.

-- 
iang

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