Re: [SPICE] Call for consensus on SPICE charter

[Manu Fontaine <[e-mail]>]

Thanks Denis, I understand your perspective.

Manu

On Mon, Feb 26, 2024 at 9:26 AM Denis <[e-mail]> wrote:

> Manu,
>
> The "IETF SEC Area" is neither a BoF, nor a WG.
>
> So the "intersection of CCC and the IETF SEC Area" will not be the SPICE
> BoF (nor a WG formed from it).
>
> Within the IETF, the TEEP WG has produced RFC 9397, i.e., the Trusted
> Execution Environment Provisioning (TEEP) Architecture.
> It is currently progressing draft-ietf-teep-protocol-18, i.e., Trusted
> Execution Environment Provisioning (TEEP) Protocol.
> This can be viewed as a back-office management function.
>
> The need to consider a TA running under a TEE in the context of SPICE does
> not originate from the Confidential Computing Consortium,
> but from a security threat analysis focusing on the Holder.
>
> The holder (application) needs to manage either asymmetric key pairs or
> Link Secrets together with Blinded Link secrets (BLSs).
> Not only these keys need to be protected in a TEE, but also the TA
> (Trusted Application), i.e., the Holder, that manages and uses
> them needs to be hosted in a TEE.
>
> In the context of SPICE, from a front-office point of view, before
> issuing a digital credential to a Holder, the digital credential issuer
> needs to be convinced
> that the digital credential request originates from a TA which supports
> "specific characteristics" and that this TA is indeed hosted in a TEE.
> This missing piece of the puzzle could be developed in a future SPICE WG
> ... or , even better, as an additional RFC published by the RATS WG.
> This is why coordination with both TEEP and RATS is important.
>
> A goal of a future SPICE WG should not be to build *the "missing layer"
> of the internet that we've all been looking for*", nor "**the* security
> bedrock*".
>
> Denis
>
> Thanks Henk, I hope you'll be in Brisbane so we can meet in person.
>
> Our perspective is that CC is literally (chip+workload) identity and
> cryptographic security at the *physical* layer.
> It's the infamous "missing layer" of the internet that we've all been
> looking for. It's *the* security bedrock.
>
> I cannot think of better places than the intersection of CCC and the IETF
> SEC Area to re-imagine security from the silicon up.
>
> Manu
>
>
> On Sun, Feb 25, 2024 at 11:17 PM Henk Birkholz
> <[e-mail]> <[e-mail]> wrote:
>
>> Dear Manu,
>>
>> I've been a member of the Confidential Computing Consortium since its
>> formation. I agree the CCC work is an implementation steered hub that
>> binds many, many of the standardized building blocks that you mentioned.
>> And a lot of IETF contributors and implementers meet there to find
>> common ground, generalize APIs across hardware, and complain about
>> Attestation Evidence heterogeneity all the time (that is fun, too).
>>
>> Advertisement hat on: It's a great place! Have a look!
>>
>> There is a tendency to produce confidential computing solutions from the
>> bottom up - okay. But I'd not go so far as to say the "infrastructure
>> layer" is the nucleus here. A ton of work is done on the API level and
>> the OPS level and the IETF provides these really useful nuclei, one of
>> them draft-ietf-rats-ar4si. That work shows that all pieces of the stack
>> are important to the assessment, even the infrastructure layer. Is the
>> situation great across vendors on that layer? Probably not great. Are we
>> trying to give the best incentives to make it better? Yes!
>>
>> Let's try to scope the SPICE WG in a way that attracts the real-world
>> experts, both users that really need standards, because "all I have are
>> these ancient processes and documents and everything seems to be hyper
>> confidential and now it must be interoperable and secure next week?" and
>> experts that bring the experience to the SPICE WG that have the
>> potential to solve parts of the problem. The interconnected system you
>> are illustrating is not blocked by that. I think it is a good way to get
>> there in time, actually. And it requires to listen to other WGs experts
>> and interact with them in the IETF. I think that's great.
>>
>>
>> Viele Grüße,
>>
>> Henk
>>
>> On 24.02.24 17:11, Manu Fontaine wrote:
>> > I am reacting to mentions of "hardware", "balance", and "maximalist
>> > positions" regarding important parts of "delivering secure and usable
>> > systems".
>> >
>> > Confidential Computing hardware (TEEs) is readily available, and a
>> > blueprint exists
>> > <
>> https://datatracker.ietf.org/meeting/118/materials/slides-118-hotrfc-sessa-05-a-universal-name-system-uns-and-universal-certificate-authority-uca-00>
>> to solve for global assurance of provenance, integrity, authenticity,
>> confidentiality, reputation, and privacy for all bits, be they code or
>> data, for persons and non-person entities. No exotic cryptography required.
>> >
>> > The problem space collapses when using Confidential Computing at the
>> > "infrastructure layer". In 2024, identity, authentication,
>> > authorization, data encryption, key management, and credentialing
>> should
>> > all be re-imagined on top of Confidential Computing, if for nothing
>> else
>> > than CC providing attestation+verification of hardware+software
>> > integrity. Why would anyone not want to verify these critical pieces of
>> > infrastructure? #zerotrust
>> >
>> > I am still an IETF newbie trying to understand how to bring this work
>> to
>> > the IETF, realizing that it's tricky as it overlaps with many WGs. I'll
>> > be in Brisbane and will schedule a side meeting to give an update on
>> our
>> > work in this direction, and I hope to start/continue conversations with
>> > all of you.
>> >
>> > Manu
>> >
>> >
>> > On Fri, Feb 23, 2024 at 9:58 PM Orie Steele <[e-mail]>
>> <[e-mail]>
>> > wrote:
>> >
>> >     The charter mentions profiles of JWP/CWP, which is from JOSE not
>> >     OAuth, and which supports BBS, but can be extended to other systems,
>> >     assuming they can support similar interfaces.
>> >
>> >     https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/
>> >     <https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-proof/>
>> >
>> >     I'd personally like to see CFRG publish some lattice based zkp
>> >     system that could offer similar capabilities... Probably, we are
>> >     years away from seeing hardware support for that... I'd be happy to
>> >     be wrong, as long as the lattice system lasts longer than elliptic
>> >     curve discrete log.
>> >
>> >     In the informal meetings, which we have had, BBS has been discussed
>> >     a lot.
>> >
>> >     As have the consent and privacy issues, and infrastructure costs
>> >     associated with single use key bound credentials, which include ISO
>> >     mDoc and SD-JWT.
>> >
>> >     Sustainability, privacy, inclusivity and transparency are all
>> >     important parts of delivery secure and usable systems.
>> >
>> >     Some balance is necessary, because we are unlikely to agree to
>> >     maximalist positions on any one of these important dimensions.
>> >
>> >     See also:
>> >
>> >
>> https://datatracker.ietf.org/doc/statement-iab-statement-on-the-risks-of-attestation-of-software-and-hardware-on-the-open-internet/
>> <
>> https://datatracker.ietf.org/doc/statement-iab-statement-on-the-risks-of-attestation-of-software-and-hardware-on-the-open-internet/
>> >
>> >
>> >     OS
>> >
>> >
>> >     On Fri, Feb 23, 2024, 8:36 PM Watson Ladd <[e-mail]
>> >     <mailto:[e-mail]>> wrote:
>> >
>> >         On Fri, Feb 23, 2024, 5:17 PM Kaliya Identity Woman
>> >         <[e-mail] <mailto:[e-mail]>>
>> wrote:
>> >          >
>> >          > I don't know what you mean by "privacy" Nick.
>> >          > I think the folks who are in the trenches of developing the
>> >         protocols of digital identity at least those arising out of the
>> >         community arising from Internet Identity Workshop community have
>> >         been very focused on how to best give individual people the most
>> >         control possible over how they can leverage digital credentials
>> >         and have worked very hard.
>> >
>> >         Results, not effort, matter.
>> >
>> >          >
>> >          > We have also come up against very real world constraints -
>> >         while the BLS family of cryptography that the BBS+ work is
>> >         anchored in and is progressing through CFRG is fantastic in
>> >         providing a path forward for really great selective disclosure
>> >         capabilities.  It isn't finished review and it hasn't been
>> >         standardized for how to actually use it to create credentials
>> >         (Although some great companies leading this work have been
>> >         experimenting).
>> >
>> >         Isn't that the work of standards bodies and companies to
>> develop the
>> >         tech and standardize?
>> >
>> >          > Even if it WAS ready "now" the phones that are on the market
>> >         and widely adopted don't have the capabilities to actually do
>> >         BLS signatures to anchor the credentials to phones.   (for
>> >         better or worse this is the primary subject holder binding
>> >         mechanism that European governments have decided to proceed with
>> >         for the issuance of state issued documents to
>> citizens/residents).
>> >
>> >         I'm not that familiar with secure element design but I have
>> written
>> >         papers and run code showing that it's possible to achieve these
>> >         bindings while preserving privacy and not modifying the
>> element. Now
>> >         there were some mistakes later work has fixed but it is
>> >         possible: see
>> >         SAC '21 and the successor that fixes some stuff is a preprint I
>> can
>> >         share.
>> >
>> >          >
>> >          > Extensive research into all the possibilities of formats and
>> >         signatures and bindings was made and I believe that SD-JWT was
>> >         the best possible one out of the bunch given all the REAL WORLD
>> >         constraints. (see this community built spread sheet for the
>> details)
>> >          >
>> >          > I think we need the SPICE working group in the IETF to
>> >         actually make a home to continue to progress the work towards
>> >         even better credentials with better properties. It is
>> >         specifically envisioned by the folks who are asking for this
>> >         working group that work on how to do credentials with BBS+
>> >         signatures would happen in this group once the CFRG review is
>> >         complete and I know that there are government folks who want
>> >         better choices then they have now in terms of ways to protect
>> >         and support citizen empowerment and "privacy".
>> >
>> >         But that's not what the group is being singularly chartered for
>> >         nor is
>> >         it combining all this work over the IETF. The debate here is
>> really
>> >         about what should be done in the group and elsewhere, and if the
>> >         charter was BBS identity I think a lot of people would support
>> it.
>> >
>> >          >
>> >          >
>> >          > If we don't actually make space to move the work forward it
>> >         can't move forward.
>> >
>> >         No one is saying we shouldn't do BBS based credentials here.
>> We're
>> >         asking questions about the scope and whether or not to approve
>> >         mechanisms that don't meet the bar privacy wise without a lot
>> more
>> >         effort in deployment that's been pushed out of scope.
>> >
>> >          >
>> >          >
>> >          > I find it a bit hard to take seriously folks who have not
>> >         been actively engaged in the community working on digital
>> >         credentials for people landing down taking one glance around and
>> >         saying in an off the cuff way "its not good enough privacy" when
>> >         they have not really taken the time to understand the history,
>> >         context, real extremely extraneous effort that has been put into
>> >         achieving the development of reasonable systems within the real
>> >         world constraints that really exist.
>> >          >
>> >          > Maybe it is our job to do a better job to communicate this
>> >         prior art and significant body of existing work, and really
>> >         dedicated people who have a real commitment to core positive
>> values.
>> >
>> >         If this community was committed to privacy you'd collectively
>> away
>> >         when the constraints make it impossible. That's what being
>> committed
>> >         to values means. Luther did not say "I stand here, and I'll move
>> >         a bit
>> >         if it's inconvenient".
>> >
>> >         SD-JWT isn't a minor privacy problem. It lets the government
>> track
>> >         every time you use a credential online, with active proposals to
>> >         mandate it for the viewing of "sensitive" materials, a category
>> >         encompassing some of the most beautiful photography of the 20th
>> >         century, several Oscar winning movies. Some governments will of
>> >         course
>> >         seek to extend this further to Winnie the Poh memes, French
>> Peanuts
>> >         reprinters, or news Carter-Ruck doesn't like.
>> >
>> >          >  The work has been happening in earnest with a coherent group
>> >         of people who have been inter-related and working together on
>> >         this for 20 years.  Many of these people gather twice a year at
>> >         the Internet Identity Workshop and ongoing efforts inbetween
>> >         happen in bodies such as the Decentralized Identity Foundation,
>> >         OpenID Foundation, Trust over IP Foundation, Kantara Initiative,
>> >         various W3C Community Groups.
>> >
>> >         There has been inordinate work on credentials ever since CL01
>> and
>> >         CL04, and all of that has been ignored. It could have gone into
>> >         secure
>> >         elements: TPM has DAA after all. But instead we get this. The
>> >         lack of
>> >         engagement with cryptographers and privacy engineers is
>> unfortunate,
>> >         but we can't ignore these issues on the basis that the water has
>> >         passed under the bridge.
>> >
>> >          >
>> >          > I have only been to the last two IETFs and I was really
>> >         impressed with the deep collective intelligence and wisdom I saw
>> >         in action.  I was surprised about how many different working
>> >         groups who's efforts touch in some way on identity are not
>> >         intersecting very much or learning from each other (PrivacyPass
>> >         has quite limited overlap with OAuth work - TIGRESS is working
>> >         on moving keys between phones/wallets? also not interacting with
>> >         work focused on that in the identity community)  Dick and Rifaat
>> >         have a great outline for an identity sense making effort that
>> >         could go a long way to helping various groups just as step 1
>> >         understand what each other is doing.
>> >
>> >         PrivacyPass is doing something different than OAUTH hence the
>> >         lack of
>> >         overlap. If they overlapped more then there would be a problem.
>> >
>> >          >
>> >          > I think SPICE is needed and I hope the charter will be
>> approved.
>> >          > I don't think adding more MUSTs to the charter right now will
>> >         help us progress.  Folks who believe that certain properties and
>> >         features should be in protocols that the group works on should
>> >         get engaged to struggle through the real work needed to find the
>> >         path - rooted in the real world of real adoption by real users
>> >         of the technology.  If it (digital identity) was "easy" it would
>> >         have been solved 15 years ago.
>> >
>> >         And if the people solving it has been at all familiar with the
>> >         literature and cared about privacy they wouldn't have made
>> >         SD-JWT.  If
>> >         we end up with SD-JWT everywhere choking the oxygen from a
>> better
>> >         solution that's bad.
>> >
>> >         End of the day there is no protocol police. So what exactly is
>> >         it you
>> >         want the IETF to give you this real world adoption cannot? Why
>> can't
>> >         we say "here's a privacy preserving solution to your problems"
>> >         rather
>> >         than ratify a lot of very flawed work? To be clear I think we
>> >         need to
>> >         have a forum to have this discussion, but to the extent SPICE
>> >         isn't it
>> >         because things continue in OAUTH (thanks to JWT) and the charter
>> >         prejudges the result I'm against it. I'd support a broader
>> charter
>> >         that doesn't have a commitment to ratifying SD-JWT.
>> >
>> >         Sincerely,
>> >         Watson Ladd
>> >
>> >         --
>> >         SPICE mailing list
>> >         [e-mail] <mailto:[e-mail]>
>> >         https://www.ietf.org/mailman/listinfo/spice
>> >         <https://www.ietf.org/mailman/listinfo/spice>
>> >
>> >     --
>> >     SPICE mailing list
>> >     [e-mail] <mailto:[e-mail]>
>> >     https://www.ietf.org/mailman/listinfo/spice
>> >     <https://www.ietf.org/mailman/listinfo/spice>
>> >
>> >
>>
>
>
>