# Summary of Decisions and Next Steps ## Web Package * Discuss on art@ietf.org email list. * Focus on requirements use cases and how to split up work. ## DNS over HTTP The Art ADs will talk to Int and Sec ADs about relation to dprive. Don't have an answer now. Many people willing to do work on this and significant interest in doing it. -------------------------------- # Raw Notes #1 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: 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. ------------------------------- # Raw Notes #2 09:30 Administrivia - Chairs (5 min) Agenda bashing; blue sheets; jabber scribe; note taker 09:35 Updates from Area Directors - ADs (5 min) APPSAWG is finally closed 09:40 Web Packaging - Jeffrey Yasskin (30 min) https://github.com/WICG/webpackage Mark Nottingham: W3C has thought about this and worked on it, can see work at IETF. Suggest breaking up into components. We do a format for http req/resp pairs, way to assert that pair(s) came from an authority. Browser behavior is not us. Could do it in httpbis. Don't make it protocol neutral. Phil H-B: Is there a spec for mhtml? There should be. Jeff: no. Martin Thompson: not a bad packaging, how it work with server push. Signing is hard, perhaps too hard. ekr: risk if packaged and stored for a long time Dan Gillmor: question about package ecosystem management, long history of this and the dependencies are always wrong Mcmanus: parts are OK for httpbis Alexey: need more fleshed out proposal before dispatching Mark Nottingham: too early to charter now, need to talk to W3C Andrew Sullivan: sounds like it needs a BOF Thompson: more clarity on requirements, framing as packaging is problematic DKG: signature without knowing what needs to be signed would be bad Ben Schwartz: relevant to me, serve people cut off from standard Internet PHoffman: concerns about signed packages, resources go dead, signature can be misinterpreted ekr: better to start with use case, then decide what addresses what fluffy: hands to show interest? Some. Discuss it on ART. 10:10 DNS Over HTTPS - Paul Hoffman (40 min) draft-hoffman-dispatch-dns-over-https Magnus: how do you pick a resolver? Privacy issues in who sees your queries. McManus: out of scope, same issue as picking a DNS server now Mark Nottingham: generally support. Can peers agree to downgrade to http 1.x Tale: need to look at use cases Ted Hardie: why isn't this in dprive? What does this solve that dprive doesn't? Paul H: this isn't just about privacy Ted: this is a new substrate that provides privacy, which is like dprive Keith Moore: can o' worms, could fork DNS Yoav: why is H2 more resilient? Paul: can't see what's in a session, can't tell DNS from other traffic Yoav: consider allowing http 1 DKG: support for privacy properties, prune non-mandatory formats ekr: too bad this wasn't earlier and part of dprive Bron G: use case: Thunderbird which doesn't have cross-platform DNS, wire format is a lot harder than JSON Ben Schwartz: there are at least two incompatible versions of this now, needs standardization ?: idea that javascript can do this without browser knowledge? Paul: yup. Alexey: ART and SEC will be talking about this Show of hands, lots of them. ARTAREA Session 10:50 BoF Summaries - various artists (5 min) 10:55 New Working Group Summaries -various artists (5 min) dcrup exists 11:00 Using URIs With Multiple Transport Stacks - Dave Thaler (15 min) draft-thaler-appsawg-multi-transport-uris Carsten: why coap doesn't have transport Dave: doc is currently just a collection of what people do now PHB: would like to solve the discovery problem once and for all K Moore: it's 1993 again, this is the URN problem, each new layer of indirection breaks stuff Klensin: 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 Nottingham: documenting these tradeoffs is important, part of larger problem about how to identify protocols Alexey: could we do this within DISPATCH? Chairs: no. Barry Leiba: is this informational or do we want an answer? Dave: split info from answer PHB: mapping out the swamp precedes draining the swamp Barry: OK so long as mapping doesn't wear us out 11:15 Hybrid Video Content - Roni Even (10 min) draft-huang-dispatch-hybrid-video-delivery Chairs: is there interest? Some. Magnus: several different questions here Keith: might be a role beyond MPEG Chairs: discuss on ART 11:25 Open Microphone/AOB Volcker Berg: Pretty Easy Privacy doing opportunistic encryption of jabber, try it maybe you'll like it. Stack to synchronize keys and trust Chairs: write a draft Matt Miller: look at XMPP standards foundation