Skip to main content

Minutes IETF118: secdispatch: Mon 14:30
minutes-118-secdispatch-202311061430-00

Meeting Minutes Security Dispatch (secdispatch) WG
Date and time 2023-11-06 14:30
Title Minutes IETF118: secdispatch: Mon 14:30
State Active
Other versions markdown
Last updated 2023-11-13

minutes-118-secdispatch-202311061430-00

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