IETF 107 - DISPATCH WG / ART Area session Audio Conference- Virtual Meeting - 22::00 UTC 23 March 2020 conference call recording: https://www.youtube.com/watch?v=CYqB6Xk4NTE The chairs would like to express their gratitude to Jean Mahoney and Bron Gondwana for leading the note taking effort and for E Sam covering the jabber relay. Dispatch Action Summary The chair discussion acknowledged the limitations of a virtual meeting. The call was structured to take questions at the end of the presentations in order to better coordinate the speaking queue. Attendees were asked to rely on the list more heavily than is usual for Dispatch given the circumstances of a virtual meeting and the difficulties in measuring consensus in that environment. The agenda was modified based on a suggestion from the chairs to defer the ASAP work to the list as we are close to a proposed charter and that forum seems easier for wordsmithing. No other agenda modifications were proposed. Due to the unusual format of the meeting it was less clear than usual what items were being discussed as DISPATCH and what as ART area. The chairs will improve on that in the future. Much of the meeting time was spent discussing email security in a discussion lead by Michael Peddemors. The general feeling in the ‘room’ was that an eventual BoF was the right outcome for this worth but a first step should be bringing a proposed charter and statements of interest to the dispatch list. Brad Peabody discussed work related to UUID v6 on a FYI basis. Mark Nottingham discussed work related to Link Hints. After some discussion the idea of a potential WG devoted to HTTP APIs was raised. Mark will investigate the viability of that approach and placed the Link Hint work on hold pending the outcome. Maxim Sharabayko discussed SRT (Secure Reliable Transport) - an existing low latency video protocol being introduced to the IETF here. There was substantial discussion about how its features interacted with existing IETF protocols and how it is expected to evolve in the future. The discussion is captured in the minutes below and on the audio recording. Maxim indicated that the existing version of the protocol would be unlikely to yield technical change control to the IETF, but the authors would be interested in collaborating on the future. The dispatch advice given was to consider the Individual Submission path for potential publication of work the IETF would not be contributing engineering work to and afterwards explore again with dispatch how the IETF could collaborate on the evolution of SRT. Detailed notes follow: DISPATCH / ART Area @ IETF107 Virtual Meeting - 23 March 2020 22:10-0:10 WebEx: https://ietf.webex.com/ Jabber Chat: xmpp:dispatch@jabber.ietf.org?join Chairs: Patrick McManus, Ben Campbell Notetakers: Jean Mahoney, Bron Gondwana Jabber Scribe: E Sam ********************************************************************** Agenda & Minutes IETF 107 DISPATCH and ART AREA ********************************************************************** DISPATCH Meeting ---------------- ### Status and Agenda Bash - Chairs and ADs (15 min) ### Client-ID and Email Security - Michael Peddemors (30 min) [SMTP-ClientID](https://tools.ietf.org/html/draft-storey-smtp-client-id-08) [IMAP-ClientID](https://tools.ietf.org/html/draft-yu-imap-client-id-03) ### Automatic Peering for SIP Trunks - Kaustubh Inamdar/Sreekanth Narayanan(15 min) Discussion: Should DISPATCH recommend formation of a mini-working group with a charter similar to the proposed? [Proposed Charter](https://mailarchive.ietf.org/arch/msg/dispatch/o3ijbrtRX5lpGuY-eqZ_nGf_f_E) This item may be removed during agenda-bashing. ART AREA Meeting ---------------- ### BoFs and meetings of interest - ADs and BoF Chairs (10 min) ### UUID Format Update - Brad Peabody (15 min) [Draft](https://tools.ietf.org/html/draft-peabody-dispatch-new-uuid-format-00) ### HTTP Link Hints - Mark Nottingham - (5 min) [Draft](https://tools.ietf.org/html/draft-nottingham-link-hint-02) ### If time permits: Secure Reliable Transport SRT Discussion: Where does discussion of this belong? [draft][https://tools.ietf.org/html/draft-sharabayko-mops-srt-00] ### AOB ********************************************************************** MINUTES ********************************************************************** Patrick introductions: * We will take questions at the end There was no agenda bashing from the floor. The chairs moved the ASAP discussion to the list. Client-ID - Michael Peddemors * Suggest via Dispatch - find new home at IETF. John Levine: this is worth a working group - make it clear that this is client to server. Not a fan of CLIENTID though, it's just another password to steal. Maybe a time-based password. Yes WG, No this draft. ekr: Likewise From Jabber: sftcd, Alexey Melnikov: +1 - plus about 7 others! sftcd: only valid Michael: need to make a home first ekr: is this encrypted or not? If it's only sent over encrypted then password is pretty good (though shared passwords are still a problem) dkg: this wouldn't be a human-generated password so can be high entropy (so scripted password guessers not a problem) Ben Campbell: If creating a WG then we need to create a charter. These drafts may or may not be an input. Worth exploring this. Michael: what is the problem statement the working group is attempting so solve? Suggest top 3 methods of email compromise. Seth Blank: WG makes sense, concerned about scope + broadness of problem area. Top 3 attacks is wrong place to start, and CLIENTID is wrong place to start. Credential easy to forge like HELO name. Seth: want do do away with pre-establised sender/receiver secrets - there's a bootstrapping + global accessibility problem. Pete Resnick: we need a more focused problem statement rather than just two protocols to go after. Suggest write a few paragraphs that will form part of a charter. Are there IPR statements on this? Michael: we've already made IPR statements on this. It's our goal to have the whole world adopt these. We've contributed code to open source projects. Only intellectual property is around threat detection, which is above and beyond actual spec. Pete: you want to fill out IPR disclosure form? Michael: already did. Richard Barnes: If a WG were to be formed, we need to have an idea what problem is being solved. E.g. if it's already deployed. There's also prior art in the web space, we should lean on that. Michael: there's deployed us. Sanebox, Bluehost, etc... even Thunderbird. Couple of million users in North America. Spencer: Is there carrier interest? Michael: there's ongoing discussions with major carriers. Some of our customers are midlevel carriers who are excited. Enterprise is excited too. dkg: this is not how we'd be designing a security mechanism today. This isn't the right draft. Murray: is there any experience that's already been had with this that you could point to. Richard Barnes: Not hearing energy to form a group - would need to see a charter first Seth Blank: what's interesting is "where can we add 2 factor"? Cullen: ... Would need to see a charter. Pete: is it appropriate for Michael to post things like a mushy charter and feedback from implementers in dispatch list, or do we need a new list first? Ben: we'll hear from Barry! Barry: a bit more discussion on Dispatch is fine, but more than that would need a new mailing list. There's interest in 2fa for email - maybe Michael should join a group doing that. Bron: don't forget JMAP! Also is TxAuth right? Michael: don't think TxAuth is the right thing - that's very targetted and quite unrelated. Michael: should have a separate mailing list where we can engage all the various people - worried they don't have a voice on dispatch. Barry: the email people who are part of IETF are already here on dispatch. If you have other people not part of IETF to bring in, a separate email list is good. Ben Campbell: Have talked about a charter and a WG - does anybody think it needs to go to a bof. Mark Nottingham: it should go to a BOF. sftcd: if there's interest, don't need a BOF. Pete Resnick: a BOF is appropriate, but don't need to wait to work on charter - let's do that first! Barry: what Pete said. Right thing to do now is somebody make a non-wg mailing list request and send it to me. I will create it. Bron: should we reanimate an old one? Barry: think it's different enough. Patrick: next step is a proposed charter abnd list. hard to summarize, we'll create a summary to the list with our understanding. drafting a potential charter, and finding a place for the work. UUID version 6 - Brad Peabody presenting https://datatracker.ietf.org/meeting/107/materials/slides-107-dispatch-uuid-v6-slides-brad-peabody-00 * ted.h: this points to creating an identifer which is not a UUID, this handily avoids the "3 different places standardized UUIDs at the same time" issue. * Richard Salz: what do you mean by sorting? Brad: if you have it as a database key, what order is it returned in? So e.g. a database table of users where UUID is key, want it to sort in order. * Richard Barnes: Why do we need a specification here? The usecases so far are internal to a database, why do you need a spec for inter-vendor interop? Brad: it will need to be read by other tooling, so we it needs to be transportable, e.g. other systems. * ekr: this is fine, but it doesn't guarantee uniqueness. * from jabber: does IETF own UUIDs? Stuart Card - UUID v 6 is facing the same issues as DRIP, meeting wed night. BoFs and meetings of interest - We looked at the upcoming events during the week. Pete Resnick described gendispatch agenda topics. Richard Barnes covered secdispatch. Link-Header: Mark Nottingham - presented in 2013 in ART area meeting. - looking for feedback about what to do next? Maybe HTTP - but not really http. - independent or AD or HTTP API specs? Seth Blank: something like this is a hot topic at M3AAWG right now. Want to describe what's in a HTTP payload. Might be a good place to discuss this at M3AAWG. Would love to connect Mark with that group. Mark: thanks! A little cautious. Seth: at M3AAWG there's a set of specific usecases. Concrete problems. Harold Alvestrand: don't understand the security model of this. Reminds me of bundles - pieces shipped together. "I'm going to tell you what you'd find at this other place". Mark: it's more "here's how you could interact with this". Spencer Dawkins: experience with AD sponsored drafts when proponents don't have much energy is not good. Richard Barnes: there's specs for things like "here's the REST APIs on this server". from jabber: maybe this should be a W3C thing, particularly for M3AAWG. Robert Sparks: is there an easy place to find the painful water that's already gone under the bridge? Mark: I wanted this in dispatch. Barry: let's treat it like Dispatch... what do YOU want? Mark: be interesting to do a WG for http APIs in general, but maybe this is small. Barry: maybe this could be a seed. Alexey via Jabber concurs. Devil is in the details. Patrick: httpbis could process this one, but if there are others then we can create a group. Mark: it's waited for a long time, doesn't hurt if it waits a little longer. Ben Campbell: should we re-ask dispatch questions on the mailing list? Or have we learned enough to make a dispatch decision already? Mark: why don't I explore idea of what the charter for the APIs group would look like. SRT protocol: Maxim - we have time! Spencer Dawkins: thanks for bringing this - question: do you intend to work on this further or publish what you've got? Should this be informational? Spencer: other working groups have done "informational v1" followed by working on v2 for standards track. Richard Barnes: how much tolerance is there for changes? Maxim: SRT is very open to changes in encryption mechanism and in other parts. Would like to have some proposals. ekr: What functionality does this have that QUIC doesn't that makes it better? Maxim: QUIC proposes a datagram extension - UDP with encryption and feedback. SRT also brings latency management, de-jittering, packet ordering. dkg: via jabber - could this be a queueing discipline for specific streams in QUIC? Spencer: likewise with transport protocols, how possible is it to evolve? E.g. new congestion control mechanisms. Maxim: yes we're flexible with congestion control. Cullen Jennings: where would I find out about congestion control? Maxim: yes, Github code is the right place now. Bernard Aboba: Is there a plan to implement something like SRT on the web? Because you don't get direct UDP access - they way to get it is QUIC. Maxim: A lot of browsers already support QUIC because it is implemented in the chrome engine. Would be good to have SRT there too. Alternatively on app sockets, but that would be tougher. Colin Perkins: how does this relate to RTP? It seems similar. Maxim: SRT isn't something that can't be found in other protocols - with RTP you have unreliable delivery of UDP, then you need an additional control channel over TCP. With SRT you get it all in one protocol. Colin: people have been multiplexing stuff with RTP for a long time. Maxim: yes, but you get it all out of the box with SRT. Furthermore, SRT is agnostic to what content to deliver. Patrick: question "is this document existing or do work"? Maxim: would be good to do informational first, and potential to extend. Patrick: start with ISE. Independent Stream.