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

[Ira McDonald <[e-mail]>]

Hi,

I think that RFC 4949 definition of "trustworthy" is seriously
flawed".  For some of the nuances see the set of definitions
of "trustworthiness" in the US NIST Online Glossary at:

https://csrc.nist.gov/glossary/term/trustworthiness

Certainly for dynamic systems (i.e., almost all systems in
the real world), the idea of absolute "trustworthy" is a bad
one to use in system designs and implementations.

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/highnorthinc
mailto: [e-mail]
PO Box 221  Grand Marais, MI 49839  906-494-2434



On Mon, Jul 15, 2019 at 7:14 AM Nicolae Paladi <[e-mail]> wrote:

> Hi and thank you for the feedback on the point about trustworthiness.
>
> I agree that in case of complex systems or decisions trustworthiness
> depends on the context.
> Indeed, in the finance industry, decisions about the trustworthiness of a
> customer or transaction are often based on many inputs that together are
> used to compute the likelihood of the transaction or customer being
> acceptable or not.
>
> However, I was referring to the trustworthiness of a specific device as
> defined in draft-birkholz-rats-architecture-01:
>
> A trustworthy system is a system "that not only is trusted, but also
> warrants that trust because the system’s behavior can be validated in some
> convincing way, such as through formal analysis or code review" [RFC4949].
>
>
> In my understanding, a formally verified component (hw or sw), considered
> in a specific threat model is either trustworthy or not trustworthy, NOT “
> X % trustworthy "
>
> Note that I do not discuss whether it is “secure”, only whether it is
> trustworthy in the sense of RFC4949
>
> Nicolae
>
>
> On 14 Jul 2019, at 21:39, Laurence Lundblade <[e-mail]>
> wrote:
>
> 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 <[e-mail]> 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/highnorthinc
> mailto: [e-mail]
> PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
>
> On Fri, Jul 12, 2019 at 10:38 PM Benjamin Kaduk <[e-mail]> 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>
>> >
>> [...]
>> > 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 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rats
>>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>
>
>
>