Subject: [dispatch] IETF 99 DISPATCH meeting notes - raw

From: "A. Jean Mahoney" <[email-masked]>
Date: Mon, 17 Jul 2017 17:13:41 +0200

Hi all,

Below are my raw notes from the meeting this morning. Things I missed I 
marked with ...

Thanks!

Jean

---------------------------------------------------------------------

DISPATCH WG Session

IETF 99 — Prague, Czech Republic
July 17, 2017  09:30-11:30, Congress III

---------------------------------------------------------------------
09:30 Administrivia - Chairs (5 min)
       Agenda bashing; blue sheets; jabber scribe; note taker
 
https://www.ietf.org/proceedings/99/slides/slides-99-dispatch-chair-slide-deck-00.pdf

Mary Barnes presented chair slides.

slide 1: Title

slide 2: Administrivia

Note takers: John Levine, Jean Mahoney

Jabber scribe: Rich Salz

slide 3: NOTE WELL

This is the old NOTE WELL slide

slide 4: NOTE WELL, in other words

slide 5: Deadlines for IETF 100

Mary: Charter proposals don't have to be formal - need a problem 
statement - what problem do you want to solve?

slide 6: Working With Deadlines

slide 7: A Reminder about Mailing Lists

09:35 Updates from Area Directors - ADs (5 min)

slide 8: Updates from Area Directors

Ben Campbell: The CELLAR meeting is happening this IETF. It's like a 
solar eclipse, it's a once in a lifetime occurrence.

Murray Kucherawy: appsawg is closed.

---------------------------------------------------------------------
09:40 Web Packaging - Jeffrey Yasskin (30 min)
 
https://www.ietf.org/proceedings/99/slides/slides-99-dispatch-web-packaging-00.pdf
       https://github.com/WICG/webpackage

Jeffrey Yasskin presented.

Mark Nottingham: First I thought - just do it in the w3c, but after some 
thinking, some work can be done here. Some history - W3C TAG has a doc 
that covered this but died. It's not the first time this has been 
proposed. I can see a place for this work in the IETF. Split this into 
components. A format to persist HTTP requests/responses. Need to assert 
that a request/response pair is from an authority. Then there's the glue 
that ties that to your work cases. The first two components are protocol 
- could do that here. the gluey stuff can be done in W3C. First two 
items can go to the ...

Cullen Jennings: By gluey stuff, do you mean signatures?

Mark: No, that's #2. We're talking about it in HTTPBIS right now. ...

Cullen: What should be done here?

Mark: we can ... We can assert that request/response pair came from an 
authority. But how browsers can support those - that's out of scope for us.

Murray: This is all in HTTP? or other WG?

Mark: My kind co-chair pointed out that ... There are pit falls around 
use cases. This is HTTP.

Murray: you would recharter?

Mark: Sure we can do it. We don't recharter much. We just determine 
whether we want to work on new drafts. Don't know if that surprised our 
AD or not. Making this protocol neutral would be a mistake.

Phillip Hallam-Baker (PHB): Is there a proper specification for MHTML?

Jeffrey: No.

PHB: You need to fix that. I don't think this should go into HTTP. We're 
already doing two sessions here. Packaging is separate. I'm working on 
something related: think about having everything encrypted and stays 
encrypted. I'm doing this. I'm not using the encryption you know. We can 
talk offline.

Jeffrey: The first two cases don't work with encryption.

PHB: I've got it running.

Magnus Westerlund: Have you read out-of-band encoding? It's solving the 
same.

Martin Thomson: This has been pitched umpteen times. This isn't about 
packaging. It's about the 2 use cases that Mark mentions. Having to 
guess what someone might ask for and when - is a challenge. Lot of 
debate about push and getting it to work. In a narrow context maybe. 
Another ... we've tilted at the signatures windmill. I don't have the 
stomach for it anymore. If we can work out the preservation problem ... 
maybe.

Eric Rescorla (ekr): It was a hack in PUSH. Request and response are 
milliseconds apart. Passivation - here's like the request that ... 
that's an odd structure for what's basically a zip file. It makes sense 
in push. You have very preprocessed data. Treating it like a stored http 
session. I don't know why that's an attractive solution. Security - the 
http credentials are there for you to sign for the long term. If you 
allow the https signature to span weeks, it creates weaknesses.

Daniel K Gillmor (DKG): The idea that you are shipping web-based apps. 
There's a long history with linux distributions, ... they still get it 
wrong with dependencies. You mentioned downgrade attacks.

Jeffrey: It's not designed fully.

Daniel: And this is not designed fully in Debian, and it's not designed 
fully for other distributions, etc., and they are centralized. You are 
talking distributed. Look at folks who have prior art. Language-based 
package distribution. Linux distribution systems 10 years ago.

Patrick McManus: IETF is not the right venue for this ...

Murray: Alexey, what are you thoughts?

Alexey: If this goes to HTTPBIS, I will have some say. We need more 
fleshed out proposal to what the work looks like. I don't want to answer 
yet. Could go to an existing WG, and WGs to be created. Are people 
interested?

Cullen: OK, one or more working groups. Let's hear people at the mic and 
then take a hum.

Mark: I don't think we should bring into HTTP now. Need more careful 
description of use cases and breaking down how to solve the use cases. 
Won't talk at HTTP this week. Love to talk about this. We should also 
talk to W3C before we take it on.

Martin: Mark has captured my thoughts - I want clarity in requirements. 
We have a big ball of wax and a big ball wax to address it. Framing as 
packaging is problematic.

DKG: I wanted to clarify my thoughts - if you define signature formats 
without understanding what needs to be signed, or not signed - you build 
a dangerous thing.

Jeffrey: ... defines a packaged ...

Murray: You can discuss on the art mailing list first.

Ben Schwartz: This is relevant to my needs and applications, it serves 
people ...

Paul Hoffman: People misinterpret signed packages. It sounds like you 
are mimicking ... If you had given the query at this time, you would 
have gotten this - and froze it. If you close and open the browser hours 
later - some things would have changed and maybe died. If the signature 
says to you ... For the hum - ask, if you saw one of these things, would 
you be able to use it. I can use it if it was unsigned. Signing will be 
easy to misinterpret.

ekr: Just start with use case and requirements doc. Chop the bottom of 
the doc off.

Cullen: The feedback I'm hearing - There's work to be done, but not 
start working group today. The question we have - we'll discuss on the 
work list. Who will work on this? (about 10 hands). Alexey?

Cullen - anyone have problems with discussion on the mailing list? And 
if there's lots of discussion, we'll move it to a separate mailing list.

Rich Salz: People in the Jabber room are saying have a bof.

Cullen: That's an option or dispatch. When we look at it, it will become 
obvious.

---------------------------------------------------------------------
10:10 DNS Over HTTPS - Paul Hoffman (40 min)
 
https://www.ietf.org/proceedings/99/slides/slides-99-dispatch-dns-over-https-00.pdf
       draft-hoffman-dispatch-dns-over-https

Magnus: how do you control the resolver?

Patrick: the bootstrapping of finding the DNS server?

Magnus: is it the site ...

Patrick: one use case - instead of a stub. Bootstrap through an OS. ... 
It applies in the browser context. Could be an application-specific 
configuration. Discovery problems are out of scope for this.

Magnus: the privacy aspects of this mechanism, who has control of which 
HTTP server responds and where it gets cached.

Patrick: The clients have this problem right now. This work doesn't sort 
out which DNS server is used. To use data from this mechanism will 
require further work in HTTP. This is how to carry DNS info in HTTP. 
That's the extent of it.

Magnus: I'm worried about punting on the use of this and the privacy 
considerations.

Paul: it's no different from what it is going now.

Patrick: it's an improvement for privacy.

Mark: I think it's good, and well scoped and it's good to punt on the 
use right now. I have feedback.

Patrick: Feedback on http on this would be good.

Mark: there's discussion on jabber on why h2 and not legacy. I think 
it's good to specify a version, be careful with language, though, http1 
is still in use, it's not legacy.

Patrick: ...

Mark: what if peers downgrade to http1? That may happen.

Dave Lawrence: I agree with Mark on this is good and I like what is 
going so far. I don't agree on punting on the use cases. DNS 
encapsulation format will be tempting for browser vendors for pushing 
more DNS data down the pipe. Needs to be clarified. What are we doing 
via ...

Paul: do you want to see more in this draft?

Dave: Acknowledge the issue. It's a competing idea. The issue needs to 
be identified and implications.

Ted Hardie: If you find your DNS server by an existing server and treat 
it as recursive. Why doesn't it fold into dprive? When you blend with 
http services, it becomes a dprive mechanism that doesn't use dprive. 
What doesn't work in dprive and why?

Paul: this isn't simply about privacy, which is the goal of dprive. It 
would require rechartering dprive.

Ted: you are creating a new substrate for the DNS protocol that provides 
privacy.

Keith Moore: this seems like a can of worms. My concern is that it forks 
DNS. A special set of DNS servers intended for web applications. You are 
providing a web specific interface to DNS. Doesn't have to be used like 
that. DNS is already polluted enough as it is. Interception proxies, 
servers that only serve parts of domains. I don't want to see another fork.

Patrick: web apps are near and dear to my heart - my hope that OS 
libraries will do this. But you get better mixing with http traffic, 
which has strong properties, better privacy properties.

Paul: this is not intended to do the split you are worried about it. 
Could be same server with the same data. It would be easy to add for 
another transport.

Keith: I'm worried about unintended consequences.

 From the jabber room: John Klensin
MIC: I'm trying to figure out what it would mean to use content 
negotiation to select variants (as one of the slides indicated) given 
that the DNS does not support a "give me all the aliases for this name" 
function (much less their properties).  The draft talks about 
alternatives, but doesn't seem to say.  Could you talk a bit more about 
that?

Paul: content negotiation is not for different names, its for the format 
- wire format or JSON. If it's not clear in the draft it should be, he's 
right you don't get to say.

Yoav Nir: ... why is that?

Paul: with regular DNS - can see the DNS traffic and block it. With 
dprive, you can tell it's a DNS session, and block it. With this you can't.

Nir: trying to get past evil firewall.

Paul: not the only use case, but yes.

Nir: the same firewalls will negotiate client servers down to http1. If 
this draft won't accept http1 -

Patrick: We can talk about it in the draft.

Nir: When is post used?

Patrick: ... enables media negotiation in a better way. The other has 
better caching properties. In scope for discussion and building 
consensus ...

John Klensin: MIC: Thanks.  And, yes the draft says "alternative" but 
the slide said "variants" and that term has taken on a special meaning 
where the DNS is concerned. "alternatives", but the slide said 
"variants" which has taken on a special meaning WRT the DNS.

DKG: I support this work. Having something like Doe(?) would be useful. 
I'm concerned about content negotiations. You can't validate DNSSEC over 
JSON, only over wire format.

Paul: if someone wanted to create a smaller and different format they 
can. Mandatory to implement will be wire format.

DKG: ... useful simplification to get this out the door. The non-UDP 
wire format doesn't have a way to handle DNSSEC signatures. I'm glad 
that discovery is not in this. I'm not sure about arbitrary end points. 
... .wellknown. I appreciate http2.

ekr: I'm sad that we're talking about this as we are finishing dprive. 
It's a superset of dprive. Want to push on mixture on DNS and http. 
Maybe with google you can get this.

Patrick: any widespread CDN

ekr: because Akamai serves Facebook ... ?

Paul: ... your connection in the coffee shop.

ekr: the coffee shop controls my IP address, not the Akamai servers. 
What actual settings does this happen in?

Paul: we don't have it now, but could with CDNs.

Patrick:  ... more than a tunnel.

ekr: I'm not sure this is a good way of hiding the traffic. You're lying 
that you doing DNS.

Paul: I'm using 443.

ekr: the enforcer ...

Paul: if you are on 443, you may be pushing more than pictures of cats, 
you may be doing something else.

Jonathan Lennox: <some question about ports>

ekr: want to see use case descriptions for dprive ++ and ... They have 
different security requirements. ... pushing the resolver into the 
browser. back to the hypothetical.

Bron Gondwana: Thunderbird doesn't do DNS lookups. 2nd point ... 3rd 
point - wire format will be more difficult to do, unlike JSON. Having a 
format that's easier to implement would be good.

Ben Schwartz - there are 2 - open resolve, dns.google.com, an argument 
for standardization.

Jonathan: Can a java script implementation can do this without the 
browser knowing?

Paul: yes.

Murray: want to talk about next steps.

Cullen: we're struggling here - how much this relates to dprive and how 
much in new wg, or not doing it. AD?

Alexey: Art ADs will talk to Int and Sec ADs about dprive. Don't have an 
answer now. It's clear there is some interest. Need to find a place for it.

Cullen: show of hands willing to read drafts and do work. Wow - tons.

---------------------------------------------------------------------
---------------------------------------------------------------------

ARTAREA Session

---------------------------------------------------------------------
10:50 BoF Summaries - various artists (5 min)

Murray: didn't get replies from bof chairs. Anyone want to talk about 
these? (No one volunteered)

BANANA - BANdwidth Aggregation for interNet Access (int)
IDEAS - IDentity Enabled Networks (rtg)
IASA20 - IASA 2.0 (gen)
NETSLICING - Network slicing (ops)

---------------------------------------------------------------------
10:55 New Working Group Summaries -various artists (5 min)

DCRUP - DKIM crypto update

Murray: upgrading size of keys and how to move them. May only meet once 
or twice it its lifetime. Meets Thursday.

Rich (?): we've shifted the meeting time and it shares a time with 
DMARC, it will now start at 10:30

---------------------------------------------------------------------
11:00 Using URIs With Multiple Transport Stacks - Dave Thaler (15 min)
       draft-thaler-appsawg-multi-transport-uris

Jonathan: maybe SIP is an anti-pattern, transport=tcp.

Dave: the argument for the anti-pattern, the ... (info is for the 
server? the client has already made a transport choice.) point is talked 
about in the doc.

Carsten: why need them for the protocol that runs over CORE, it sees 
something like transport in the URI, it confuses them.

Dave: The point of the doc is not to make recommendations, just document 
ways to solve it and document the tradeoffs.

PHB: we have a doc that describes how to use SRV records for discovery. 
I like the idea of taking all the cruft and explaining it. Every wg has 
a discussion on discovery. I'd like to come to an agreement on how to do 
it. When I define a web service, I get my name, my URI, my ... prefix. 
... I don't want a URI that has the same name. I want one solution for 
discovery.

Dave: challenge on finding one solution.

Keith: I feel like I've gone back to 1993. This is the URN problem 
again. The result, sad to say, was to create a huge mess. I want to 
believe it's over with, but it's not. I don't want to discourage you. 
There's something dangerous here or elusive about the problem space. 
Everyone looks at the layer of indirection and then projects ideas of 
what they want on it. Hard to create anything coherent. When you define 
an identifier scheme, and then later you try to change what it means. 
For example, IPv4 addresses - Class A, B or C, and remaining bits. And 
we had to change classes, and now we have NATs. Adding Layers of 
indirection break things. URNs let you tell the difference between 
schemes, how do you keep people from inserting layers of indirection?

John Klensin MIC: Dave, seems to me that halfway to your 4th approach is 
to focus on identification the resource and go with URNs, allowing the 
protocol to be sorted out as part of the resolution mechanism..  but 
that is still a URI, not a different mechanism

Mark: it's appropriate to give this kind of advice. There are cases that 
are different. Different requirements from different protocols. 
Documenting these tradeoffs is important. I encourage you to look into 
this area. This is part of a larger problem, which is how to identify 
protocols.

Dave: there are 2 audiences - IETF, and the other for people who don't 
have permanent schemes.

Murray: This is an art area discussion, it's not being dispatched.

Alexey: Can it be done in dispatch? There's an exception for 
IANA-related things.

Chairs: no.

Mary: do you want to AD sponsor it?

Barry Leiba: Do we just want an informational doc, or do we want to come 
up with an answer with a BCP? I'm leaning toward BCP, and AD sponsoring 
it won't do it.

Dave: 2 efforts - updating requirements for permanent registration ...

Adam Roach: Get input from the art community on the art mailing list. 
Then we can circle back.

PHB: mapping the swamp is a good way to start to find the path.

---------------------------------------------------------------------
11:15 Hybrid Video Content - Roni Even (10 min)
       draft-huang-dispatch-hybrid-video-delivery

Cullen: of the people who build these systems, are they willing to 
switch systems to use a new IETF solution? Are there people who will 
participate? (3 people raised hands).

Magnus: this is too fluffy. It's a question of which of several 
different problems - how to invoke multicast from browsers? does the 
multicast transfer protocols have the right features? do the meta data 
in MPEG...?  It's easy to step over borders, and the people are in other 
fora.

Roni: we need to understand the generality, source to receiver. I don't 
think it's been discussed in IETF. We can start with more info on the 
structure. If there is no interest, no point of writing docs.

Keith: I started out thinking that this is an MPEG problem. There may be 
role for collaboration between MPEG and IETF. Best you can hope for is 
some sort of MPEG ... if the format is not amenable to slicing and 
dicing, not much you can do.

Roni: trying to see how to transfer in a better way. We see this problem 
in live video, MPEG doesn't address this issue. Need to provide the 
whole view.

Murray: we should encourage discussion on art list.

---------------------------------------------------------------------
11:25 Open Microphone/AOB
       (remaining time; TBD)
       Possible topics:
       - TBD

Volker Birk: We've implemented opportunistic encryption of chat messages 
and email. We are trying now to get what we are doing into an open 
standard. Maybe you want to have a look at what we're doing. We have a 
protocol stack that syncs keys and trust, and addresses and schedule. 
Internally in our database, peer-2-peer, always local. we are using URI 
schemes that are not standardized.  We have message formats that are not 
available in openPGP and SMIME. We have ... 
(https://www.ietf.org/mail-archive/web/saag/current/msg07789.html)

Murray: Submit drafts if you have any and then post to the art list.

Matthew Miller: You should contact the XMPP standards foundation.