Subject: Re: [Rats] Next Steps after IETF 103 BoF

From: "Smith, Ned" <[email-masked]>
Date: Wed, 2 Jan 2019 18:47:11 +0000

I don't believe Scope 2 necessarily requires a TPM RoT as there is common practice around embedding 802.1AR IDevID or simply embedding an asymmetric key at manufacturing time. Attestations involving supply chain entities/organizations have the semantics of being able to show provenance of the device through the supply chain - aka "Device Provenance Attestation").

If I understood EAT use case correctly, there was a manufacturing element as well where keyIDs were embedded then a protocol to convey public keys to the verifier/Attestation Service Provider is needed so that the verifier can match keyID with public keys. The conveyance protocol feels like it could fit into #5 scope. The semantics appear to be aimed at device provenance attestation. In that sense, scope 1 doesn't address fully the scope of either EAT or RATS IMO. 

My view is attestation without a RoT is closer to onboarding using weak pairing mechanisms (or assumes an out of band secure channel but doesn't define it). Neither EAT or RATS are describing such a thing. Therefore, I'm not sure why it makes sense to define scope 1 as lacking a RoT mechanism. 

Given both EAT and RATS are valuing some form of device provenance attestation mechanism and both are defining/assuming some sort of protocol for conveying information to verifiers, it seems scopes 1 and 2 are somewhat arbitrary. Nevertheless, the scoping criteria (1 - 5) seem relevant for both EAT and RATS in terms of possible ways to narrow scope. 

Given #3 (token format definition) includes security considerations (e.g. encryption) then dependence on conveyance protocols (#4 and #5) for security isn't a high priority. Any existing transport will do. Given EAT and RATS are both advocating device provenance attestation use cases (where an asymmetric key is embedded somewhere during manufacturing - aka RoT) which is common to 802.1AR IdevID, TPM2, DICE, SGX and other attestation systems that define a RoT key. It makes sense to keep RoT within scope in terms of architecture and use case content. In other words, the arch/use cases can refer to a RoT without standardizing it. But RoT should align with something that can sign / protect the claims/token format. For example, RFC5280 certificates, 802.1AR (which is also RFC5280) or W3C DID (which can support RFC5280) are standards that can define a RoT key that can sign JOSE/COSE claims structures. 

Given #2 (claims definitions) the WG would focus on identifying a few assertions that make sense (given the use case scope). For example, a RoT claim might be that the RoT key resists software and maybe certain hardware attacks at the time of manufacturing completion. Another claim might be that the RoT firmware is updated correctly and is current. Just these two claims would make a significant industry impact if everyone could agree to support them.

Cheers,
Ned

On 12/20/18, 8:25 AM, "RATS on behalf of Roman Danyliw" <[email-masked] on behalf of [email-masked]> wrote:

    Hello!
    
    The IETF 103 BoF demonstrated the need for continued discussion on scoping the proposed work.  Robust private conversations have occurred, but none on the list -- a key ingredient to charter work.  To foster the further conversation:
    
    ** Attached are our observations on scoping and possible next steps -- no preference is being expressed and these likely do not represent the totality of the candidate scopes or next steps.
    
    ** Please comment on the proposed charter language posted at https://www.ietf.org/mail-archive/web/rats/current/msg00216.html.  Almost every step forward will require some charter language.
    
    ** We plan to schedule a WebEx call in mid-January 2019 to allow us to discuss next steps collectively. Please help us find the most mutually agreeable time by completing this doodle poll -- https://doodle.com/poll/h4qnn5kgcwmniz85
     
    Regards,
    Roman and Nancy

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 7 Jan 2019 19:56:01 -0800

Hi Ned,

I think it only takes a secret / private key for signing or HMAC and some SW to produce an standard attestation token. 

I think arbitrary Linux processes, Android Apps, Apple Watch apps and so on can produce standard attestation tokens all on their own irregardless of what HW they are running on and even when the underlying OS doesn’t support any sort of attestation. Those tokens won’t mean as much as ones produced by a TPM measuring the system, or a 802.1AR iDevID or such, but they will mean something and be useful and must be allowed.

I don’t think an RoT should be required and even prefer to not use the term in this work (unless maybe we agree on something like “attestation RoT”, define it very very broadly and clearly write its definition).

However you slice, it an RoT seems to be about the protection against local device-in-possesion attacks. 

I think it is probably not the business of an IETF attestation standard to say how the attestation signing key is protected from non-network borne attacks.  We don’t specify key protection requirements in other IETF standards using private / secret keys. Not in CWT, JWT, CMS, JOSE, COSE or TLS as far as I know. Specifying how keys are protected is very messy business. I know first hand from doing it in the FIDO certification program. 

If a relying party really want to know if an attestation token came from a super secure protected source or it came from a barely secure source, you generally have to find out from the owner of the keys you used to verify the token signature.

It is however fine to discuss, work on and standardize crypto algorithms, protocols and formats that are suitable for compatibility with TPMs. 

As to claims that describe the security of a module / process / subsystem in an IETF standard, I’m scared. It seems very slippery all the way to Common Criteria Attack Potential Calculation. 

EAT specifically avoids defining any conveyance protocol for the token. Just put tokens in extensions in other protocols. For example in an HTTP header or a TLS extension. I think this is how CWT and JWT are used. Or just use an HTTP GET or PUT to convey the token if there is no protocol already in use.  Tokens are always signed (sometimes encrypted) and thus self-secured. It doesn’t seem like there’s much of a need to define a protocol for token conveyance. So I don’t see much need for deliverable 4. 

LL

> On Jan 2, 2019, at 10:47 AM, Smith, Ned <[email-masked]> wrote:
> 
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats

---

From: Carl Wallace <[email-masked]>
Date: Tue, 08 Jan 2019 09:49:56 -0500

On 1/7/19, 10:56 PM, "RATS on behalf of Laurence Lundblade"
<[email-masked] on behalf of [email-masked]> wrote:

><snip>
>
>EAT specifically avoids defining any conveyance protocol for the token.
>Just put tokens in extensions in other protocols. For example in an HTTP
>header or a TLS extension. I think this is how CWT and JWT are used. Or
>just use an HTTP GET or PUT to convey the token if there is no protocol
>already in use.  Tokens are always signed (sometimes encrypted) and thus
>self-secured. It doesn’t seem like there’s much of a need to define a
>protocol for token conveyance. So I don’t see much need for deliverable
>4. 

[CW] Would definition of extensions to other protocols not fall under
deliverable 4 as a conveyance mechanism? As mentioned before, I would like
to see the binding to certificate request protocols standardized.
><snip>

---

From: Daniel Smith <[email-masked]>
Date: Wed, 09 Jan 2019 08:10:22 -0500

Greetings,

Forgive my intrusion, Monty invited me to come join the WG a few months back and I have been lurking on the list thus far. Please consider my inline comments below.

V/r,

Daniel P. Smith

Apertus Solutions, LLC

---- On Mon, 07 Jan 2019 22:56:01 -0500 Laurence Lundblade <[email-masked]> wrote ----

Hi Ned,

With all due respect but by defining an attestation architecture, whether you acknowledge it or not, you will  have a RoT for Reporting (RTR), which is one of three RoTs a TPM provides and what I think you were meaning to refer to by mentioning an "attestation RoT". The RTR is simply the mechanism you are trusting to make "correct" assertions about an entity's properties, e.g. measurements. The ability of the RTR to resist corruption of its assertions is referred to as the Strength of Mechanism for the RTR. IMHO the RTR should be acknowledged and the question should be what are the minimal Strength of Mechanism requirements that this specification impose on the RTR, e.g. does it have to be rooted in hardware, what mechanism should be used to assert its identity, what properties of the mechanism should it be able to assert, etc. I will also add that I would suggest not to craft the standard pinned to the TPM. The TPM is a great, low-cost mechanism to provide a RTM, RTS, and RTR but is not the only means to do so. I could easily see an RTR implemented in locations such as ARM's TZ or under an x86 STM that can provide a strong Strength of Mechanism and uses a RATS compliant protocol to make its assertions.

LL

> On Jan 2, 2019, at 10:47 AM, Smith, Ned <mailto:[email-masked]> wrote:

> On 12/20/18, 8:25 AM, "RATS on behalf of Roman Danyliw" <mailto:[email-masked] on behalf of mailto:[email-masked]> wrote:

> mailto:[email-masked]

RATS mailing list

mailto:[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Jan 2019 11:04:14 -0500

Laurence Lundblade <[email-masked]> wrote:
    > I think arbitrary Linux processes, Android Apps, Apple Watch apps and
    > so on can produce standard attestation tokens all on their own
    > irregardless of what HW they are running on and even when the
    > underlying OS doesn’t support any sort of attestation. Those tokens
    > won’t mean as much as ones produced by a TPM measuring the system, or a
    > 802.1AR iDevID or such, but they will mean something and be useful and
    > must be allowed.

I strongly agree!

In particular, not every attestation deals with life and death issues.
(I'm immediately thinking about drones in airport space right now,
but I can't say if or how any of this work would help there.  I'm sure
Hollywood thinks that unauthorized distribution of it's product are life and
death issues)

But, for the technology to be useful, relatively ubiquitous and cheap enough
such that it's present and available when we need it, it needs to be useable
for far less serious things.   For instance physical proximity attestations
seem like one such thing that the world needs to deal with a wide variety of
attacks against low-value targets.  (Think parking space allocation systems
in smart-cities)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 9 Jan 2019 17:04:28 +0000

See inline under [nms]

On 1/7/19, 7:56 PM, "RATS on behalf of Laurence Lundblade" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Ned,

    I think arbitrary Linux processes, Android Apps, Apple Watch apps and so on can produce standard attestation tokens all on their own irregardless of what HW they are running on and even when the underlying OS doesn’t support any sort of attestation. Those tokens won’t mean as much as ones produced by a TPM measuring the system, or a 802.1AR iDevID or such, but they will mean something and be useful and must be allowed.
[nms] The goal is interoperability. Strength of function / trust is a policy decision enforced by verifiers not standards. Verifiers just need to know what things mean.
    
    I don’t think an RoT should be required and even prefer to not use the term in this work (unless maybe we agree on something like “attestation RoT”, define it very very broadly and clearly write its definition).
[nms] I'm OK with "attestation RoT". We need vocabulary that allows us to talk about important concepts. The portion of the platform that the verifier is supposed to believe is working correctly without any evidence of such is an important concept.

    I think it is probably not the business of an IETF attestation standard to say how the attestation signing key is protected from non-network borne attacks.  We don’t specify key protection requirements in other IETF standards using private / secret keys. Not in CWT, JWT, CMS, JOSE, COSE or TLS as far as I know. Specifying how keys are protected is very messy business. I know first hand from doing it in the FIDO certification program. 
[nms] The point of attestation is to allow the verifier to know something about the attesting device's trustworthiness. If your point is IETF standards don't do attestation already, then I agree. If it is that IETF as an organization is chartered not to do attestation, then I disagree. 
    
    If a relying party really want to know if an attestation token came from a super secure protected source or it came from a barely secure source, you generally have to find out from the owner of the keys you used to verify the token signature.
[nms] Attestation mechanisms should facilitate making it easier to find out.

    As to claims that describe the security of a module / process / subsystem in an IETF standard, I’m scared. It seems very slippery all the way to Common Criteria Attack Potential Calculation. 
[nms] It may be simpler than this. For example, just knowing vendor, model and version of something goes a long way toward understanding the risk. A token that expresses these three values doesn't seem too difficult to express in a JWT/CWT token.

    EAT specifically avoids defining any conveyance protocol for the token. Just put tokens in extensions in other protocols. For example in an HTTP header or a TLS extension. I think this is how CWT and JWT are used. Or just use an HTTP GET or PUT to convey the token if there is no protocol already in use.  Tokens are always signed (sometimes encrypted) and thus self-secured. It doesn’t seem like there’s much of a need to define a protocol for token conveyance. So I don’t see much need for deliverable 4. 
[nms] Your definition of conveyance protocol seems similar to what others in RATS are thinking too. We do need to be able to talk about how tokens move around however.
    
    LL

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Jan 2019 17:38:19 -0600

> [nms] The goal is interoperability. Strength of function / trust is a policy decision enforced by verifiers not standards. Verifiers just need to know what things mean.

I largely agree ... but knowing what things mean and trusting that they are
accurate are different but entwined factors.

> [nms] The point of attestation is to allow the verifier to know something about the attesting device's trustworthiness. If your point is IETF standards don't do attestation already, then I agree. I…

I was reading this as claiming that the IETF doesn't need to mandate (e.g.)
that a given private key be stored in a hardware module whose manufacturer
carries liability insurance that will pay out $100,000 if the key is
extracted.  We can assume that there exist a key that the participants in
the protocol exchange deem to be adequately protected and build from there.
I'm not really squaring that with either of your listed interpretations, so
hopefully we can all get on the same page on this point.

> [nms] It may be simpler than this. For example, just knowing vendor, model and version of something goes a long way toward understanding the risk. A token that expresses these three values doesn't…

Yes ... but of course you again have to trust that the conveyed values are
accurate.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Jan 2019 17:43:51 -0600

> to see the binding to certificate request protocols standardized.

It's probably worth being open to the possibility that in some cases we
will be responsible for producing extensions to other protocols that enable
these facilities, but in other cases the other protocol will have an active
management WG that would be better placed to produce such extensions to the
protocol they manage.

-Ben

---

From: "Smith, Ned" <[email-masked]>
Date: Fri, 11 Jan 2019 01:13:52 +0000

See inline [nms2]

On 1/10/19, 3:38 PM, "Benjamin Kaduk" <[email-masked]> wrote:

[nms2] Agree.

[nms2] I'm OK with that as a starting point assumption. I will need to convince myself (and others?) that there is a basis for "deeming" the key to be adequately protected, even if that assumption is substantiated outside of an IETF specification. For example, a manufacturer might issue a manufacturing certificate that describes the way the mfg. key is generated or bound to hardware or firmware that is immutable from the time it leaves the factory until it participates in an attestation protocol. In this example, the certificate bridges the gap in terms of making a "believable" assumption vs. a wishful assumption. Anything the key signs, such as CWT structure containing assertions, builds on the assertion(s) found in the certificate.

    Yes ... but of course you again have to trust that the conveyed values are
    accurate.
[nms2] Refer to my last response above as it seems to break out of the circular reasoning.
    
    -Ben

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 10 Jan 2019 17:50:42 -0800

To me it seems similar to TLS and root certificate authorities. As far as I know, the IETF has no protocols, specifications, standards or criteria for how a particular TLS-enabled website protects its private keys or how the root certificate authority protects the root private key. There are some auditing schemes, services and companies that do check this, but they don’t work of full security specifications set by the IETF.

So, when a relying party is considering the trustworthiness of a token, it will be somewhat up to them to figure out who and what they trust, at least in the beginning. Probably it will be domain and company specific. Entities that I know that provide base trust nowadays are Google, FIDO Alliance, Qualcomm and Intel.

I hope we can do better in the long term, but my thought is to leave it out of the charter for the first round because it seems like a very hard problem.

LL

> On Jan 10, 2019, at 3:38 PM, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 11 Jan 2019 08:00:03 -0500

Hi,

Laurence - I disagree that Roots of Trust should be out-of-scope for RATS.

Relevant work, for any not familiar with it, was published in October 2018
in IETF Vectors of Trust:

https://www.rfc-editor.org/rfc/rfc8485.txt

All TPM chip manufacturers provide base trust.  There is active work
in Trusted Computing Group on TPM 2.0 Platform Certficate format
(from the TPM chip manufacturer).

I doubt that there is much practical utility to RATS attestations that are
simply based on TOFU (Trust on First Use) and opaque attestation
entities in endpoints using undisclosed software based roots of trust.
Reputation is meaningless, if the attesting endpoint has been hacked.

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: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, Jan 10, 2019 at 8:50 PM Laurence Lundblade <[email-masked]>
wrote:

> To me it seems similar to TLS and root certificate authorities. As far as
> I know, the IETF has no protocols, specifications, standards or criteria
> for how a particular TLS-enabled website protects its private keys or how
> the root certificate authority protects the root private key. There are
> some auditing schemes, services and companies that do check this, but they
> don’t work of full security specifications set by the IETF.
>
> So, when a relying party is considering the trustworthiness of a token, it
> will be somewhat up to them to figure out who and what they trust, at least
> in the beginning. Probably it will be domain and company specific. Entities
> that I know that provide base trust nowadays are Google, FIDO Alliance,
> Qualcomm and Intel.
>
> I hope we can do better in the long term, but my thought is to leave it
> out of the charter for the first round because it seems like a very hard
> problem.
>
> LL
>
>
>
> >> On 1/7/19, 7:56 PM, "RATS on behalf of Laurence Lundblade" <
> [email-masked] on behalf of [email-masked]> wrote:
> >>
> >>    Hi Ned,
> >>
> >>    I think it only takes a secret / private key for signing or HMAC and
> some SW to produce an standard attestation token.
> >>
> >>    I think arbitrary Linux processes, Android Apps, Apple Watch apps
> and so on can produce standard attestation tokens all on their own
> irregardless of what HW they are running on and even when the underlying OS
> doesn’t support any sort of attestation. Those tokens won’t mean as much as
> ones produced by a TPM measuring the system, or a 802.1AR iDevID or such,
> but they will mean something and be useful and must be allowed.
> >> [nms] The goal is interoperability. Strength of function / trust is a
> policy decision enforced by verifiers not standards. Verifiers just need to
> know what things mean.
> >
> >>    I don’t think an RoT should be required and even prefer to not use
> the term in this work (unless maybe we agree on something like “attestation
> RoT”, define it very very broadly and clearly write its definition).
> >> [nms] I'm OK with "attestation RoT". We need vocabulary that allows us
> to talk about important concepts. The portion of the platform that the
> verifier is supposed to believe is working correctly without any evidence
> of such is an important concept.
> >>
> >>    However you slice, it an RoT seems to be about the protection
> against local device-in-possesion attacks.
> >>
> >>    I think it is probably not the business of an IETF attestation
> standard to say how the attestation signing key is protected from
> non-network borne attacks.  We don’t specify key protection requirements in
> other IETF standards using private / secret keys. Not in CWT, JWT, CMS,
> JOSE, COSE or TLS as far as I know. Specifying how keys are protected is
> very messy business. I know first hand from doing it in the FIDO
> certification program.
> >> [nms] The point of attestation is to allow the verifier to know
> something about the attesting device's trustworthiness. If your point is
> IETF standards don't do attestation already, then I agree. If it is that
> IETF as an organization is chartered not to do attestation, then I
> disagree.
> >
> >>    If a relying party really want to know if an attestation token came
> from a super secure protected source or it came from a barely secure
> source, you generally have to find out from the owner of the keys you used
> to verify the token signature.
> >>    It is however fine to discuss, work on and standardize crypto
> algorithms, protocols and formats that are suitable for compatibility with
> TPMs.
> >>
> >>    As to claims that describe the security of a module / process /
> subsystem in an IETF standard, I’m scared. It seems very slippery all the
> way to Common Criteria Attack Potential Calculation.
> >> [nms] It may be simpler than this. For example, just knowing vendor,
> model and version of something goes a long way toward understanding the
> risk. A token that expresses these three values doesn't seem too difficult
> to express in a JWT/CWT token.
> >
> >>    EAT specifically avoids defining any conveyance protocol for the
> token. Just put tokens in extensions in other protocols. For example in an
> HTTP header or a TLS extension. I think this is how CWT and JWT are used.
> Or just use an HTTP GET or PUT to convey the token if there is no protocol
> protocol for token conveyance. So I don’t see much need for deliverable 4.
> >> [nms] Your definition of conveyance protocol seems similar to what
> others in RATS are thinking too. We do need to be able to talk about how
> tokens move around however.
> >>
> >>    LL
> >>
> >>
> >>
> >>
> >>
> >>
> >>> I don't believe Scope 2 necessarily requires a TPM RoT as there is
> common practice around embedding 802.1AR IDevID or simply embedding an
> asymmetric key at manufacturing time. Attestations involving supply chain
> entities/organizations have the semantics of being able to show provenance
> of the device through the supply chain - aka "Device Provenance
> Attestation").
> >>>
> >>> If I understood EAT use case correctly, there was a manufacturing
> element as well where keyIDs were embedded then a protocol to convey public
> keys to the verifier/Attestation Service Provider is needed so that the
> verifier can match keyID with public keys. The conveyance protocol feels
> like it could fit into #5 scope. The semantics appear to be aimed at device
> provenance attestation. In that sense, scope 1 doesn't address fully the
> scope of either EAT or RATS IMO.
> >>>
> >>> My view is attestation without a RoT is closer to onboarding using
> weak pairing mechanisms (or assumes an out of band secure channel but
> doesn't define it). Neither EAT or RATS are describing such a thing.
> Therefore, I'm not sure why it makes sense to define scope 1 as lacking a
> RoT mechanism.
> >>>
> >>> Given both EAT and RATS are valuing some form of device provenance
> attestation mechanism and both are defining/assuming some sort of protocol
> for conveying information to verifiers, it seems scopes 1 and 2 are
> somewhat arbitrary. Nevertheless, the scoping criteria (1 - 5) seem
> relevant for both EAT and RATS in terms of possible ways to narrow scope.
> >>>
> >>> Given #3 (token format definition) includes security considerations
> (e.g. encryption) then dependence on conveyance protocols (#4 and #5) for
> security isn't a high priority. Any existing transport will do. Given EAT
> and RATS are both advocating device provenance attestation use cases (where
> an asymmetric key is embedded somewhere during manufacturing - aka RoT)
> which is common to 802.1AR IdevID, TPM2, DICE, SGX and other attestation
> systems that define a RoT key. It makes sense to keep RoT within scope in
> terms of architecture and use case content. In other words, the arch/use
> cases can refer to a RoT without standardizing it. But RoT should align
> with something that can sign / protect the claims/token format. For
> example, RFC5280 certificates, 802.1AR (which is also RFC5280) or W3C DID
> (which can support RFC5280) are standards that can define a RoT key that
> can sign JOSE/COSE claims structures.
> >>>
> >>> Given #2 (claims definitions) the WG would focus on identifying a few
> assertions that make sense (given the use case scope). For example, a RoT
> claim might be that the RoT key resists software and maybe certain hardware
> attacks at the time of manufacturing completion. Another claim might be
> that the RoT firmware is updated correctly and is current. Just these two
> claims would make a significant industry impact if everyone could agree to
> support them.
> >>>
> >>> Cheers,
> >>> Ned
> >>>
> >>> On 12/20/18, 8:25 AM, "RATS on behalf of Roman Danyliw" <
> [email-masked] on behalf of [email-masked]> wrote:
> >>>
> >>>   Hello!
> >>>
> >>>   The IETF 103 BoF demonstrated the need for continued discussion on
> scoping the proposed work.  Robust private conversations have occurred, but
> none on the list -- a key ingredient to charter work.  To foster the
> further conversation:
> >>>
> >>>   ** Attached are our observations on scoping and possible next steps
> -- no preference is being expressed and these likely do not represent the
> totality of the candidate scopes or next steps.
> >>>
> >>>   ** Please comment on the proposed charter language posted at
> https://www.ietf.org/mail-archive/web/rats/current/msg00216.html.  Almost
> every step forward will require some charter language.
> >>>
> >>>   ** We plan to schedule a WebEx call in mid-January 2019 to allow us
> to discuss next steps collectively. Please help us find the most mutually
> agreeable time by completing this doodle poll --
> https://doodle.com/poll/h4qnn5kgcwmniz85
> >>>
> >>>   Regards,
> >>>   Roman and Nancy
> >>>
> >>>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 11 Jan 2019 16:35:14 +0100

Hi Ned,

we are meeting in 20 min, right? My calendar says so. Finishing the slides and sending them to the list seems in order?

Viele Grüße,

Henk

On January 11, 2019 2:13:52 AM GMT+01:00, "Smith, Ned" <[email-masked]> wrote:
>>On 1/7/19, 7:56 PM, "RATS on behalf of Laurence Lundblade"
>>     I think it only takes a secret / private key for signing or HMAC
>and some SW to produce an standard attestation token. 
>    >     
>policy decision enforced by verifiers not standards. Verifiers just
>need to know what things mean.
>    
>>     I don’t think an RoT should be required and even prefer to not
>use the term in this work (unless maybe we agree on something like
>“attestation RoT”, define it very very broadly and clearly write its
>definition).
>verifier is supposed to believe is working correctly without any
>evidence of such is an important concept.
>    >     
>non-network borne attacks.  We don’t specify key protection
>requirements in other IETF standards using private / secret keys. Not
>in CWT, JWT, CMS, JOSE, COSE or TLS as far as I know. Specifying how
>keys are protected is very messy business. I know first hand from doing
>it in the FIDO certification program. 
>something about the attesting device's trustworthiness. If your point
>is IETF standards don't do attestation already, then I agree. If it is
>that IETF as an organization is chartered not to do attestation, then I
>disagree. 
>    
>[nms2] I'm OK with that as a starting point assumption. I will need to
>convince myself (and others?) that there is a basis for "deeming" the
>key to be adequately protected, even if that assumption is
>substantiated outside of an IETF specification. For example, a
>manufacturer might issue a manufacturing certificate that describes the
>way the mfg. key is generated or bound to hardware or firmware that is
>immutable from the time it leaves the factory until it participates in
>an attestation protocol. In this example, the certificate bridges the
>gap in terms of making a "believable" assumption vs. a wishful
>assumption. Anything the key signs, such as CWT structure containing
>assertions, builds on the assertion(s) found in the certificate.
>    
>>     If a relying party really want to know if an attestation token
>came from a super secure protected source or it came from a barely
>secure source, you generally have to find out from the owner of the
>keys you used to verify the token signature.
>algorithms, protocols and formats that are suitable for compatibility
>with TPMs. 
>    >     
>subsystem in an IETF standard, I’m scared. It seems very slippery all
>the way to Common Criteria Attack Potential Calculation. 
>risk. A token that expresses these three values doesn't seem too
>difficult to express in a JWT/CWT token.
>    

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 11 Jan 2019 16:52:34 +0100

Oh. Hi list :) Happy new year!

as you now know, the RATS proponents are preparing a slide-deck to 
consolidate the core concepts presented at the BoF, based on the 
"Diagram for Discussion #2". With some luck we get the polich done today 
and send that out. MY assumption is that it will include the spectrum of 
conveyance of verifiable claims up integrity measurement logs quite well.

Wrt to RoTs: I think mandating them in 100% of the use cases would be 
excessive, as would be not taking them into account. I am rather sure, 
the proposed WG will be able to create an architecture that highlights 
which flavor of RoT can increase the level of confidence in which peace 
of the puzzle (network protocol defined/referenced in RATS).

After a lot of exlporation, I am under the impression that essentially 
every remote attestation relies that relies on a higher level of 
confidence uses a kind of RoT. Be at an e-fused pre-master secret that 
the manufacturer knows about, but is not directly accessible on the 
device it is on, a TEE with well-vetted software, or a dedicated hw 
crypto processor.

Viele Grüße,

Henk

On 1/11/19 4:35 PM, Henk Birkholz wrote:
> Hi Ned,
> 
> we are meeting in 20 min, right? My calendar says so. Finishing the 
> slides and sending them to the list seems in order?
> 
> Viele Grüße,
> 
> Henk
> 
>         I think arbitrary Linux processes, Android Apps, Apple Watch
>         apps and so on can produce standard attestation tokens all on
>         their own irregardless of what HW they are running on and even
>         when the underlying OS doesn’t support any sort of attestation.
>         Those tokens won’t mean as much as ones produced by a TPM
>         measuring the system, or a 802.1AR iDevID or such, but they will
>         mean something and be useful and must be allowed.
>         [nms] The goal is interoperability. Strength of function / trust
>         is a policy decision enforced by verifiers not standards.
>         Verifiers just need to know what things mean.
> 
>          
>         use the term in this work (unless maybe we agree on something
>         like “attestation RoT”, define it very very broadly and clearly
>         write its definition).
>         [nms] I'm OK with "attestation RoT". We need vocabulary that
>         allows us to talk about important concepts. The portion of the
>         platform that the verifier is supposed to believe is working
>         correctly without any evidence of such is an important concept.
> 
>         standard to say how the attestation signing key is protected
>         from non-network borne attacks. We don’t specify key protection
>         requirements in other IETF standards using private / secret
>         keys. Not in CWT, JWT, CMS, JOSE, COSE or TLS as far as I know.
>         Specifying how keys are protected is very messy business. I know
>         first hand from doing it in the FIDO certification program.
>         something about the attesting device's trustworthiness. If your
>         point is IETF standards don't do attestation already, then I
>         agree. If it is that IETF as an organization is chartered not to
>         do attestation, then I disagree.
> 
>          
>         came from a super secure protected source or it came from a
>         barely secure source, you generally have to find out from the
>         owner of the keys you used to verify the token signature.
>         algorithms, protocols and formats that are suitable for
>         compatibility with TPMs.
> 
>         subsystem in an IETF standard, I’m scared. It seems very
>         slippery all the way to Common Criteria Attack Potential
>         Calculation.
>         [nms] It may be simpler than this. For example, just knowing
>         vendor, model and version of something goes a long way toward
>         understanding the risk. A token that expresses these three
>         values doesn't seem too difficult to express in a JWT/CWT token.
> 
>          
>     ------------------------------------------------------------------------
> 
>     RATS mailing list
>     [email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 11 Jan 2019 14:57:34 -0600

Hi Ira,

> https://www.rfc-editor.org/rfc/rfc8485.txt

That's just a container format for conveying information that can describe
factors including RoT used, but requires site-specific agreement between
peers about what values actually mean.

> Reputation is meaningless, if the attesting endpoint has been hacked.

Those are reasonable doubts to hold!  But so long as they remain just
doubts, it's a bit premature to use them to completely exclude the topic
from discussion.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 11 Jan 2019 14:58:37 -0600

> [nms2] I'm OK with that as a starting point assumption. I will need to convince myself (and others?) that there is a basis for "deeming" the key to be adequately protected, even if that assumption…

Exactly!

-Ben

---

From: Ira McDonald <[email-masked]>
Date: Fri, 11 Jan 2019 17:46:40 -0500

Hi Benjamin,

I didn't at all mean to rule TOFU "trust" out of scope.

I meant to *include* in scope hardware-based RoTs
(whether they're based in TPMs, Trusted Apps in
correctly implemented GP TEEs, or some other
mechanism that has more tamper-resistance than
a pure software RoT.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 11 Jan 2019 16:50:40 -0600

> mechanism that has more tamper-resistance than

Ah, thanks for clarifying.

-Ben

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 11 Jan 2019 15:39:58 -0800

Hi Ira,

I am saying that an RoT-based device implementation should not be a normative requirement, just like HSMs are not required in the TLS or X.509 specs and smart cards are not required in the CMS spec. I don’t think we should make a normative requirement for the strength of protection around the key used to sign attestations.

I think there must be discussion of RoTs in the Security Considerations spec and I think most implementations should use an RoT in some form or other.  I think the Security Consideration section should strongly encourage protection of the signing key and suggest that implementations that don’t have any protection are particularly poor.

I agree with you that TOFU is not what we want for most use cases.

Three main reasons for this position on RoTs:
 - Specifying protection methods in a clear calibrated way is very difficult (I’ve worked on doing this for FIDO for years) 
 - IETF specifications focus on bits on-the-wire and existing specs  (TLS, CMS, PKIX, CMS, CWT, JWT…) don’t have such normative requirements
 - RoT means different things to different people. As I talk with each of you individually, I get varying descriptions.

I am fine with creating claims to characterize and calibrate the security of some part of a device with the understanding that they are optional just like any other claim.

Thanks for sharing the vectors of trust doc. This is similar to creating claims that describe security of a device like we want to do here. It however is does not put normative requirements on the protection of CWT/JWT signing keys.

LL

> On Jan 11, 2019, at 5:00 AM, Ira McDonald <[email-masked]> wrote:
> 
> Hi,
> 
> https://www.rfc-editor.org/rfc/rfc8485.txt <https://www.rfc-editor.org/rfc/rfc8485.txt>
> 
> 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: [email-masked] <mailto:[email-masked]>
> On Thu, Jan 10, 2019 at 8:50 PM Laurence Lundblade <[email-masked] <mailto:[email-masked]>> wrote:
> > On Jan 10, 2019, at 3:38 PM, Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> >> On 1/7/19, 7:56 PM, "RATS on behalf of Laurence Lundblade" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >>    Hi Ned,
> >> 
> >>> On Jan 2, 2019, at 10:47 AM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>> On 12/20/18, 8:25 AM, "RATS on behalf of Roman Danyliw" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>>   Hello!
> >>> 
> >>>   The IETF 103 BoF demonstrated the need for continued discussion on scoping the proposed work.  Robust private conversations have occurred, but none on the list -- a key ingredient to charter work..  To foster the further conversation:
> >>> 
> >>>   ** Please comment on the proposed charter language posted at https://www.ietf.org/mail-archive/web/rats/current/msg00216.html <https://www.ietf.org/mail-archive/web/rats/current/msg00216.html>.  Almost every step forward will require some charter language.
> >>> 
> >>>   ** We plan to schedule a WebEx call in mid-January 2019 to allow us to discuss next steps collectively. Please help us find the most mutually agreeable time by completing this doodle poll -- https://doodle.com/poll/h4qnn5kgcwmniz85 <https://doodle.com/poll/h4qnn5kgcwmniz85>
> >>> 
> >>>   Regards,
> >>>   Roman and Nancy
> >>> 
> >>> 
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> >> 
> >>    [email-masked] <mailto:[email-masked]>
> >>    https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> >> 
> >> 
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 11 Jan 2019 15:47:11 -0800

> On Jan 11, 2019, at 12:58 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Pretty sure I agree too. 

The out-of-band trust could be repetitional, which is the way we trust most TLS CAs and browser vendors today and on which the security of billions of dollars of e-commerce hinge. It could also be through a legal contract.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 13 Jan 2019 10:41:02 -0800

> On Jan 11, 2019, at 3:47 PM, Laurence Lundblade <[email-masked]> wrote:
> 
> The out-of-band trust could be repetitional, which is the way we trust most TLS CAs and browser vendors today ...

reputational (auto-correct…)

LL