Re: [Rats] Comments on draft-birkholz-rats-architecture-01

My framing for this is not binary, in this day and age of risk engines and machine learning. The relying party receiving the attestation is going to take whatever data is attested in as part of a decision that will probably involve other data such as transaction history and type. For example:

- A payment might be allowed if it is tiny and the risk of losing the customer is high even if the attestation seems wrong. Or vice-versa, the payment is large and the customer expects best protection. I’m pretty sure PayPal, VISA, Mastercard, Experian and such operate this way.

- a biometric authentication may not be allowed even though the attestation is excellent because the risk engine recognizes a pattern of fraud based on other non-attested data.

- A bad attestation from a router might be considered an isolated event until more evidence is accumulated. No one is went to the wire closet.

I also consider the security technology used to protect the signing key and attestation creation subsystem variable in security. And it needs to be considered in relation to the capacity of the attacker. A TEE (little defense against chip probing) might be consider quite good for small to medium $  payments backed by a risk engine. An EAL 6 secure element may be the only thing considered OK for access to a nuclear facility with no risk engine back up.

I prefer to never characterize something as trustworthy or as secure in any RFCs we create.  CWT and JWT don’t seem to go down this path either. 

(Correct me if I’m wrong, but I think maybe TCG does use the secure/non-secure framing. If so, I do NOT think we should bring it in here.)

LL

> On Jul 13, 2019, at 7:13 AM, Ira McDonald <blueroofmusic@gmail.com> wrote:
> 
> Hi,
> 
> About binary "trustworthy".
> 
> This is a fundamental fallacy.  Neither "trustworthy"
> nor "secure" are *ever* binary.  That's basic to the
> security by design approach.
> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Co-Chair - TCG Metadata Access Protocol SG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
> http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic@gmail.com <mailto:blueroofmusic@gmail.com>
> PO Box 221  Grand Marais, MI 49839  906-494-2434
> 
> 
> 
> On Fri, Jul 12, 2019 at 10:38 PM Benjamin Kaduk <kaduk@mit.edu <mailto:kaduk@mit.edu>> wrote:
> Cherry-picking one point...
> 
> On Mon, Jul 08, 2019 at 02:44:56PM +0000, Nicolae Paladi wrote:
> > Hello,
> > 
> > Some comments on draft-birkholz-rats-architecture-01<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01 <https://tools.ietf.org/html/draft-birkholz-rats-architecture-01>>
> > 
> [...]
> > 7.1.1<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-7.1.1 <https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-7.1.1>>.  How the RATS Architecture Addresses the Lying Endpoint Problem
> > 
> > 
> > 
> > 
> > 
> >  RATS imply the involvement of at least two players (roles) who seek
> >    to overcome the lying endpoint problem.  The Verifier wishes to
> >    consume application data supplied by a Computing Context.  But before
> >    application data is consumed, the Verifier obtains Attestation
> >    Evidence about the Computing Context to assess likelihood of poisoned
> >    data due to endpoint compromise or failure.  Remote Attestation
> >    argues that a systems's integrity characteristics should not be
> >    believed until rationale for believability is presented to the
> >    relying party seeking to interact with the system.
> > 
> > “Likelihood” implies a probabilistic approach to trustworthiness (e.g. 42% likelihood of poisoned data”). Is that really feasible? And if so, is it actually of any use? IMO trustworthiness is binary (“trustworthy or not trustworthy”), or binary and conditional/contextual (“trustworthy if used for certain actions”).
> 
> My personal thinking here is along the lines of "this data makes me
> confident that only someone who was able to subvert my supply chain and
> surreptitiously replace the TPM chip in the sealed device delivered to me
> would be able to forge the attestation evidence; I don't think I'm the
> target of such an attack, so there's a low likeliyhood of endpoint
> compromise".  Or, as James Mickens put it more glibly in
> https://www.usenix.org/system/files/1311_05-08_mickens.pdf <https://www.usenix.org/system/files/1311_05-08_mickens.pdf> there's a
> Mossad/not-Mossad distinction in the potential attackers, and if the Mossad
> is a threat, you're gonna be Mossad'ed upon no matter what you do.
> 
> -Ben
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org <mailto:RATS@ietf.org>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats