Announcing httpsy://, a YURL scheme

[Perry E. Metzger]

Ian Grigg <iang at systemics.com> writes:
> "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 -

What are you talking about?

I'm talking about replacing keys. Almost every protocol out there lets
you replace your keys at periodic intervals. Proper key hygiene
dictates that you change your keys often enough that the security harm
caused by disclosures or cracking is mitigated. Using this system,
they're basically frozen forever because everyone on earth expects
your HURL, er, YURL, to remain constant.

Since when is proper key hygiene "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.

Our evidence in the long run is that users are extremely poor at
handling security decisions like this. They don't understand the
security implications of their actions. If the goal is to improve
security over the existing system, especially because users tend to
get spoofed, this doesn't succeed.

> In comparison to the CA regime,

I think that's a poor point of comparison. It is like saying "I don't
like bad system A, so note how bad system B is so much better".

There are fine ideas out there on how to handle this sort of thing
that don't involve bad ideas at all -- I don't see why I should pick
a bad way of doing things 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.

I do. You start by looking at document A. You click on it and end up
at document B at another site. Then you click on it and end up at
document C at yet another site. Before long, you're trusting documents
that are very, very far from the original HURL, er, YURL you started
with, and you have no idea what your trust relationship with them is
at all. It is a recipe for serious trouble. "Hmm, this claims to be
www6.amazon.com and I somehow got there by an unknown sequence of
clicks -- guess I'll give it my credit card number."

SFS has the same problem -- by the time you've cd'ed into a few
directories on a few file systems, you no longer have any idea what
your trust path is at all.


> > 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.

So in that sense, we end up with the worst part of the SSH model --
you get a message that a key has changed and you have no idea why or
if it is legitimate so users ignore it. "Not an improvement."

> > 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.

That paragraph is completely incomprehensible to me.

Perry

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