Subject: [saag] Draft minutes

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Mar 2017 08:15:27 -0500

Here are the draft minutes (thanks to Yoav and Wendy). Yoav, I edited your
remarks about 3552 bis a bit to try to get at what I thought you were
saying. Can you check and see if I have it right and otherwise send a
correction?

Thanks
-Ekr

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.
@@: 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.
Kathleen: How many people interested in an update? [about 20 hands]. Please
discuss on SAAG list.

And we're done (16:48)

---

From: "Black, David" <[email-masked]>
Date: Fri, 31 Mar 2017 15:39:04 +0000

> @@: 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.

“@@” was Matt Mathis.

> David Black: Example in Ops: appendix with a list of questions an ops reviewer should ask.

It would be helpful for the minutes to note that this is Appendix A of RFC 5706 (as indicated in subsequent email to the list).

Thanks, --David

From: saag [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Friday, March 31, 2017 9:15 AM
To: [email-masked]
Subject: [saag] Draft minutes

Here are the draft minutes (thanks to Yoav and Wendy). Yoav, I edited your remarks about 3552 bis a bit to try to get at what I thought you were saying. Can you check and see if I have it right and otherwise send a correction?

Thanks
-Ekr

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.

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.
@@: 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.
Kathleen: How many people interested in an update? [about 20 hands]. Please discuss on SAAG list.

And we're done (16:48)