Re: [Rats] Attestation Results for Connectivity

["Eric Voit (evoit)" <[e-mail]>]

Hi Dave,

Thanks so much for the quick feedback!   Some thoughts on some of the comments below:

[DT1]: Terminology problem: Evidence is offered to a Verifier, not a Relying Party
[EV1]: With terminology, the question is how to handle things at the abstract view when the terminology itself is clunky.   I agree with you that the 100% correct thing to say (and what is said in places like Figure 1) is a joint combination of "Relying Party and Verifier".  Perhaps over time we can find a way to say this which isn't so weighty.

[DT2]: Why? Firewalls don't do this in general, so such a requirement requires justification. 
[EV2]: A communication establishment which fails to a specifically targeted peer typically has a reason.   The mental model is List of HTTP status codes like HTTP 404 page not found error.

[DT3]: Terminology problem: Evidence goes to a Verifier not a Relying Party.
[EV3]: Here it is quite straight-forward to change the definition to "a combined Relying Party + Verifier"

[DT5]: This sounds directional (connect FROM a relying party TO an attester) instead of generic ("communicate with") 
[EV5]: Makes sense, how about "will accept a connection request from".

[DT6]: And this sounds directional in the opposite direction from the paragraph above. Shouldn't these be direction agnostic? And also "connection" vs "connectionless" (TCP vs UDP) agnostic?
[EV6]: Ultimately we will have bi-directional attestation on the same transport; e.g., EAP over TLS.  So we are trying to write this as unidirectional requirements over a bi-directional transport layer connection.  I expect work smithing will be needed as this progresses so that all constituents are happy.  As for TCP vs UDP should be agnostic; of course the definition of connection varies based on where in the networking stack you live :-).  "UDP connection" has 100K hits on Google.

[DT7]: I'd argue that each Attesting Environment (e.g., each OS or firmware vendor) might similarly support a different set of claims so this is not unique to hardware chips.
[EV7]: We can change 'hardware chip' to 'Attesting Environment'.

[DT8]: Rather than duplicating claim concepts for affirming vs detracting, can't you collapse them and have affirming vs detracting be part of the value? Not collapsing complicates the test matrix, e.g. to deal with
cases where both exist for the same concept in the same message.
[EV8]: Very interesting comment.   Effectively we would have a boolean (affirming or detracting) associated with a type of claim.   As for whether a (conflicting?) affirming or detracting result come from a  particular Appraisal Policy for Attestation Results: it is possible to avoid that risk by having a state machine which dictates that such intersections are not possible.  See the end of Appendix B.  But perhaps we can enforce this via the datatypes themselves.

[DT9]: Does this mean that the Verifier can authenticate both the hardware and the firmware? 
[EV9]: In draft-voit-rats-trustworthy-path-routing, we broke out hardware and firmware.  However I was unable to find a real case where a customer might be good with the hardware being ok, but they were not ok with the firmware being not ok.   So from the perspective of the Relying Party + Verifier B, if Verifier A finds any issue here, then flag it.   In general, it is useful to collapse failure states where the Relying Party + Verifier will take the same action no matter what.

[DT10]: Is there a difference between authentication (as in "authentic") vs verification? 
[EV10]: Same comment as [EV9], if the Verifier finds an issue, it should flag it.  Without such a discovered issue no explicit claims should be made.

[DT11]: This description contradicts the name. The name says it's only about the HW as an Attesting Environment, but the description implies that it is about any Attesting Environment. Presumably the description should be fixed.
[EV11]: agree that it is a specific Attesting Environment.  It read ok to me, but we are happy to work toward text which works for all.

[DT12]: executables != files. Some executables can be dynamically downloaded and installed without ever being stored as files. (Javascript code running in a browser is one example, but there are many more, including ones running natively, not in an interpreter) 
[EV12] Good catch.  Will change 'file' to 'executable'.

[DT13]: If I understand right, this is not about runtime memory, it's just about what's stored passively? 
[EV13]: Yes

[DT14]: This is a normative reference in the references section. Does that mean this claim is only usable for a GP compliance device? If so, the name should change. If not, the reference should change. 
[EV14]: It is not just for GP compliant devices. If this draft is adopted, we can work the references appropriately.  

[DT15]: Can't parse grammar. What verb goes with "storage space"?
[EV15]: 'storage space' is a noun to me.   Likely need more info to work this.

[DT16]: This reference is specific to an Open Module Terminal Platform and not to nodes in general. Does that mean this claim is only usable for OMTP devices? If so, the name should change. If not, then this doc should either cite it only as an example, or find a more general normative reference. 
[EV16]: Like [EV14], if adopted, we can work the nomenclature.

[DT18]: No idea what this means.
[EV18]: If a claim is automatic as a result of coming from a specific type of TEE, does the claim need to be (redundantly) articulated?  I would assert no.  But I could be convinced otherwise.

[DT21]: This seems overly limiting based on some of the claims shown that might not affect the communication in question (e.g., file-system-anomaly).
[EV21]: I violently agree.   In fact our implementation does what you said.   Time to tweak the text.

[DT22]: Either I misunderstand the definition, or SGX cannot provide this at all.
[EV22]: In theory, a TEE embedded Verifier could do some of this.  We could work specifics over time.   But it certainly wouldn't be precluded by SGX.

Thanks,
Eric


> -----Original Message-----
> From: Dave Thaler <dthaler=[e-mail]>
> Sent: Monday, April 26, 2021 5:32 PM
> To: Eric Voit (evoit) <[e-mail]>; Thomas Fossati
> <[e-mail]>; [e-mail]
> Cc: Scarlata, Vincent R <[e-mail]>; Thomas Hardjono
> <[e-mail]>; Henk Birkholz <[e-mail]>
> Subject: RE: Attestation Results for Connectivity
> 
> Hi Eric, et al.   I have read the document and added my comments in a marked
> up copy at
> https://www.microsoft.com/en-us/research/uploads/prod/2021/04/draft-voit-
> rats-attestation-results-00-DTreview.pdf
> 
> BTW, the CCC SIG is indeed called the "CCC Attestation SIG" and not the "CCC
> AAA SIG" 😊
> 
> Dave
> 
> -----Original Message-----
> From: RATS <[e-mail]> On Behalf Of Eric Voit (evoit)
> Sent: Monday, April 26, 2021 12:01 PM
> To: Thomas Fossati <[e-mail]>; [e-mail]
> Cc: Scarlata, Vincent R <[e-mail]>; Thomas Hardjono
> <[e-mail]>; Henk Birkholz <[e-mail]>
> Subject: Re: [Rats] Attestation Results for Connectivity
> 
> I meant to the CCC  AAA SIG   :-)         But this will get the word out for sure.
> 
> Eric
> 
> > -----Original Message-----
> > From: Thomas Fossati <[e-mail]>
> > Sent: Monday, April 26, 2021 2:49 PM
> > To: [e-mail]
> > Cc: Henk Birkholz <[e-mail]>; Thomas Hardjono
> > <[e-mail]>; Scarlata, Vincent R
> > <[e-mail]>; Thomas Fossati
> > <[e-mail]>; Eric Voit (evoit) <[e-mail]>
> > Subject: Re: Attestation Results for Connectivity
> >
> > <shameless_plug>
> >
> > Tomorrow, we are discussing this topic at the CCC Attestation SIG meeting.
> > Needless to say, everyone is more than welcome to join the call.
> >
> > For the details regarding agenda & zoom link, see:
> >
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs
> > .google.com%2Fdocument%2Fd%2F1NkiS78knPhDO0vA9ElS-
> &amp;data=04%7C01%7C
> >
> dthaler%40microsoft.com%7C7058c2c5167b495c547a08d908e5d7da%7C72f98
> 8bf8
> >
> 6f141af91ab2d7cd011db47%7C1%7C0%7C637550605542933134%7CUnknown
> %7CTWFpb
> >
> GZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M
> n0
> >
> %3D%7C1000&amp;sdata=BNx%2FHfu7ptDXErqqe0vgNuVWr1kBb00GnHbbFH7
> m2OU%3D&
> > amp;reserved=0 bQOHNu783gGPdmTEbbOoOOU/edit?usp=sharing
> >
> > cheers!
> >
> > </shameless_plug>
> >
> > On 26/04/2021, 18:12, "Eric Voit (evoit)" <[e-mail]> wrote:
> > >
> > > We have just submitted a new draft:   Attestation Results for
> > > Connectivity
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> > > tatracker.ietf.org%2Fdoc%2Fdraft-voit-rats-attestation-results%2F&am
> > >
> p;data=04%7C01%7Cdthaler%40microsoft.com%7C7058c2c5167b495c547a08d
> 90
> > >
> 8e5d7da%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63755060554
> 2933
> > >
> 134%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJB
> > >
> TiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3LaG5MGjcx3q1izo6sKzhc
> uK
> > > 7fTXT2BwZBw93AOb6jA%3D&amp;reserved=0
> > >
> > > This draft defines reusable Attestation Result information elements.
> > > When these elements are offered to Relying Parties as Evidence,
> > > different aspects of Attester trustworthiness can be evaluated.
> > > Additionally, where the Relying Party is interfacing with a
> > > heterogenous mix of Attesting Environment and Verifier types,
> > > consistent policies can be applied to subsequent information
> > > exchange between each Attester and the Relying Party.
> > >
> > > We would be very interested in your thoughts and input!
> > >
> > > Thanks,
> > >
> > >    Eric Voit – [e-mail]
> > >    Henk Birkholz – [e-mail]
> > >    Thomas Hardjono – [e-mail]
> > >    Thomas Fossati – [e-mail]
> > >    Vincent Scarlata – [e-mail]
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> > confidential and may also be privileged. If you are not the intended
> > recipient, please notify the sender immediately and do not disclose
> > the contents to any other person, use it for any purpose, or store or
> > copy the information in any medium. Thank you.