Meeting started right on time - 15:20 Showed Note Well ; thanked Stephen Farrell Going through working group reports. Most had been sent to the list. Going through related working groups. Paul Hoffman talked for a bit about DPrive. Karen talked about NTP. Wendy sent a message to the list about W3C Hannes talked about the TEEP BoF. Half the room didn't understand what they were trying to do. Thinking about what to do next. Presentations: *** Hannes about "EEMBC IoT Security Benchmarks" Hannes's slides: https://www.ietf.org/proceedings/98/slides/slides-98-saag-eembc-iot-security-benchmarks-00.pdf Even lightweight devices can do crypto. http://www.eembc.org/iot-secure/about.php *** David Mazieres "Internet Level Consensus is Practical" David's slides: https://www.ietf.org/proceedings/98/slides/slides-98-saag-internet-level-consensus-ilc-01.pdf Note that there is an IETF mailing list for this subject: https://www.ietf.org/mailman/listinfo/ilc [slide 15] Ted Hardie: A node can select more than one slice? David: Yes, for redundancy. Ted: How can it get a super-set if there's more than one? David: Needs to be a super-set of one? Ted: Does is work if there's only one? David: Yes, but if one member of the slice is down, you can't get a quorum and thus no consensus. * Bar BoF tonight, 7:30pm–9:00pm MCR: You talked about CAs and public knowledge. Financial transactions are not public knowledge. How is that handled? David: The log is public, but there are ways that people who don't know the transactions to not get this. It's on a different layer. Melinda Shore: This is a distributed computing problem more than security. We have a long history of kicking those down the road. Homenet, Trans are publishing consensus protocols. Christian Huitema: Sybil attack? (https://en.wikipedia.org/wiki/Sybil_attack) question about who is allowed to be on the tier of trusted nodes. David: decided by consensus. transitive trust. You might choose, e.g., 30 CAs + locally trusted org Kyle Rose: How do you converge if there is disagreement on timestamp David: You'll converge on a set of nominated values. Challenge depends on the usage. In markets, concerned about front-running, more of a concern than in software transparency Tim Sheppard: the problem of deciding who the roots of the CA us is solved? David: We'll have people decide for themselves. If there's enough overlap it will work. *** Sharon Goldberg on "Verifiable Random Function" Sharon's slides: https://www.ietf.org/proceedings/98/slides/slides-98-saag-verifiable-random-functions-vrfs-00.pdf Ben Kaduk: Is there a way to verify that the hasher is not denying things in the data structure? Sharon: That is proved by the structure of the data structure itself. If something is absent the data structure will show it. The hasher cannot deny that something is present or absent. Richard Barnes: Trying to figure out what you can build on top of this. Are all VRFs of this form (hash + signature)? Sharon: (slide 17) - the signature is the proof. The signature needs to be deterministic, so you can't use ECDSA (which is non-deterministic). In EC-VRF we use the X coordinate of gamma for "hash". Phil???: Sharon: these are all VRFs in the ROM. Don't know what it says about post-quantum (?) Wes Hardaker: If I were able to collect a bunch of proofs over time, I could do dictionary attacks? Sharon: When you see a proof, you can verify it if works for an input. Wes: and it would be a strange protocol where I couldn't see the inputs but could see the proofs *** Phillip Hallam-Baker on "JSON implementation of Mesh/Remesh" PHB's slides: https://www.ietf.org/proceedings/98/slides/slides-98-saag-json-implementation-of-meshremesh-00.pdf (just one slide) (no questions) *** Open Mic Ingo Stieglitz : Thank you. You are all awesome. Is there any work here on ICMP NATing Kathleen: Recommend you ask in Ops Yoav Nir: A couple IETFs ago, started to discuss 3552bis, what should go into security considerations. I did a first transposition, called for comments, and got nothing. We shouldn't send the message that there's nothing to add since 2003 [by publishing a new unchanged document]. We need people to propose text and ideas. Hannes: We asked for update without knowing what the update would be. What is the target audience? What should the recommendation be? Yoav: 3552 and bis, target audience is people who write RFCs. Security Considerations sections target the same audiences as the RFCs themselves. Hannes: this isn't the way people write security considerations. they cut-and-paste from existing documents. Kathleen: At SecDir, not everyone is comfortable with privacy; we might do better on those reviews if we got more info into the bis. Paul Hoffman: One problem with the original document is its length: 40 pages. Mix of good examples, etc. but many people don't want to read that long. A shorter document would be better for doc authors. Matt Mathis: speaking as an author in other WGs, the presence of Security Considerations section has caused us to take things out of documents; that the review doesn't pick thnigs up doesn't mean it hasn't helped. David Black: Example in Ops: appendix with a list of questions an ops reviewer should ask. (Appendix A of RFC 5706) Kathleen: How many people interested in an update? [about 20 hands]. Please discuss on SAAG list. And we're done (16:48)