[dispatch] DISPATCH Minutes

[Ben Campbell <[e-mail]>]

Hello Everyone:

The preliminary minutes for DISPATCH at IETF 104 are available at the following link, and also copied below for your convenience. Please send comments and corrections to the dispatch list and copy the chairs directly.

Many thanks to Jean and Pete for taking notes!

https://datatracker.ietf.org/meeting/104/materials/minutes-104-dispatch-00 <https://datatracker.ietf.org/meeting/104/materials/minutes-104-dispatch-00>


Thanks!

Ben.

——————————————

# DISPATCH Minutes - IETF 104: Monday, 25 March, 2019 Prague

Chairs: Mary Barnes, Ben Campbell.

The chairs would like to thank our note takers for
their excellent notes: Jean Mahoney, Pete Resnick

See DISPATCH wiki for additional links to materials:
https://trac.ietf.org/trac/dispatch/wiki

# Summary:

DISPATCH Meeting
------------------

### Status and agenda bash - Chairs (10 min)

The chairs thanked the outgoing chairs (Cullen and Murray) and welcomed
the incoming chair (Ben). Mary presented a token of appreciation to the
outgoing ART AD (Ben) The order of discussions was changed to accomodate
a travel delay by one of the presenters.


### Relay User Machine (RUM) - Brian Rosen

(Presented last due to Brian's travel delay)

Brian provided an overview of the proposed RUM charter and
draft-rosen-rue-00.

RUM was not dispatched, since a working group charter is already in
external review and expected to be approved soon. A side meeting was
also planned for later in the week.

### JSON Contact - Bron Gondwana and Robert Stepanek(remote)

Robert presented a summary of draft-stepanek-jscontact.

There was discussion about whether this work should go into a new,
focused WG vs CALEXT. 4 or 5 people indicated that they were likely to
implement it.

The work needs some refinement and more discussion prior to making a
dispatch recommendation. DISPATCH may look at this again in the future.
List discussion was encouraged. The chairs noted that this need not wait
for IETF 105 for further discussion.

### Web Packaging - Jeffrey Yasskin (20 min)

Jeffery presented draft-yasskin-dispatch-web-packaging and discussed
changes since previous discussion of the concept.

The work needs feedback from deployments. The IAB is organizing the
ESCAPE workshop to get feedback from publishers. There will be a side
meeting on Wednesday. It is likely that part of the work should be in
the W3C.

The room agreed that it would be appropriate to plan a BoF. We need to
focus first on selecting the right use cases. Direct engagement from
implementers will be important for success.

### Other Business

Aaron Falk mentioned the proposal for BRAID at HotRFC as a potentially
dispatchable proposal.


ART AREA Meeting
 -------------------

# JSON Canonicalization Scheme (JCS) - Anders Rundgren (20)

Anders presented draft-rundgren-json-canonicalization-scheme and
received feedback. The draft was also expected to be discussed in
SECDISPATCH.

We need to better understand the use cases. There are both security and
application aspects.

# Raw Notes from Jean Mahoney

Dispatch - IETF 104

Monday morning session I Congress Hall 3

Chairs: Ben Campbell, Mary Barnes

Note takers: Pete Resnick, Jean Mahoney Jabber scribe: Matt Miller

DISPATCH wiki: https://trac.ietf.org/trac/dispatch/wiki

----------------------------------------------------------
Status and agenda bash Presenters: Mary, Ben
slides:
https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch-
chairs-agenda-and-status-02

The schedule of presentations changed due to travel delays experienced
by a presenter.

Mary Barnes thanked Cullen Jennings and Murray Kucherawy for their work
as DISPATCH co-chairs, and welcomed Ben Campbell as the new co-chair.
Mary presented Ben with a token of appreciation for his work as ART AD
(a bottle of Czech rum), and let him know that another gift would be
shipped to his home address.

----------------------------------------------------------
Web Packaging
Presenter: Jeffrey Yasskin Discussion:
https://mailarchive.ietf.org/arch/msg/dispatch/
e6ZSh7ocW6n2afnbwGzBlX1WT8Y slides:
https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch-
web-packaging-01

Jeffrey said that he needed feedback from deployments. Mark Nottingham
and the IAB are organizing the ESCAPE workshop to get feedback from
publishers. There will be a side meeting on Wednesday. He thought that
part of the work should be in the W3C, and part in HTTPWG.

Eric Rescorla suggested a bof be held and that the bof should discuss
use cases. Eric pointed out that the answer to the given use cases may
not be the solution that Jeffery is proposing, and didn't think that all
use cases given were equally important.

Wendy Seltzer said that the W3C is interested in the use cases and want
to be part of the discussion. There were distances between use cases and
solutions.

Mark Nottingham thought that a bof was needed. He wondered if Jeffery
would be willing to accept consensus if the IETF community determined
that the solution to the use cases wasn't the one that Jeffrey was
proposing.

Jeffrey thought that he could.

Cullen asked what Jeffrey expected from the IETF.

Jeffery said he needed the security expertise in HTTPS, TLS and that the
IETF would define the format while the W3C would define the algorithms
for loading.

Ted Hardy agreed that a bof was the next step, but wondered if it was a
task for the bof to determine the split of work, or would that be
decided before the bof, and suggested that the Wednesday side meeting be
used to discuss that. Ted was interested in the anti-censorship use
case.

Martin Thomson wanted to know who would implement it, and said that the
implementers needed to show up at the IETF.

Dan York agreed that a bof was needed, but said that we needed to know
that the solution would be used.

Eric Rescorla emphasized that if the implementors don't participate,
there's no point in pursuing it.

Cullen Jennings said that if a group of people want to change the
architecture fundamentally but don't show up, they won't be taken
seriously.

Jeffrey thought he could get the implementers to participate remotely.

Ben Campbell, as chair stated for the minutes: A bof is a good idea,
need to focus on right use cases first, the people who are going to
implement it need to be engaged in the process.


----------------------------------------------------------
JSON Contact

Presenter: Robert Stepanek (remote), Bron Gondwana Discussion:
https://mailarchive.ietf.org/arch/msg/dispatch/
IEwBrtBUZfAsD_usDt40HDBBTB0 Draft: draft-stepanek-jscontact slides:
https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch-
json-contact-00

Daniel Migault, as CALEXT co-chair, was in favor of bringing the working
into the CALEXT working group.

Cullen argued for a new, focused working group since CALEXT didn't do
messaging.

Barry Leiba sided with Cullen on a new, focused WG. He pointed out that
vCard versions get ossified, with new implementations using new version
of vCards, while older implementations stay with older versions. He
suggested keep as much mapping as possible so it can be ported.

Robert Stepanek said that they would reuse as much as possible but
couldn't guarantee 100% compatibility.

Jim Fenton asked if Robert had a feel for how well this would be
adopted.

Robert said they were early in the process and that it was experimental.

Chris Newman felt that it created an opportunity to get address books
integrated more effectively with other protocols.

Alexey Melnikov, as AD, said that he heard some interest, but it was not
clear whether it will go CALEXT, JMAP or a new working group.

Ben Campbell asked for a show of hands if anyone was interested in
implementing it. Four or five people raised their hands.

Jon Peterson said there was already a draft on how to do vCard with
JSON. He might implement this if it were better, but the draft was at
too early a stage to tell.

Mary Barnes, as chair, said that more work needed to go into this for
people to discuss.

Alexey, as AD, said that an updated draft and more discussion was
needed, then it could be re-dispatched.

Ben Campbell, as chair, pointed out it could be discussed on list and
the WG didn't have to wait until Montreal to dispatch.


----------------------------------------------------------
JSONCanonicalization Scheme (JCS) Presenter: Anders Rundgren
Document: draft-rundgren-json-canonicalization-scheme

Richard Barnes pointed out that this topic was on the agenda of
secdispatch, and the actual dispatch would be done there.

Carsten Bormann wanted to know what the use case was and commented that
it was a deterministic mapping ..., and that JSON has refused to define
the data model. This would define _a_ data model, but not _the_ JSON
data model. Carsten had issues with mapping specifics that he didn't
need to cover at the mic. He didn't like the idea of embedded
signatures. He thought a mapping to JSON ... was a good thing to have.

Anders said that comparing output data was out of scope ...

Matt Miller thought it was probably ok for what it was defining, but
needed a better understanding of use cases.

Eric Rescorla said that when JOSE was designed, canonicalization had
been eschewed because previous attempts had been debacles and that
wrapping was better, with sharp containment between wrapper and what was
being signed... and wondered what was wrong with what we have?

Anders said that it works, but is not readable.

Eric said that it's  readable, just not legible.

Jeffrey said ... and agreed with Carsten.

Carsten pointed out that the ...64 problem comes up in other
environments, and that CBOR covers this. Deterministic serialization ...

Martin Thomson ... and that a warning should be added.

Cullen said that the point of JSON is to be human readable, and mistakes
were made with STIR token signatures.

Pete Resnick pointed out that encode the whole thing is inconvenient,
because you can't manipulate the internal bits. There were advantages to
..., but that a security person would say not to do that.

Mary cut the discussion due to lack of remaining time and that it would
also be discussed in secdispatch.

----------------------------------------------------------
Relay User Machine (RUM)
Presenter: Brian Rosen Charter
proposal: https://mailarchive.ietf.org/arch/msg/dispatch/DulYa-
smNK96RXGos_x_lEjeUw8
slides: https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch-
relay-user-machine-rum-00

Ben pointed out that the working group would be formed within the next
few weeks, and that the charter is in external review.

Paul Kyzivat, participating remotely, wondered if Meetecho would be
available for the Wednesday meeting.

Brian Rosen said that side meetings don't have Meetecho support and he
didn't like it.

Paul pointed out that it was more than just a SIP profile.

Brian agreed and how much to include would be up to the WG.

Aaron Falk wondered if it could cover any language translator use case?

Brian thought it could work, and the charter could be modified if people
were interested.

Martin Thomson asked what thinking had gone into the security issues
surrounding the man-in-the-middle use cases.

Brian agreed that it needed more scrutiny.

Jonathan Lennox said ...

Brian said that they would fix it, and also would talk to Chris Wendt
and Jon Peterson.

Brian said that they'll ask the working group to adopt
draft-rosen-rue-00, but the WG does't have to do that.

# Raw Notes from Pete Resnick

DISPATCH WG / ART Area Meeting. IETF 104 Mary Barnes and Ben Campbell
chairing Pete Resnick taking minutes.

https://datatracker.ietf.org/group/dispatch/meetings/
https://datatracker.ietf.org/meeting/104/session/dispatch

Chairs rewiew Note Well, Agenda.

Deadlines reviewed.

A review of distinction of ART and DISPATCH lists, BOFs and other
meetings this week, and new WGs.

Thanks to previous co-chairs, and intro of new co-chair.

Web Packaging:

https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch-
web-packaging-01.pdf

WPACK is having a meeting on Wed (unfortunately against DOH).

Comments: Eric Rescorla: This is a pretty big architectural change. A
BOF should probably review use cases, not just jump into the protocol
discussion of this proposal. Wendy Seltzer: W3C also has concerns about
connection between use cases and solutions. Mark Nottingham: We need a
BOF to actually have a discussion. Heard from several folks that use
cases might not lead to web packaging. Are you still on board if the
solution doesn't look like WPACK? Jeffrey: Yes, so long as we can get
AMP to switch over to whatever we produce. Cullen Jennings: What's the
interaction between IETF, W3C, and WHATWG? What's IETF's rule. Jeffrey:
Security issues are the most important bit that IETF brings to table.
IETF defines format; W3C defines algorithms to load it. W3C vs. WHATWG
will be dealt with by them. Ted Hardie: BOF as next step makes sense.
Should we figure out split before or after BOF? Side meeting should
think about that. Anti-censorship use case is most interesting. Some
folks would want this if it's available in common applications; don't
want to identify folks who want anti-censorship, as that flags people
who don't want flagging. Martin Thomson: BOF should definitely involve
people who are going to implement this, and make sure they participate.
That includes the AMP team, though other folks too (e.g., Apple News,
etc.). Should reach out to them and get them to at least join the list.
Dan York: Need BOF so that we can get use cases resolved. As web
publisher, I have particular things in mind. Eric Rescorla: Getting AMP
committed to this work is essential. If AMP isn't going to participate,
no need to bother. Cullen Jennings: If a group who is going to change a
fundemental architecture won't show up, that's not going to go over
well. They really should show up in person. Eric Burger: Do we really
want in-person to be a requirement? Cullen: Yes. Chair summary: We think
a BOF is a good idea. Focus on right use cases. Implementers and users
must be engaged in process.

JSContact:

https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch-
json-contact-00

Comments: Daniel Migault: Merging the assorted WGs who deal with this
sort of thing would be good. Perhaps calext is the right place. Cullen
Jennings: Given that this also interacts in the collaboration/messaging
folks, a small focused WG might be better. Barry Leiba: Lean toward
Cullen's proposal. If we use existing, JMAP seems better. Also: VCARD
versions tend to get occified, so try to keep as much mapping as
possible so that you can port to older versions. Jim Fenton: VCARD isn't
loved, but it would be hard to get people to change to this. Do you have
some sense that this would be adopted? Robert Stepanek: It is an
experiment at this stage. Barry Leiba: New implementations tend to
implement new versions of VCARD. We may get new implementations will use
this, but older implementations will not. Chris Newman: This has
potential to deploy because the change in network API model has changed
to the JSON model, meaning this might stick. Support this work. Alexey
Melnikov summary: Some interest, not clear whether this goes to CALEXT,
JMAP, or new WG. Still not clear how much implementation interest there
is. Should discover that on the list. Chair query: Are there
implementers in here? 4-5 people raise hands. Jon Peterson: We're
shopping for a way to do VCARD in JSON. If this is better than the
current standard, then we'd probably use it. Chair summary: Worth
putting in more work for this and discussing on the list, and perhaps
re-dispatch if needed.

Aaron Falk: Proposal at HotRFC for BRAID. Might be worth discussing as a
dispatchable proposal.

JSON Canonicalization Scheme:

https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch-
json-canonicalization-scheme-jcs-00

Comments: Richard Barnes: Also on the agenda for SECDISPATCH, and will
likely be dispatched there. Carsten Borman: One problem is that the JSON
creator won't define the data model. We did that part way with I-JSON.
We need to define the data model (and that would be a good thing). Some
particular things that I don't like in the proposal, but that can be
discussed later. Finally: What is the use case? This could be used for
comparing output data. Even though the embedded data model for strings
is out of scope, applications could take that on with specific standards
for them. Overall, this is a good thing to have, and I have at least one
use case. I don't like embedded signatures, but we can discuss that in
SECDISPATCH. We should discuss this in a wider context than just
signatures. Matthew Miller: It would be nice to figure out the cases.
The simple JSON data types only get you so far. This might be a starting
point, but we must be careful. Eric Rescorla: When we defined JOSE, we
explicitly eschewed canonicalization. This (for better or worse)
backtracks on that decision. Legibility seems to be the issue. Why is
wrapping a bad thing? Readability. Jeffrey Raskin: Agree with Carsten
that a deterministic serialization is useful. Carsten Borman: The BASE64
problem comes up in other environments (cf: CBOR). Eric Rescorla: Let's
be clear on whether this is for security purposes or some other
purposes. Carsten Borman: Not only a JSON issue, but an application
issue. Somebody has to take care of deterministic encoding. This is a
superset of the current proposal. Martin Thomson: If we define a
canonicalization without being designed for security, it's still going
to be used for security. Cullen Jennings: The point of JSON is to put it
in human readable form, and this does that. We have made this mistake
before. Eric Rescorla: We don't want applications to avoid the security
stuff, so having a bucket of bits can be a good thing. Pete Resnick: But
that is a tradeoff, because applications also want to examine certain
parts before handed to security protocols. Chair summary: This will be
dispatched by SECDISPATCH, but there may be application interactions
that need to be acconted for.

Relay User Machine:

https://datatracker.ietf.org/meeting/104/materials/slides-104-dispatch-
relay-user-machine-rum-00

Chair comment: This is already in the WG-forming process

There is a Wednesday side meeting, but no Meetecho support.

Comments: Paul Kyzivat: This seems beyond a SIP profile, given the
provisioning stuff. The SIP SDP media piece is really the imporant
stuff. Aaron Falk: Is this specific to sign-language translation, or
could you put (e.g.) a language translation mecahism in the same slot?
How specific is this? Brian: It should just work. We could put this in
the charter. Martin Thomson: Suggest that "M" stands for
man-in-the-middle. Perhaps that issue should be considered. Need to have
mechanism to assure you're talking to the right endpoint, and someone
gets to choose the MITM. (Current default is the originator who
chooses.) Perhaps this should be in the charter. Jonathan Lennox: Want
to also assure that the translation service is authenticated. Cullen
Jennings: Need to limit security mechanisms to what will reasonably
deploy. Eric Burger: 90% of the "am I talking with who I think I am
talking with" is already in SIP. Brian: Still might need to authenticate
original caller.