Secdispatch @ IETF109
Monday, November 16, 2020, 16:00-18:00 ICT (UTC +7)
Chairs: Francesca Palombini, Kathleen Moriarty, Richard Barnes
Jabber logs: https://www.ietf.org/jabber/logs/secdispatch/2020-11-16.html
(1) An Interoperability Architecture for Blockchain Gateways (Thomas Hardjono)
(2) DANE for IOT security (Shumon Huque and Ash Wilson)
(3) Signature Validation Token (SVT) (Stefan Santesson)
Minute takers: Kathleen is jabber scribe, dkg is note taker
- some confusion around SVT (whether it has already been dispatched). A list should have been created after IETF 108, but was not followed through on. If we’re going with a new list, Stefan should follow up with ADs (Ben Kaduk) about creating the list, which can itself be re-used for a new WG if appropriate.
An Interoperability Architecture for Blockchain Gateways
link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/tPEd-CcPyqzcxGPju5gSRhVoQLg/
presenter: Thomas Hardjono
time allocated: 30min
authors’ objective: BoF
- Alissa Cooper notes https://datatracker.ietf.org/doc/html/draft-thomas-interledger-00
- ekr: there are a bunch of concepts i see in here that are unusual for the IETF. The distinction between your proposal and the distributed gateway protocols we’ve done is that IETF understood those problem domains. You’d need to get several large participants to join in to change my mind (ok with mailing list, though)
- Wes Hardaker: how large would this solution apply in the real world? this seems like an n² problem. if you don’t have buy-in from a lot of people, this could be a lot of work for little gain
- Thomas: the space is more mature than it used to be. Central banks with their own currencies are contemplating the need for their own sovereign digital currency
- dkg: how can one of two systems (distinct DLTs) be able to prevent double-spend in the other DLT?
- Thomas: at the least, each DLT has to promise to the other one that the assets in question are locked during the transaction, and then destroyed on the source system after the transaction completes
- Wes Hardaker: do the gateways need to know who each other is?
- Thomas: yes, there is no anonymity here. the gateways need to have device (legal) identities.
- Wes: seems like there are risks of disclosure of asset holding, etc, given the lack of anonymity.
- Thomas: yes, this comes from legal requirements in the finance world
- Phillip Hallam Baker: audio failure
- Kathleen: have you talked to Sharon Goldberg?
- Thomas: yes, i have.
- Francesca: the chairs are hearing that there is support for a mailing list. in fact, we have one already: firstname.lastname@example.org
- ekr: so do we need to do anything else? can we just observe the activity there to see whether anything else is needed?
- Alissa Cooper: Meetecho is going down for about 5 minutes
DANE for IOT security
link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/PXAN6rBQSDKtn7jKNPit4_xno58/
presenter: Shumon Huque
time allocated: 30min
authors’ objective: get feedback?
- Eliot Lear: can you talk more about IoT use case?
- Phillip Hallam-Baker: devices don’t really fit into the PKIX/X.509 model, and DANE dosn’t help very much
- Eliot Lear: missing a lot of information: i have questions about dependencies, and it’s something similar to a half-dozen diffrent mechanisms. maybe IOTOPS if that gets formed?
- Richard Barnes: maybe a BoF would be useful to figure out a more holistic view? we could also set up a mailing list
- Eliot: can we use email@example.com?
- stephen farrell: i don’t understand the topic of the proposed BoF
- Eliot: Anima, Ace, Teep, dan harkins, “our colleague from malaysia” all offer relevant/adjacent topics
- Roman: non-wg-forming is the right way to go. we don’t understand how to get the names mapped to these devices in the first place. DANE to a non-unique name doesn’t help much.
- Shumon: yes, names will be unique. there’s a provisioning process.
- Ben Kaduk (AD hat on): not a super clear outcome, but there’s activity in this space. I’m not sure i understand the scope, so it sounds like further discussion to me, but not sure what the right next step is.
- Francesca: next step is BoF, maybe use firstname.lastname@example.org ML in the meantime
- Shumon: if the BoF is supposed to cover related protocols, then i’ll need Eliot to supply that list of additional related protocols.
- Francesca: reminder: we determine the right next steps in secdispatch, but the onus is on the advocates to make those next steps actually happen.
Outcome: continue discussion on email@example.com (sync with https://datatracker.ietf.org/wg/iotops/about/ work )
Signature Validation Token (SVT) update – Dispatched already
link to mail post: https://mailarchive.ietf.org/arch/msg/secdispatch/pGYvDunuUMxVYexPQt1h1i78lDA
presenter: Stefan Santesson
time allocated: 15min (more if time allows)
author’s objective: mailing list creation, new WG, or assign the work to an existing WG
- this was dispatched in IETF 107, have things changed that warrant a reassessment?
- Roberto Polli: other organizations (e.g. in Europe) that are organizing a json structure for storing signatures (eIDAS, ETSI). not exactly the same thing, but maybe you want to talk with them?
- Stefan: ETSI work is complementary to this work, it’s about including cascading evidnce in a document, but it’s not the sam thing.
- Hank Birkholz: why are you using tokens? aren’t tokens typically short-lived? it seems odd to use them in this long-life context.
- Stefan: you can treat the tokens as much longer-lived,
- Francesca: needs more discussion. what i’m reading from the chat is not LAMPS. if it continues it needs its own WG, but for now we just need to go ahead and get that ML set up.