# Secdispatch IETF 118   {#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)   {#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)   {#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)   {#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