Secdispatch IETF 118
Co-chairs: Rifaat Shekh-Yusef and Daniel Kahn Gillmor
Note-taker: Leif Johansson
Intro by chairs.
On Network Path Validation – Chunchi Liu (20 min)
https://datatracker.ietf.org/doc/draft-liu-on-network-path-validation/
Correction: the most current draft is
https://datatracker.ietf.org/doc/draft-liu-path-validation-problem-statement/00/
Presentation by Peter Liu (PL).
- Richard Barnes (RB): non-transit should be clearly out of scope
- RB: how to deal with untrusted parties between trusted parties?
- PL: next step is looking at that
- RB: no cryptographic way to prove the absense of untrusted parties
- RomanD: lets focus on the DISPATCH result we want
- RB: BoF, if anything. Need clarity on (1) not proving non-transit,
and (2) what this reveals to untrusted intermediaries
- Jeff Haas (JH): thx for updating based on previous convos. Use-cases
are on the week side with some exceptions eg preventing spoofing
- DKG: what does that mean for dispatching?
- JH: needs more iteration on use-cases. Probably needs to go to INT
area.
Benjamin Schwartz(BS): don't buy the security argument. I either
trust the routers on the path or I don't - either way the solution
doesn't work. Possibly there is use in order to detect misconfig.
Suggest dispatch to spring.
- PL: ... possibly more related to routing/ops
- BS: (makes some point about recursion)
- RB: needs mutiple domain expertiese - eg there is non-trivial crypto
involved here, hence argument for BoF if anything.
OUTCOME: Needs more discussion, especially alignment on goals /
deliverables
Expect Signed Mail – Daniel Kahn Gillmor (20 min)
https://datatracker.ietf.org/doc/draft-dkg-lamps-expect-signed-mail/
Daniel Kahn Gillmor (DKG) takes off hat and speaks about signed email
- Phil Hallam-Baker (PHB): history lesson. Suggest dispatch to lamps
for the community. We should not be disappointed when we fail fixing
email. smtp is dying.
- Paul Wouters (PW): not a lot of security specific protocol design.
Mostly this is about signaling and ux. Dispatch somewhere in ART
pershaps?
- RomanD: no good WG for email "stuff" where this would be in scope
for in ART. Next step could be ART dispatch.
- Ted Hardie (TH): suggest talk to MARC.
- DKG: this is somewhat different
- TH: suggest running a BoF on this. There are lots of corner cases.
- Yaron Sheffer (YS): I don't hear the word "encrypted". People care
more about confidentiality. Does this affect scope? Include
confidentiality.
- DKG: semantics of encryption is different. This is deliberately not
included. This would add confusion. Lamps has interesting threads
about encryption.
- YS: BoF this
- Deb Cooley (DC): Unfortunate thing about signing is, if anything on
the path changes something, the signature breaks. Not under endpoint
control. How do you deal with that?
- DKG: catalogue the common ways things break so the user(s) can try
to mitigate
- DC: Lamps or BoF. A BoF may send you to lamps anyway.
- AJ Stein (AJ): Even if smtp is on the way out it will be around for
long enough to warrant spending the time.
OUTCOME: consult with ART
SAV-based Anti-DDoS Architecture – Linzhe Li (20 min)
https://datatracker.ietf.org/doc/draft-cui-savnet-anti-ddos/
Linzhe Li presenting SAV-D
RB: In order for this to be useful, you need not only enough SAV
networks, but to have enough density of DDoS participants in a SAV
network to block the network. Neither of these seems to be true.
BS: need clear realistic use-case. This also looks like a pervasive
passive monitoring system [RFC7258]
OUTCOME: need more discussion