Announcing httpsy://, a YURL scheme

[Ian Grigg]

Ed Gerck wrote:
> 
> >From your URLs:
> 
> "The browser verifies that the fingerprint in the URL matches the public key provided by the visited site. Certificates and Certificate Authorities are unnecessary. "


I agree that the last part is a little aggressive.
"Unnecessary" is so ... final.  What this does is
to place the URL as the point of trust, rather
than placing a CA at the point of trust.  It also,
as an aside, allows the CA to remain as a upstream
point of trust.  (Or, so I read it?)

> Spoofing? Man-in-the-middle? Revocation?
> 
> Also, in general, we find that one reference is not enough to induce trust. Self-references
> cannot induce trust, either (Trust me!).

I'm not sure whether the intention is to allow
filtering of URLs and caching of hashes found
therein!  That seems the obvious intention; to
scatter a thousand URLs out there, and by the
time the browser has a desire to upgrade the
connection, it has already established a record
of hashes.

Is that the case, Tyler?

> Thus, it is misleading to let the introducer
> determine the message target, in what you call the "y-property". Spoofing and
> MITM become quite easy to do if you trust an introducer to tell you where to go.


Essentially, trust is established at the point of
"when you trust this URL, you can trust the connection."

That's quite valuable.  It separates out the trust
into two separate protocols, which makes both much
stronger.  In fact, I think it is essential for a
sound security model.  It's what makes SSH so efficient,
and it's what makes SOX so simple.  Obversely, I
suspect, but am not totally convinced yet, that it
is at the root of SSL's issues as a protocol.

It can be seen by inspection that the second part;
booting from the URL to a secured connection, is, on
the face of it, viable.

How is the URL trusted, is the big question.  If
the answer is that it is no less trusted than the
ordinary http URL, and less trusted than a https
URL, than that's still valid, and a vast improvement
on today's situation of 99% untrusted browsing.

> Not that I believe CAs are essential (I don't, for reasons already presented in '97),
> but unless the issues of spoofing, MITM and revocation are adequately handled
> according to a threat model that is useful, communication cannot be considered
> secure.

Well.  I worry that your criticism rides on a circular
assumption.

To unwind, it is a statement of definition that if the
threat model is not covered, then the communications
are insecure.  If the threat model *is* met, then the
communications are secure.

So the question devolves to "what is the threat model?"

1. Clearly, the threat model does not include MITM.  That's
quite practical in today's world.  See my rants on the
subject for my logic.

2.  Revocation of a private server key seems an unusual
need.  Granted, in a PKI of some dynacism (?), this would
be a real shortfall.  But for a website server, I don't
see the need for revocation.  It's not as if private
keys are stolen anytime, much, and if the server cert
changes for operational reasons (end of year, etc),
then that moves the YURL into the domain of "broken
link."  So writing revocation out of the threat model
seems like a practical decision.

3. Spoofing, however, seems unavoidable as an issue.  It's
trivially easy to construct a link which purports to
be something else.  All the YURL does is to prove that
it is the real underlying link, without helping any
in the spoofed presentation problem.

That is, if I mail a million BoA account holders with
my YURL and some standard text, it will work as well
as if I didn't use a YURL, so adding the security
aspect might create a false expectation, and nothing
more!

Is the YURL considered to be a generic replacement for
links?  If so, I don't see how it changes the big failure
of secure browsing, which is the spoof attack.

Mind you, I would, in the spirit of addressing the real
security agenda, applaud any attempt to propose fixing
up the current bad-and-getting-worse situation.  It would
seem that sharing and spreading the hash of server certs
is definately a viable direction.

-- 
iang

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