Subject: [therightkey] Will the real RPF please stand up?

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jan 2012 14:07:14 -0500

This is a site I have been using for over a year now.

How would I as a regular Internet user be expected to work out which
site is the real one? This could be site napping or it could be
phishing fraud.

I tend to suspect that the email is telling the truth, but it is also
possible that it is a phishing attack.

I do not particularly want to log into either site right at the moment.

DANE would be no help whatsoever. In fact as currently proposed it
would require browsers to only consider therpf.com as valid.

But some of the other proposals made could provide important
information. For example, Perspectives and Convergence might allow
continuity to be established through the certificate continuity.
Depending on the details of the implementation, SK and CT

---------- Forwarded message ----------
From: [email-masked] <[email-masked]>
Date: Thu, Jan 26, 2012 at 1:33 PM
Subject: the Replica Prop Forum - Update to Critical Notice
To: [email-masked]

Hello hallam

Two weeks ago we wrote to tell you the unfortunate news that our
domain name, therpf.com had been stolen.  A considerable number of you
have written back to ask for an “official” update, so here you go!

While we have been able to secure our own server where we are
temporarily hosting the RPF (thereplicapropforum.com) we have NOT been
able to regain ownership of therpf.com at this time.

To be clear, therpf.com is STILL in the hands of the hacker who has
setup a site which looks almost identical to the real site.  Do NOT be
fooled.  therpf.com may look like the real site, but is still under
the control of the hacker!

The real RPF is still being temporarily housed at thereplicapropforum.com

Some of you have expressed a concern about how you know if these
communications (like the one you are reading now) are legitimate.  To
verify, you can go to our facebook page, twitter page, our facebook
group, or even my personal facebook page to verify and learn more.
Below are links to each.

Official RPF Facebook page:  http://www.facebook.com/therpf
Official RPF Facebook GROUP page:  http://www.facebook.com/groups/therpf/
Official RPF Twitter page:  http://twitter.com/replicaprops
My personal facebook page: http://www.facebook.com/artandrewsjr

Our legal team is getting close to completing our dispute of the
illegal transfer of therpf.com and with any luck, we hope to have that
domain back in our possession in roughly 30 days or so, but the legal
process is a slow one and this has been further complicated since it
is also an international issue.

When we do get the domain back, we will email you again to let you
know it is safe to return to therpf.com but until that time, please
continue to use thereplicapropforum.com and avoid therpf.com.  We are
still here, doing what we have always done; sharing our love for
props, costumes and models and talking about the latest movies and
goings-on in the entertainment industry.

On a final note, hundreds of you have come forward to help support
this community in numerous ways.  Thank you for that support!  Your
support has shown your devotion and love for this community and we
really appreciate it.  Like you, we love this community and are
looking forward to continuing to serve you in the future!

Sincerely,
Art
www.thereplicapropforum.com … for now…

-- 
Website: http://hallambaker.com/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 26 Jan 2012 14:35:13 -0500

Illegitimate transfers are out of scope.  From the point of view of the DNS, an illegitimate transfer is indistinguishable from a legitimate transfer.

The only thing technology could do for this case is allow the web site to tell customers "I'm not planning to change anything in the next N days".  So, for instance cached DANE records or key pinning.  First-time visitors with nothing cached are out of luck.  Maybe you could have something of an observatory system for sharing the sort of information that other people have cached.

--Richard

On Jan 26, 2012, at 2:07 PM, Phillip Hallam-Baker wrote:

> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 26 Jan 2012 15:06:52 -0500

Thanks to Phillip for raising this point.

> Illegitimate transfers are out of scope.  From the point of view of the DNS, an illegitimate transfer is indistinguishable from a legitimate transfer.

eh?  The whole point of this discussion, as i understand it, is supposed
to be to figure out a way that users and site administrators can tell
when something illegitimate is going on and have some protection from
attack.

Saying that a fraudulent or coerced DNS transition is "out of scope"
seems equivalent to saying "make the users and admins vulnerable to
attacks via DNS", in which case we might as well give up.

DNS is certainly not a shining beacon when it comes to resistance to
fraud or coercion.  Let's not make it a single point of failure.

> The only thing technology could do for this case is allow the web site to tell customers "I'm not planning to change anything in the next N days".  So, for instance cached DANE records or key pinni…

These are reasonable examples of things that a "right key" protocol
could do.  There are probably more ideas people could come up with.  Why
would these suggestions be out of scope?

	--dkg

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 26 Jan 2012 16:06:53 -0500

> fraud or coercion.  Let's not make it a single point of failure.

I think it would be really nice if we would make some distinctions
among different phænomena.  It seems to me to be absurd to collapse
attacks on the registration side of the DNS and attacks on the
resolution side of the DNS as though it's all "the DNS".  To begin
with, a significant number of registrations in the DNS don't share a
common mechanism for registration, so making sweeping generalizations
is going to be a waste of time.

That said, it's clearly true that TLSA records in a zone do you no
good if you are mistaken about who is operating the zone.  It does
seem to me that it would be possible to use multiple channels to check
whether a given name is operated by the person you think it is, and
that a mechanism to do such checking is in-scope on this list.  (I
also wonder whether what's going on in REPUTE might be helpful.)

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jan 2012 16:15:22 -0500

Maybe to you, but not to me. If we are going to do any good we have to
deal with all the problems and not just a few cherry picked problems
that we think should be the ones people are worried about.

As I pointed out, there is actually quite a bit that technology can do here.

This is a real problem that people have been complaining about for years.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jan 2012 16:34:07 -0500

>From a security point of view it is the security of the system that
matters, not the security of the individual components.

The S in DNS stands for System.

If a system is going to be robust in practice it has to take account
of all possible sources of error including administrative incompetence
and user error. Security that only looks at malice is brittle
security.

Getting defensive about problems is not going to solve them.

---

From: David Conrad <[email-masked]>
Date: Thu, 26 Jan 2012 13:43:43 -0800

On Jan 26, 2012, at 1:34 PM, Phillip Hallam-Baker wrote:
> and user error.

I'm curious: where do you draw the line?  Should routing system security be included?  Email security (since many transactions relating to DNS zone administration occur via email)? Telephone? Etc.

> Security that only looks at malice is brittle security.

Security that looks at 'all possible sources of error' seems to me to be a halting state problem

Regards,
-drc

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Jan 2012 22:52:34 +0100 (MET)

David Conrad wrote:
> 
> Phillip Hallam-Baker wrote:
> >
> I'm curious: where do you draw the line?  Should routing system security
> be included?  Email security (since many transactions relating to DNS
> zone administration occur via email)? Telephone? Etc.
> 

Drawing a line amounts to sticking your head in the sand.

A chain is only as strong as its weakest link, and aside from
wanna-bees, determined attackers are *not* going to attack the
strong pieces of the technology, but turn the weak parts or
the links between.

Using DNS names for authentication is the folly here.  If we believe
that using DNS names for authentication, then we need to fix *all*
parts of the technology, including the adminitrative procedures
for managing/delegating DNS names.

-Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 26 Jan 2012 17:02:09 -0500

> for managing/delegating DNS names.

Ok, what names *should* we be using?  Maybe we should use names that people claim by presenting their drivers' licenses?
<http://dmv.ca.gov/pubs/newsrel/newsrel11/2011_26.htm>
Passports?
<http://www.usimmigration.com/selling-fake-passports.html>

Can you point to an identity system that doesn't have layer-9 vulnerabilities?

Domain names are names like any other name, except they have some nice features: Hierarchical storage and you can use them to look stuff up.  ISTM that this group will have a win if they can come up with a good way to authenticate domain names, possibly patching over some of the layer-9 weaknesses.

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jan 2012 17:09:49 -0500

Of course routing security is considered.

The reason that you want TLS in the first place is precisely the fact
that routing can be compromised (ranging from WiFi evil twin up to BGP
attack).

Security has to look at all sources of error but that does not mean it
has to eliminate them. Security is risk mitigation and not risk
elimination - as some of us were saying before a certain well known
person wrote a book making that claim.

In this particular instance there is still going to be a residual
routing security risk with respect to denial of service so BGP
security remains an issue, albeit one that is rather different to that
the proposals attempt to address.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 26 Jan 2012 17:10:32 -0500

> Getting defensive about problems is not going to solve them.

I'd like to know what you thought to be defensive in what I said.  I
was merely trying to point out that we need to make distinctions about
pieces of the system if we are not to trip over ourselves trying to
solve multiple problems at once.  ("All possible" is, frankly, a
preposteous scope.  Universal quantification over possibility claims
lead to metaphysical problems.  I'd prefer to talk about practical
methods to secure systems.)

DNSSEC and DANE are both designed with a particular purpose in mind:
ensuring that you got the data you should have received from the
(formally) correct server for that data.  Pointing out that those
techniques don't solve some other problem -- in this case, that the
technically-correct server might not be the socially- or
intentionally-correct server -- is at least an equivocation.  That is
not to say that those other issues are unimportant, and I didn't
suggest they were.  On the contrary, I think they are important and I
think we need to think about them.  But those other issues are not
evidence that DNSSEC and DANE don't or won't work.

We'll never get anywhere if we treat distinguishable problems as
though they're one big lump.  I think calling the entire lump of all
the ways that data might get into the DNS plus all the ways you might
look things up in it "the DNS" obscures distinctions that are
extremely useful in thinking about the behaviour we want, and I cannot
see any benefit in talking about the entire system without at
the same time talking about the different parts and how those parts
affect the overall security.  It's like talking about the etiology of
disease in mammals: maybe you can learn something from the
generalization, but the particular disease and mammalian species is
more likely to yield paths to useful inquiry.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Chris Palmer <[email-masked]>
Date: Thu, 26 Jan 2012 14:10:55 -0800

> Security that looks at 'all possible sources of error' seems to me to be a halting state problem

As security engineers, our role is to (a) reduce the number of
entities we trust; (b) reduce the extent to which we trust the
remaining trusted entities; and (c) determine the trustworthiness of
trusted entities.

This list is about, "We can do better at those three things." That's
hardly saying, "Let's solve the halting problem."

Having certificates or public keys in the first place are great at
doing (a), when they work. For example, if you know you've got the
right key, you no longer need to trust DNS or BGP or TCP. CAs are an
attempt to do (c). The proposals that this list is to discuss are
further attempts to do (c) — even if, perhaps, the email system is
compromised.

So, yes, all those things are and should be in scope.

By contrast, some things are clearly out of scope, such as host
integrity. (Other efforts are working on that problem, and they can
indeed succeed at incremental improvements in (a), (b), and (c)
without exploding to become the halting problem.)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jan 2012 17:11:59 -0500

As I said in the original post, look at this problem and then ask
yourselves how Perspectives, Convergence, SK and CT might help solve
it.

I can see the potential for leverage in all four schemes since they
all provide a means of persisting information over time.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jan 2012 17:21:35 -0500

> remaining trusted entities; and (c) determine the trustworthiness of

Really?

I prefer trying to help people manage risk. People have assets that
they would like to protect. What matters to them is

1) The cost of protecting those assets (financial and non-financial)
2) The value of those assets (financial, human, etc.)
3) The reduction in risk that is achieved

Obviously it is good to be able to measure those things but I am
pretty sure that reducing the number of trusted parties is not a goal.

A system with fewer trusted parties may have greater risk or less risk
than one with more.

> without exploding to become the halting problem.)

Since (1) the four proposals to date all look to me to represent
logical extensions of our Anti-Virus product and (2) the CA
infrastructure also supports code signing, I think host integrity is
quite likely to be relevant.

That does not mean we will eventually build something that can be used
for host integrity protection, but I am pretty sure that there is a
lot of useful experience to tap there.

---

From: Chris Palmer <[email-masked]>
Date: Thu, 26 Jan 2012 14:35:39 -0800

>> remaining trusted entities; and (c) determine the trustworthiness of

Yep.

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Jan 2012 23:42:51 +0100 (MET)

Richard L. Barnes wrote:
> > in using DNS names for authentication, then we need to fix *all*
> Ok, what names *should* we be using?
> Maybe we should use names that people claim by presenting
> their drivers' licenses?

The task of having to fix *all* parts of the chosen technology will be
independent from the identity system that we choose.

Commercial CAs seem to have some amount of success in convincing
businesses that EV-certs are more trustworthy than DV-certs,
and one of the reasons might be that their failure mode is not
tied to the DNS registration/administration procedures alone.
(i.e. a combination of two identity systems).

I'm not aware of any secure identity system (if one existed, everyone would
be using it and we would not constantly be inventing new ones).

The *existing* security of those that currently exists are based
on a trade-off resulting from a risk assessment, trying to keep
the cost of breaking it above the value of the protection, so
it is effectively good-enough to be economically unattractive
to attack (Coasean Floor), combined with the hope, that the number
of attacker who do are not economically motivated, is so small
that they can be neglected.

Think of counterfeiting of cash money.  There is no such thing as
a perfect counterfeiting protection.  Protections are "good enough"
when the economic cost of counterfeiting a certain unit of cash money
is higher than economic value of that unit of cash money itself.

> 
> Domain names are names like any other name, except they have some
> nice features: Hierarchical storage and you can use them to look
> stuff up.  ISTM that this group will have a win if they can come
> up with a good way to authenticate domain names, possibly patching
> over some of the layer-9 weaknesses.

DNS, and the adminstrative procedures for registration/delegation/management
was not designed with a high degree of trustworthiness in mind.
Personally, I strongly believe that DNS should remain fast, scalable
and affordable.

Trying to make DNS much more trustworthy would mean a price hike of
the fees of more than a magnitude for everybody.  I can imagine that
some companies in the DNS business would appreciate the new business
opportunity to multiply their revenues and rake in huge amounts of money.

But charging a magnitude higher fees for hundreds of millions of
domains in order to make DNS-based authentication more trustworthy
for some ten thousands of domains where it is actually needed
bears some resemblance with scam.

I strongly believe that some level of "pinning" information from previous
authentication and using it to verify successor authentications would
significantly reduce the attack surface without requiring redesign
of the entire infrastructure.

-Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 26 Jan 2012 17:55:01 -0500

>>> remaining trusted entities; and (c) determine the trustworthiness of

+1  

One of the better definitions I've heard.  I would question whether (c) is even in scope; seems like a relying party function.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jan 2012 18:03:53 -0500

It is nonsense.

Let us consider a Tier 6 security regime applied to management of a CA:

Separation of duties - increases the number of trusted parties
No sequential access - increases the number of trusted parties
No lone zone - increases the number of trusted parties.

Those are all NSA/GCHQ doctrines. I am pretty sure that they
understand security engineering at some level.

People need to stop talking about links in chains. If you have a
serious security architecture it does not look like a chain, it does
not have a single point failure mode.

---

From: Chris Palmer <[email-masked]>
Date: Thu, 26 Jan 2012 15:10:53 -0800

> No lone zone - increases the number of trusted parties.

But they can reduce the extent to which you must trust any one entity,
and can make it a bit easier to determine their trustworthiness (such
as by making them easier to audit). And that can be a net win.

---

From: Ralph Holz <[email-masked]>
Date: Fri, 27 Jan 2012 00:15:37 +0100

Hi,

> understand security engineering at some level.

But can they be applied to, say, current X.509 PKI? I doubt that.

> not have a single point failure mode.

This seems too high-level and abstract to have a meaning. There seems to
be a chain in every "security architecture" (for whatever that may be).
Just think of work flows - these are inherent to any "architecture", and
work flows are chains.

Ralph

PS: My problem with the word "architecture" is that today it's mostly
used in publications when the authors just mean "something we thought up
for our little problem". It's used so often it's almost meaningless.

-- 
Dipl.-Inform. Ralph Holz
I8: Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 26 Jan 2012 18:20:14 -0500

Those are all (b).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jan 2012 18:21:41 -0500

In other words, they mitigate risk.

If we talk in terms of risk and risk alone as I proposed we can put
numbers on things and use that as a basis for an objective comparison
of the schemes.

You have three separate degrees of freedom and no principle to compare
them by so putting numbers on your scheme isn't possible.

---

From: Ralph Holz <[email-masked]>
Date: Fri, 27 Jan 2012 00:25:07 +0100

Hi,

> 2) The value of those assets (financial, human, etc.) 3) The
> reduction in risk that is achieved

The trouble with the risks we're facing it that they are extremely
unlikely, yet have a high impact. If you're arguing that risk management
does not lead to the conclusion "fewer TTPs", you need to show how you
get to that conclusion.

Take the few numbers we have. 150+ recognised root certificates in a
browsers, distributed over 50+ organisations (I'm referring to Mozilla).
Exact numbers may be higher, but depend on how you count. Yet both Nasko
Oskov and Ivan Ristic (and actually, our group, too) have shown that
most of these TTPs are not needed. Just one or two handful of TTPs have
issued 95% of certificates. Considering the high impact, the conclusion
that I view as more likely is that less TTPs in X.509 is a good idea.

Of course, if you're arguing you actually want to move away from X.509
and towards, say, SK, the story may be different.

Ralph

---

From: David Conrad <[email-masked]>
Date: Thu, 26 Jan 2012 15:26:10 -0800

> Drawing a line amounts to sticking your head in the sand.

Or a realization that it isn't realistic to try to solve "all possible sources of error".

> If we believe

That isn't even close to "all possible sources of error".

You would seem to draw the line at "administrative procedures for managing/delegating DNS names" (if DNS is to be used).  PHB would appear to draw the line _much_ further out.  I'm trying to understand what the scope of this discussion is (perhaps only to try to figure out if this is a philosophical discussion or actually trying to get something done).

Regards,
-drc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jan 2012 18:47:20 -0500

> But can they be applied to, say, current X.509 PKI? I doubt that.

Of course they were, why do you think I raised it in the first place?

Separation of duties is essentially what SK and CT are providing.

---

From: Martin Rex <[email-masked]>
Date: Fri, 27 Jan 2012 00:56:50 +0100 (MET)

> "all possible sources of error".

If a secure identity system existed, we would be using it.

If a secure identity system could be invented, it would have been
invented by now.

So far, the best known approach is to look at *all* parts of the
system individually, and perform risk management for it,
i.e. ensure that the cost of breaking it is sufficiently high
that the entire system amounts to a good-enough trade-off.

> You would seem to draw the line at "administrative procedures for
> managing/delegating DNS names" (if DNS is to be used).

The line in the above statement is the circle aroud "*all* parts",
which leaves no parts of the system on the other side of that line.

But "fix" may have been misleading here.  It was meant in the sense
from above: ensuring for each part individually that the cost of
breaking it is high enough that the resulting system amounts
to a good-enough trade-off.

The EV-certs approach is in principle correct: those who want the
extra trustworthiness should bear the additional costs necessary to
ensure that trustworthiness.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jan 2012 19:15:46 -0500

The way I was taught to do security analysis is you start off with
everything on the table and look to identify all possible sources of
risk. You do that by identifying assets, the risks against those
assets etc. etc. It is an iterative process and it is frequently
useful to work in both directions, since considering attacks and
generalizing them to threats often identifies risks and often assets
that you might not otherwise have realized were involved.

At the end of the process you then consider relative importance of the
risks, there are to issues here, one is the probability of the risk
being realized, the other is the consequence. Here we are dealing with
a set of risks that were very low probability when the serious attacks
were mostly motivated by money. Now the observed incidence of those
attacks is going up and the motive is often political so raising the
cost of the attack does not necessarily provide a deterrent.

This is an objective process. There is no risk of 'philosophy'.

Here we have people who are saying that one threat 'is' out of scope
(wrong see below) despite a very high observed incidence rate when
another threat realizing the same risk is of paramount importance
despite a negligible incidence rate.

If people want to talk about the scope of this list, they should first
read the proposal I wrote when I requested it be created. Stephen
appended it to the announcement.

It is one thing for people to argue what the scope SHOULD be. But I
know what I wrote.

---

From: Martin Millnert <[email-masked]>
Date: Fri, 27 Jan 2012 02:56:40 +0100

> remaining trusted entities; and (c) determine the trustworthiness of

I'm trying to fit the trust mobility ideas behind Convergence into this
picture, plus, the mentions on this list of having a non-boolean
definition of trust/no-trust - which I found quite interesting.

Guess they're all c) in this case?

> further attempts to do (c) — even if, perhaps, the email system is

Drilling down a little, what about: 
  s/if you know you've got the right key/if you are 87% sure you've got
the right key/ ?

Intuitively(*) to me, having a way of offering a non-boolean (sum of)
trust to a user will have us end up with a system capable of offering
more total security than one without.

* I'm drawing intuition from Linear Programming optimizations vs Integer
Linear Programming optimizations, where boolean total trust corresponds
to ILP, which normally is harder to solve than LP. I'm not sure how my
cerebrum made this immediate association.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jan 2012 21:13:10 -0500

That reminds me of the Media Lab idea that binary choices are bad and
things should be specified as a range.

What we are doing here is attempting to reduce risk and risk is a
continuous variable.

In the simplest model of risk we merely consider if there is a non
negligible probability of a loss.
In the next model of risk we might multiply the probability of a loss
occurring by the probable loss.
That is not completely accurate either since there is a range of
probable loss and a probability associated with each one and so we
might need to consider them as continuous functions
And even that does not capture everything as large losses are more
catastrophic than small ones.

The last seems to be what tripped up the financial markets. A 1% risk
of losing 100 billion is a loss of $1 billion on average. But nobody
can carry the insurance for a loss that size so when that 1% comes up
it is going to take down the whole system with it.

A useful definition of 'trust' is the ability to accurately quantify
risk. In this definition, saying a party or an application or a
platform is trusted means no more than that I am exposed to risk
should it default and trustworthy means no more than that the degree
of residual risk is known to be within acceptable bounds.

---

From: Ralph Holz <[email-masked]>
Date: Fri, 27 Jan 2012 11:21:14 +0100

Hi,

> Separation of duties is essentially what SK and CT are providing.

I thought you were referring to technical issues, like numbers of
trusted TTPs = CAs. I don't think your argument applies there.

Ralph

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 27 Jan 2012 07:59:01 -0500

> trusted TTPs = CAs. I don't think your argument applies there.

Separation of duties would suggest that we have two separate trusted
parties with somewhat different responsibilities and require both to
concur in order to establish trust.

This is essentially what the four proposals I described in the paper
attempt to do, albeit CT and SK attempt to limit the exposure to the
additional party cryptographically but even if that is assumed to work
as intended, the notary can still perform a service attack.

---

From: Jon Callas <[email-masked]>
Date: Tue, 31 Jan 2012 16:29:23 -0800

> One of the better definitions I've heard.  I would question whether (c) is even in scope; seems like a relying party function.

We should run screaming from (c). Not only do there be dragons there, but there be dragons even in saying what "trustworthiness" means. Surely this is not a real-world reputation system.

	Jon

---

From: Paul Lambert <[email-masked]>
Date: Tue, 31 Jan 2012 17:14:50 -0800

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Jon Callas
...
>> One of the better definitions I've heard.  I would question whether
>(c) is even in scope; seems like a relying party function.
>
>We should run screaming from (c). Not only do there be dragons there,
>but there be dragons even in saying what "trustworthiness" means. Surely
>this is not a real-world reputation system.
>
>	Jon

Yes! ... but, we can define "who we trust for what" ... who being a key, what being some Domain of Discourse with appropriate constraints.  

Trustworthiness as a probability or metric yields contradictory and nondeterministic evaluations.  

Paul

---

From: Martin Millnert <[email-masked]>
Date: Wed, 01 Feb 2012 03:15:40 +0100

> Trustworthiness as a probability or metric yields contradictory and nondeterministic evaluations.  

Paul, is this necessarily bad?

All three statements above are sort of correct IMHO. A slight
modification:
  "As security *protocol* engineers, we have to [...] and (c), give the
users the capacity and ability to enforce their own trust-policies, for
their own purposes, according to their own desires."

Let's go deeper.

I (still, thankfully!) have the ability to remove root CA's from
my /etc/ssl/cert when I see fit to do so. And I do so.  But it's
extremely cumbersome and obviously "does not scale".  Let's do better?
Obviously, not all users on the planet can by decree of a small group be
mandated to verify trust in the same manner, at least not very
successfully. The choice of what you want to trust has always been
there.

From this I can't say that I either fully - or not at all - trust any CA
in my root-cert store on an individual basis -- some are even there, not
because I trust them indefinitely, but because of a combination of
 a) my browser becomes full of extra clicks without them, 
 b) they do provide a varying-but-greater-than-zero % expectation that a
TLS-connection that validates to them can be reasonably expected not to
also be MITM:ed somewhere. 

This doesn't mean *I* have 100% trust in any of them.  These are
different things.

Adding to that: having multiple inputs to your trust policy generation
engine, as has been discussed here, can't possibly hurt the objective
here?  Similarly, having an output from this trust resolution engine
that motivates its calculation (according to your policy), can't hurt
either?

  configuration bar = list of various input sources;
  trust_policy_compile(policy foo, configuration bar) ->
trust_resolve_data[policy=foo]

(Policy and configuration may actually just be one and the same.)

Obviously, a computer program wouldn't work very well if a 67% trust
implies that it should proceed with a computation in 67% of the
instances:
  The validation result through my trust verification engine using
policy X ought to be that I either can (based on my policy!) proceed
with the computation, or, that I have to abort it because of a lack of
trust. 

  validate_with_policy(trust_resolve_data data, policy foo, certificate
bar) -> (valid|invalid, {details})

The policy can define things such as, a >X% fail-rate from
convergence/observatory (using convergence/observatory-configuration
foobar...) -> invalid cert verification, and list of root-CA's, etc.
Note that this does not at all exclude putting multiple certificates in
the handshake! That seems smart, for those who can afford the extra
bytes transferred.

So, perhaps having browser vendors and operating systems declare who The
list of trustworthy entities according to their Process is, is not the
best solution for all purposes?  Having defaults is fine, I guess, but
for all I care this entire apparatus could (successfully, overall, I
bet) be externalized to institutions dealing more solely with trust, and
individual users would then get the option to choose between these. The
feedback-loop this could provide is not without merit.
  For example, there appears to me to be a natural place for someone to
define these foo's, that users can use. And also [inputlist]
configurations.

Offline, people trust different things.  Would there be a
protocol/standard/method to model this in a more scalable way online, so
much better, I think.

Best,
Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 31 Jan 2012 22:35:09 -0500

I don't see the problem with defining the term 'trustworthy'

Risk = Cost imposed by likelihood of probable loss.
Trust = Confidence with which risk is assessed.
Trusted = An entity that is relied on to mitigate risk (whether
trustworthy or not).
Trustworthy = An entity that meets rational criteria for risk mitigation.

We could wordsmith the definitions, but I think we can probably agree
on the general principles.

The problems stem from the fact that risk is a very complex function.
It is not merely probability * probable loss since in a real world
situation both are continuous functions, I might suffer  $100 loss
with probability X, and a $1000 loss with probability Y and so on.

And it is not just the expected loss that is the issue but the cost
that expected loss would impose on my business. My probability of a $1
million loss might be 0.1% but the cost that potential imposes on my
business might be much higher than $1000.

I think we should also be able to come to agreement that even though
we can define the terms, we can't expect to come to precise
measurements, or even particularly satisfactory measurements. If we
could do that we would be in the regular business of insurance.

In particular, insurance companies have always avoided writing
policies on acts of war. The reason being that the probable losses
simply do not follow a predictable pattern. Losses due to theft and
even natural causes follow reasonably predictable patterns.

We are now dealing with politically motivated attacks and so we end up
with probabilities that don't fit a mathematical model and losses that
don't have a monetary value.