Minutes IETF98: saag
minutes-98-saag-01

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)