# DISPATCH Virtual Meeting @IETF-111 Monday 26 July 2021 19:00-21:00 UTC [MeetEcho](https://meetings.conf.meetecho.com/ietf111/?group=dispatch&short=&item=1) [Notes](https://codimd.ietf.org/notes-ietf-111-dispatch) [Jabber](xmpp:dispatch@jabber.ietf.org?join) DISPATCH Meeting ---------------- The NoteWell was recited. ### Status and Agenda Bash - Chairs and ADs (5 min) ### JWS Clear Text JSON Signature Option (JWS/CT) (20 min) Presenter: Samuel Erdtman [draft-jordan-jws-ct](https://datatracker.ietf.org/doc/draft-jordan-jws-ct/) [Messages](https://mailarchive.ietf.org/arch/msg/dispatch/au-e9vF3TdhomM9hCKhlYKNHeZU/) [DISPATCH options]( https://mailarchive.ietf.org/arch/msg/dispatch/ldkB_LnEQxFxpDTPwjfeMDXAMP0/) [Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-jws-clear-text-json-signature-option-jwsct/) Presentation: It is often desirable to present a signed JSON document as cleartext (i.e. do not base64 encode). This can be done by applying RFC8785 Canonicalization to the payload and adding a detached signature. Carsten Bormann: Comments in chat. This is bikeshed material. This is a more complicated issue. Naming is critical. Sean Turner: Do you think this RFC will be referenced by other WGs? Rules dictate this is at most informational if you intend to go the ISE. Samuel Erdtman: Have been discussions on making it an extension to JOSE, not expecting other WGs to adopt this. More of an in the wild use. Would like a stable reference. Eric Resorla: Not sure if it is a bad idea but ISE is the appropriate route. Canonicalization is needed but should not be mandated for on the wire, the endpoints should canonicalize as part of verification. Cullen Jennings: When we say send this to the ISE we say IETF shouldn't do this (now). Pete Resnick: Idea of a signature that doesn't require ASCII armor is interesting but this approach is not appropriate to IETF. May want to change approach to make it compatible. Show of hands poll: SHOULD THE IETF TAKE THIS ON? (IF NOT, "DO NOT RAISE HAND" COULD INDICATE GOING TO ISE) Raise Hand: 10 Do Not Raise Hand: 28 ### image/webp mime-type registration (10 min) Presenter: James Zern [draft-zern-webp](https://datatracker.ietf.org/doc/draft-zern-webp/) [Messages](https://mailarchive.ietf.org/arch/msg/dispatch/XtRV8K2DTym_aL7eovkB13D0KFU/) [Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-slides-111-dispatch-draft-zern-webp/) Presentaion: WebP is an image format that supports lossy and lossless compression with alpha transparency and animation capabilities. It is supported in all major browsers. Barry Leiba: Doesn't even need an RFC, just write out spec and submit to IANA as expert review request. James Zern: Had tried submission was told it should go via an RFC. Murray Kucherawy: Had suggested this as an option. Barry Leiba: Media types don't require a consensus document. Tim Bray: This is requesting standards tree Barry Leiba: Thats OK. Tim Bray: If there is a document, then just register it, if not, then should be a document. James Zern: We have three separate documents, not one. They cover the bases. Cullen Jennings: Its not the definition of bits, but some of the tags could do to be better described, does not matter where that happens. ### NICER (usage profile of ICE) (20 min) Presenter: Harald Alvestrand [draft-oreland-dispatch-ice-nicer](https://datatracker.ietf.org/doc/draft-oreland-dispatch-ice-nicer/) [Messages](https://mailarchive.ietf.org/arch/msg/dispatch/XtRV8K2DTym_aL7eovkB13D0KFU/) [Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-nicer-nicer-ice-based-on-rtt/) Harald Alvestrand: Presentation Proposal to improve connection establishment. Curently ICE tries many paths, picks one and sticks to it, this is not always optimal. NICER keeps the non-best paths and keeps probing so that choice of path is under constant review. Bernard Aboba: Some of the constraints you specify seem arbitrary, why isn't it possible to change at any time? this is taking something that is out there and making it better. Eric Rescorla: Can see some answers are wrong - this is not AD sponsored. Looks like it could go to MMUSIc which currently owns ICE. Johnathan Rosenberg: This attempts to minize the controller changes but number is not zero. Since controller has to upgrade, should consider going further. My preference would be something with richer set of tools. Would support MMUSIC or another WG to avoid this fragmentation. Harald Alvestrand: Must avoid kitchen sink issue. Justin Uberti: I think there is real value here and we can make a useful contribution without a boat anchor. Cullen Jennings: I think this needs a working group, maybe not MMUSIC though. I don't know why ICE was there in the first place. Charter a new WG with responsibility for ICE in general. Harald Alvestrand: MPLS? Cullen Jennings: I think it is more general. This work leads to more general solutions. We are within striking distance but need more than a few bullet points. Needs new WG. Johnathan Lennox: MMUSIC is a bit too much of a grab-bag, a new WG is a better idea. Phillip Hallam-Baker: FIPE side meeting Tuesday is discussing some of this. Scope for near term extension and for longer term research. Onion routing, link level feedback. Kirsty Paine: Looks like a lot of support for the work, question is MMUSIC or new WG. ### SDP Security Descriptions is NOT RECOMMENDED and Historic (10 min) Presenter: John Mattsson [draft-mattsson-dispatch-sdes-dont-dont-dont](https://datatracker.ietf.org/doc/draft-mattsson-dispatch-sdes-dont-dont-dont) [Messages](https://mailarchive.ietf.org/arch/msg/dispatch/j0n6mubcHh3JqWICDqGlsqlX9xM/) [Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-sdp-security-descriptions-dont-dont-dont/) John Mattsson: Presentation Security Descriptions introduced in SDRP have many security issues. New systems (e.g. WebRTC) have prohibited use. Proposing reclassification as HISTORIC and phaseout strategy. Cullen Jennings: Needs more discussion before decision is made. Are you aware of any system that is vulnerable to SSRC collisions? John Mattsson: No Cullen Jennings: Security descriptions do allow for security proofs. That is why SDES is widely used even for secure systems. Chair: Think we need this discussion with the experts. Cullen Jennings: MMUSIC isn't a security group, clearly the wrong place to discuss. Main alternative to this is not WebRTC, it is a patented tech. John Mattsson: SDES is easy to make secuyrity proofs because it makes assumptions. Cullen Jennings: Question is what the alternative is. We can discuss offline. Roman Shpount: The alternatives don't solve all the problems. We need a new group to develop an alternative before we deprecate SEDS. We need to do a lot of work. Bernard Aboba: Need to look at the scenario in which SDES is to be used. Took an enormous amount of time to get it deployed. Only got secure signal very recently. Barrier to deployment is very high. Eric Rescorla: It is clear SDES is a nightmare. Agree deprecation without alternatives is bad. Need to work out how to fix them. The installed base is significant. Probably requires a new WG to understand arguments and validity. In favor of forming a WG. ### The "large file in email" problem (10 min) Presenter: Bron Gondwana [Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-gondwana-email-big-files-problem/) People want to send larger files than SMTP can handle. There are many different approaches users have to navigate. We need a stardard approach. PHB: Malware is a major security issue. Needs to be a WG. Michael Richardson: Needs to be a WG. Problem is who pays for storage. Need to consider asynchronous nature. Neil Jenkins: People clearly want to do this with email. Standardized version is worthwhile. John Levine: This is a very old problem, we had it on usenet. There's two approaches, external body or divide into chunks. Suggest WG look at both approaches (h/t Ned) and how they have failed in the past. Outcomes (all outcomes are preliminary and will go to the list to be confirmed) * JWS Clear Text JSON Signature Option: chairs did not hear support for the IETF taking on this work at this time; dispatch will not recommend doing so. * image/webp mime-type registration: Murray Kucherawy is deciding between expert review and AD sponsorship * NICER (usage profile of ICE): to be decided by ADs to determine if ice-revisited as a broader topic for a WG would be right, or this would be better in MMUSIC as a standalone item * SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus was sub-optimal. There was support for revisting the space currently standardised by SDP, but not on direction (whether to do a deprecation with/without replacement). Future paths suggested included: mmusic, a new WG, more work required for it to be ready, or a BoF (in chat) to vet the idea further. * The “large file in email” problem: recommend new WG, charter to dispatch list for discussion ## ART AREA Meeting ---------------- ### BoFs, updates and meetings of interest - ADs (10 min) ### FFV1 v4 - new codec spec from CELLAR WG (5 min) Presenter: Michael Richardson [FFV1-v4 Github](https://github.com/FFmpeg/FFV1/blob/master/ffv1-v4-goals.md) [Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-cellar-wg-overview/) ### IPv6 Zone Identifiers in URIs (RFC6874bis) (10 min) Presenter: Brian Carpenter [draft-carpenter-6man-rfc6874bis](https://datatracker.ietf.org/doc/draft-carpenter-6man-rfc6874bis/) [Messages](https://mailarchive.ietf.org/arch/msg/ipv6/i5LUQN9vU9MryNWtvS_M_O7Wgjc/) [Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-ipv6-zone-identifiers-in-uris-rfc6874bis/) Larry Masinter: Would start the discussion in the browser world. ### Reliable (unreliable) streaming protocol (10 mins) Presenter: Kirill Pugin [draft-kpugin-rush](https://datatracker.ietf.org/doc/draft-kpugin-rush/) [Messages](https://mailarchive.ietf.org/arch/msg/avt/F-dp-TQrKxDjAanl1_gaRhNWGuM/) [Slides](https://datatracker.ietf.org/doc/slides-111-dispatch-rush-reliable-unreliable-streaming-protocol/) Juliusz Choboczek: Everything going out on same channel and encrypted, right? How can router distinguish different flows? Kirill Pugin: It doesn't. ### AOB