Subject: Re: [Secdispatch] secdispatch - Requested session has been scheduled for IETF 113

From: Sean Turner <[email-masked]>
Date: Tue, 1 Mar 2022 23:52:47 -0500

Ladies and Gentleman,

I my be totally jumping the gun here because you have not yet requested agenda topics, but when you do please note that I would like to request some time to dispatch draft-ciphersuites-in-sec-syslog.

Cheers,
spt

> On Feb 25, 2022, at 20:29, IETF Secretariat <[email-masked]> 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
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdispatch

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 2 Mar 2022 06:23:09 -0500

Thank you, Sean.

Requests are welcome and we do have at least one other.

Best regards,
Kathleen 

Sent from my mobile device

> On Mar 1, 2022, at 11:53 PM, Sean Turner <[email-masked]> wrote:
> 
> Ladies and Gentleman,
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 9 Mar 2022 23:39:18 +0100

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/

and

> https://datatracker.ietf.org/doc/draft-birkholz-scitt-receipts/

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

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 21 Mar 2022 16:22:24 -0700

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

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 <
[email-masked]> wrote:

> > iCalendar:
> https://datatracker.ietf.org/meeting/113/sessions/secdispatch.ics
> >
> > Request Information:
> >
> >

---

From: Richard Barnes <[email-masked]>
Date: Tue, 22 Mar 2022 07:31:04 -0400

Hi folks,

It looks like at a high level, the approach here is along the same lines as
what has been discussed as "Binary Transparency" elsewhere.  There have
been several stabs taken at this before.  See, for example:

https://www.sigstore.dev/
https://unmitigatedrisk.com/?tag=binary-transparency
https://github.com/FreeBSDFoundation/binary-transparency-notes/blob/master/debian.txt
https://wiki.mozilla.org/Security/Binary_Transparency

While these existing approaches do help validate that there is some
interest in the field for what SCITT does, it's not clear how SCITT is
different from / better than this prior art.

--RLB

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 22 Mar 2022 09:20:58 -0400

Greetings,

I have some similar questions, and question the hard requirement for a DID.
It seems that there will be many use cases that would want a traditional
PKI like is used with SigStore for a higher level of assurance. Both a
traditional PKI and a distributed can use the distributed ledger.

I am aware of vendors looking at this solution, so there's support behind
it. They also want to make sure the right thing is done, hence it coming to
the IETF to get broad review.

I think on the signature part, it would be useful to also support PKI with
ACME and to see the client authentication methods supported as sigStore
uses a certificate (their flow is a little different from ACME at the
moment).

I also support this being developed in the IETF as it's an important
problem set and now has vendor traction due to requirements. I'd just like
to see support for traditional PKI and ACME for the certificates/keys.

I have to go through the document more closely as the problem set needs to
consider organizations and individuals in terms of scale as well. How will
this be managed? Will it be manageable and can it be architected to reduce
the distributed burden so that security just works (as opposed to needing
another million jobs to be filled that can't be filled).

It's an important problem and would benefit from the IETF review process
and openness to bring more vendors together than those who are already
participating.

Best regards,
Kathleen

On Tue, Mar 22, 2022 at 7:31 AM Richard Barnes <[email-masked]> wrote:

> Hi folks,
>
> It looks like at a high level, the approach here is along the same lines
> as what has been discussed as "Binary Transparency" elsewhere.  There have

-- 

Best regards,
Kathleen

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Tue, 22 Mar 2022 13:23:41 +0000

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 <[email-masked]> On Behalf Of Eric Rescorla
Sent: 21 March 2022 23:22
To: Birkholz, Henk <[email-masked]>
Cc: [email-masked]; IETF SecDispatch <[email-masked]>
Subject: [EXTERNAL] Re: [SCITT] [Secdispatch] Request for session at IETF 113

OVERALL

- Software vendors

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>

TECHNICAL

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

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>

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:
> 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:
>
>
> [email-masked]<mailto:[email-masked]>
> 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
[email-masked]<mailto:[email-masked]>
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>

---

From: Chris Inacio <[email-masked]>
Date: Tue, 22 Mar 2022 13:26:28 +0000

Henk,

Just a quick comment before the start of the actual SECDISPATCH session: signing an ML algorithm isn’t all that interesting, _maybe_ signing the model is a bit more interesting.  What’s really interesting is the data used to create the model, and that is where a lot of work in adversarial AI happens.  But they don’t call it big data for nothing, and I’m not sure the logistics of transparent (big) data, or the privacy impact of that are reasonable.

So maybe a different example may be appropriate.

--
Chris Inacio
[email-masked]

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Date: March 9, 2022 at 5:40:11 PM
To: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject:  [Secdispatch] Request for session at IETF 113

---

From: Ira McDonald <[email-masked]>
Date: Tue, 22 Mar 2022 10:15:06 -0400

Hi,

Please note that ETSI SAI (Security of AI) has been explicitly addressing
these
issues of algorithm/model/data set integrity and attestation for a couple
of years,
has already published several excellent documents and is developing more.

My co-chair in TCG Trusted Mobility Solutions (Alec Brusilovsky,
InterDigital) is a
co-editor and rapporteur (liaison) to TCG from ETSI SAI.

https://www.etsi.org/committee/sai

Interested folks can send me a note (offlist).

Cheers,
- Ira

*Ira McDonald (Musician / Software Architect)*

*Chair - SAE Trust Anchors and Authentication TF*
*Co-Chair - TCG Trusted Mobility Solutions WG*

*Co-Chair - TCG Metadata Access Protocol SG*

*Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer
Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF
Designated Expert - IPP & Printer MIBBlue Roof Music / High North
Inchttp://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]
<[email-masked]>(permanent) PO Box 221  Grand Marais, MI 49839
906-494-2434*

On Tue, Mar 22, 2022 at 9:30 AM Chris Inacio <[email-masked]> wrote:

> Henk,
>
> Just a quick comment before the start of the actual SECDISPATCH session:
> signing an ML algorithm isn’t all that interesting, _maybe_ signing the
> model is a bit more interesting.  What’s really interesting is the data
> used to create the model, and that is where a lot of work in adversarial AI
> happens.  But they don’t call it big data for nothing, and I’m not sure the
> logistics of transparent (big) data, or the privacy impact of that are
> reasonable.
>