Subject: [kitten] On TOFU and metaphysics (Re: PKCROSS)

From: Nico Williams <[email-masked]>
Date: Thu, 1 Aug 2013 12:26:58 -0500

On Thu, Aug 1, 2013 at 11:31 AM, Josh Howlett <[email-masked]> wrote:
>>LoF/TOFU is not a central feature here.  It's just a side benefit that
>>one could do it.
>
> Understood (as a "side feature" :-)

I don't see how any PK-based protocol fails to have this feature,
whether anyone likes it or not (think: how many SSL/TLS
implementations have failed to do thorough certificate validation?
and even when they do, how many CAs have lied or been subverted?).
There's little point in pointing out that there are many cases where
LoF/TOFU is undesirable :(

And TOFU is a useful side feature.  I'd rather have it than not.  And
there are real use cases for it.  But we'd get it no matter what.  So
I score it as a plus.  Philosophically, TOFU is all we naturally have,
and any TTP system is just an attempt to scale up, with trust
inversely proportional to the size of the world you want to scale to,
asymptotically approaching zero.

>>If you want to scale to Internet scale then you kinda need trust
>>policies that are congruent with the DNS.  Now, that doesn't mean that
>>you can't have islands of higher trust.
>
> Sure. But those "higher trust" islands get manifested using a different
> mechanism from the mechanism used to manifest the "baseline" trust. I
> would prefer a more consistent architecture that didn't require this
> distinction.

Nothing requires that anyone's baseline be 'scale to the whole
Internet'.  The protocol does not (must not) dictate trust baselines;
I'd not propose otherwise.

>>To me this is no different than ABFAB's approach to federation.  If
>>it's good for ABFAB, it's good for Kerberos.
>
> Well, I disagree but let's not have that discussion here :-)

OK, sure, but then you say "you are correct for extant trust
management mechanisms for AAA infrastructures that are standardised
today", so which is it, and how could ABFAB do better? :)  (that's
rhetorical -- see below)

If you want to scale up trust infrastructure to the whole Internet
then you have to accept that some trust paths will be iffy.  It's an
unavoidable fact of nature.  It's not even a shortcoming of PK crypto.

Authentication and identification are metaphysical problems.

"Papers" and cryptographic equivalents are nothing more than a
trusted-third-party protocol for authentication/identification,
subject to all the usual problems, on-line and off.  Off-line we *all*
practice TOFU every time we meet someone new.  We happen to have great
biometric authentication devices that are difficult to spoof, but so
what?  We aren't omniscient, we don't know our peers' past; any
background checks are necessarily costly and imperfect, therefore the
vast majority of the time we use our also-amazing memories (in
conjunction with our senses) in a TOFU manner.  It should not surprise
us that on-line it's the same, but worse: because our natural
biometric devices don't work on-line and because we have so many more
peers on-line.  TOFU and TTP -- that's all we have, and all we can
ever hope to manage.

Nico
--

---

From: Josh Howlett <[email-masked]>
Date: Thu, 1 Aug 2013 20:59:31 +0000

>unavoidable fact of nature.  It's not even a shortcoming of PK crypto.

I agree with everything you say. There is, as you suggest, a spectrum of
iffy-ness and I certainly have no interest in eradicating or normalising
the natural iffy-ness that is inherent in different kinds of social
relations. I'm simply arguing that, for the spectrum of iffy-ness, we
should seek consistency in how we technically manage it, for as many trust
paths as possible, such that we can accommodate the spectrum of paths
(iffy or otherwise) within an operational framework that is usable for
administrators and users.

>TOFU and TTP -- that's all we have, and all we can
>ever hope to manage.

Amen!

Josh.

Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

---

From: Nico Williams <[email-masked]>
Date: Thu, 1 Aug 2013 16:23:14 -0500

> administrators and users.

I don't want a separate protocol for each use case.  This is how we've
ended up with a mess of protocols that must all be deployed
concurrently and at great cost.

The whole point of GSS and SASL is to abstract away those protocols so
that users can use the ones most appropriate to them.  But then too,
the whole point of Kerberos pluggable pre-auth (PKINIT, OTP, ...) and
kx509, and other bridges, is that we need to be able to reuse existing
infrastructure.

Closing the door to some feature in one protocol is not a proper
substitute for lack of policy/UI.  Implementations need to fail safe
in the absence of suitable policies/UIs, of course, and that's the
correct answer here.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 1 Aug 2013 16:24:13 -0500

> kx509, and other bridges, is that we need to be able to reuse existing

I should also add that protocols/bridges that allow for infrastructure
reuse are also easier to deploy/invest in than ones that don't.