Re: [Secdispatch] [EXTERNAL] Re: [SCITT] Request for session at IETF 113

[Antoine Delignat-Lavaud <[e-mail]>]

Hi Ekr and thanks for your excellent technical comments.

Regarding (1) this is very much something to be aware of in deciding which DID schemes should be recommended by the standard. Generally you would expect that transparency services should prefer fully replayable/verifiable DID resolution methods (and it is indeed quite hard to make did:web verifiable with TLS 1.3 where all cipher suites are AEAD without using advanced verifiable computation crypto). It is not clear what choice would fit most binary transparency users; maybe something based on DNSSEC could fit the bill, but at this point the question is open for comments.

(2) is a good argument, though unlike certificates there isn't an obvious universal mechanism to attach SCT to signed binaries. Receipts also have the benefit to work with unsigned artifacts, which are a legitimate use in non-software supply chain. More is definitely achievable to integrate transparency into binary signing in the style of today's certs.

(3) is up for discussion but we would rather avoid a mess like pre-certs in CT, such as commitments to artifacts that are not known at claim registration. Note that related to the previous point the receipt is separate from the artifact in SCITT so there should not be as much latency pressure as in CT, if the receipt is obtained asynchronously. However, getting more feedback from maintainers of existing binary transparency systems would be helpful.

Best,
Antoine

From: SCITT <[e-mail]> On Behalf Of Eric Rescorla
Sent: 21 March 2022 23:22
To: Birkholz, Henk <[e-mail]>
Cc: [e-mail]; IETF SecDispatch <[e-mail]>
Subject: [EXTERNAL] Re: [SCITT] [Secdispatch] Request for session at IETF 113


OVERALL
This document describes a general structure for providing transparency
for  software artifacts, effectively a generalization of what's often
called "binary transparency". This is a useful kind of service in concept
an at least theoretically an appropriate topic for IETF.

The answer to the secdispatch questions depends, I think on the level
of interest people have in deploying such a service and especially
with this as a starting point. Specifically, we'd need to hear from:

- Software vendors
- Potential transparency service (log) operators.

I'd particularly like to hear from people who already are involved
with Binary Transparency: https://developers.google.com/android/binary_transparency<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelopers.google.com%2Fandroid%2Fbinary_transparency&data=04%7C01%7Cantdl%40microsoft.com%7C448f5c11a113497f9e7008da0b91d09a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637835018189784163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=KMKXKvlTYUbhmTgQY9AavdSEqFuJ1Lao%2F5eMyK9s5%2B4%3D&reserved=0>

If there is interest, I would be supportive of moving forward with
this. Given the complexity of the topic, a BOF is probably the next
step.


TECHNICAL
I do have a few small technical comments.

1. I'm still working through the semantics of the identities you are
   using. As I understand it, the signatures are intended to provide
   evidence that the vendor actually published something, but if you
   use did:web, then can't the vendor just use a different key for
   each signature and remove the key from the Web site later. What
   proof is there that the vendor endorsed a specific key?

2. I understand the appeal of the append only log, but I'd observe
   that much of the value in CT has been achieved without any real
   verification by clients of the inclusion proofs but just relying
   entirely on SCTs. So, perhaps we don't need to try as hard
   here. This point applies to BT as well, I think.

3. S 6.3 seems to require the claim to be appended to the log prior to
   issuing the receipt. This is not how CT is architected, as I
   understand it because of concerns about the latency of that
   process. Instead, certificates have SCTs. Do similar concerns
   apply here?

I'm sure all of these could be addressed during the standards process,
and they certainly don't preclude doing this work, but I noted them
as I read the document and thought it would be good to record them.








On Wed, Mar 9, 2022 at 2:40 PM Henk Birkholz <[e-mail]<mailto:[e-mail]>> wrote:
Hi secdispatch,
(hi scitt),

emerging work on the topic of Supply Chain Integrity, Transparency,
Trust has taken some shape recently.

The work combines existing IETF building blocks to facilitate useful
Internet-based support of global supply chain interoperability.

Current contributions focus on the definition of Transparency Services
based on Internet technology (using CBOR/CDDL/COSE) to achieve
unambiguous, scaleable, and resilient integration with common devops and
secops requirements.

I'd like to request secdispatch agenda time for two documents that are
currently submitted:
  > https://datatracker.ietf.org/doc/draft-birkholz-scitt-architecture/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-birkholz-scitt-architecture%2F&data=04%7C01%7Cantdl%40microsoft.com%7C448f5c11a113497f9e7008da0b91d09a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637835018189784163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=kYB%2BZyzNWT2BvRNewYHBYJANYh3WQsPbYzowoEeMV%2FI%3D&reserved=0>

and

> https://datatracker.ietf.org/doc/draft-birkholz-scitt-receipts/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-birkholz-scitt-receipts%2F&data=04%7C01%7Cantdl%40microsoft.com%7C448f5c11a113497f9e7008da0b91d09a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637835018189784163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iyQcUeZ%2BbuzW%2FUncjOIPndC%2Fr9%2FILP%2FzNh2hqiu5ndI%3D&reserved=0>

These two contributions are in -00 state. Yet, they already address
essential requirements, such as, air-gapped validation when being
offline, integration of remote attestation, efficient and crypto-agile
signing prescriptions for out-of-the-box interoperability, and - in
essence - long-long-term guarantees in support of various types of
supply chains requirements.

We'd be happy to present this emerging work in secdispatch with the goal
of discussing whether it might fit into the IETF space and how to
progress it together.

Viele Grüße,

Henk



On 26.02.22 02:29, "IETF Secretariat" wrote:
> Dear Mohit Sethi,
>
> The session(s) that you have requested have been scheduled.
> Below is the scheduled session information followed by
> the original request.
>
>
>      secdispatch Session 1 (2:00 requested)
>      Tuesday, 22 March 2022, Afternoon Session II 1430-1630
>      Room Name: Grand Park Hall 3 size: 250
>      ---------------------------------------------
>
>
> iCalendar: https://datatracker.ietf.org/meeting/113/sessions/secdispatch.ics<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F113%2Fsessions%2Fsecdispatch.ics&data=04%7C01%7Cantdl%40microsoft.com%7C448f5c11a113497f9e7008da0b91d09a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637835018189784163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=CfvI4TXyDkZcBgkRYsI6jI6BYwTNre0wRCBmUCf1A8o%3D&reserved=0>
>
> Request Information:
>
>
> ---------------------------------------------------------
> Working Group Name: Security Dispatch
> Area Name: Security Area
> Session Requester: Mohit Sethi
>
>
> Number of Sessions: 1
> Length of Session(s):
> Number of Attendees: 200
> Conflicts to Avoid:
>
>
>
>
> People who must be present:
>    Benjamin Kaduk
>    Kathleen Moriarty
>    Mohit Sethi
>    Paul Wouters
>    Richard Barnes
>    Roman Danyliw
>
> Resources Requested:
>
> Special Requests:
>    Please avoid conflict with any Security related BoF.
> ---------------------------------------------------------
>
>
> _______________________________________________
> Secdispatch mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/secdispatch<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsecdispatch&data=04%7C01%7Cantdl%40microsoft.com%7C448f5c11a113497f9e7008da0b91d09a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637835018189784163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=cP73pgYaZFajY9JxODBB6YSIiEHTlNddKunfEZHS7ZE%3D&reserved=0>

_______________________________________________
Secdispatch mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/secdispatch<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsecdispatch&data=04%7C01%7Cantdl%40microsoft.com%7C448f5c11a113497f9e7008da0b91d09a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637835018189784163%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=cP73pgYaZFajY9JxODBB6YSIiEHTlNddKunfEZHS7ZE%3D&reserved=0>