Internet Engineering Task Force 97, 18 Nov 2016

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF97-DPRIVE-20161118-1150

Description

DPRIVE meeting session at IETF97
2016/11/18 1150

A

You can get enough stuff to get get back, so we're continuing hello I'm on gospel is any.

B

Of presentation on it, this meeting.

A

B

A

And priced at two.

C

D

Other profiles.

E

Are on the agenda? Okay,.

A

The related Rockies yep do those presentations yep and then our how we're going to use carries um frankly. I figured.

A

F

A

Great and glorious.

F

That not one this great, it's just a little sitting. There seems all right in front row. It's a sort of like it's like wait, did I wake up in da shop again I.

A

G

Two minutes to.

A

Check again, oh yes,.

B

I knows what they.

F

Don't know and.

A

F

A bunch of people like tsinghua I, don't know about this. Changing as I go. Okay, guys, you get it sort this out here.

G

A

We know on your mark, I am later on. We.

G

Didn't unlock them.

G

G

F

Know I just I think this whole are, you need to you know, keep it there to end up in sort of the key, politically yeah yeah, just waiting.

A

For me, wait anyway.

F

No, no I actually get super Snooper and yes and act.

B

Alrighty everyone we're gonna, be starting real soon now, so please find seats, sit down, shut up, pay attention, etc. Wow look I could be like all the thyroid if and stuff and I've got a microphone yeah and nobody.

H

H

Good to see you go.

F

You're done traveling the world I. Guess all.

B

Right sit down shut up still, nobody listens. Oh well,.

F

You run some viewers like that: okay.

F

B

Okay, so hetero everyone welcome to deprive um we got the short straw, and so it's Friday afternoon. So many of us I'll I it's Friday morning. Many of us are somewhat tired and loopy, but oh well, we'll see how this goes um next slide. So, as I said, welcome to deprive Tim Warren um dan York has nicely agreed to be the jabber scribe is Dan actually in the room dan. Thank you, sir. The jabber scribe gets priority. My mic access, so you know if there is a lie in the JavaScript, can cut in front.

B

Thank you. um Susanne says she will do minutes Thank You Suzanne, if you're using etherpad, please save it to somewhere else every now and then because etherpad has a tendency to eat notes every now, and then um next note well. Here is the note. Will please note it well, presumably, by now you've seen this many times. It says all sorts of important things, I'm not going to interpret them. This is between you and your lawyer, / rabbi, / priest, /, whatever. Please make sure that you understand what it means.

B

It's important blue sheets, the blue sheets are busy circulating somewhere. If you have not signed the blue sheets, yet please sign the blue sheets. Who has the blue sheets? Can you, okay, they're all the way towards the back of the room? Eventually they'll come forward. Please sign them. This is our agenda. It is nice and short. um Does anybody have any agenda bashing? Are you expecting to present and aren't listed or more worryingly, are you listed? And you don't know that you're presenting okay? Well there we go, then a quick status update.

B

These are the rfcs which we published so far. The deprived, dns / dtls document has been submitted to the iesg. It's on the december 15th tell a chat. Hopefully it goes well.

B

The deprived profiles document the working group last call for this ended october 21st. Unfortunately, we did not get enough feedback to actually call it. This will be presented today. So hopefully people will, you know, actually know what it says and will care, but please go off and actually read the document. Please provide feedback. There will be some more cajoling going on.

B

You know during /, after the presentation we have two related drafts, the padding profiles draft and the phase 2 or step to work, they'll be presented as well, and then we're going to have to you know, discuss what we're actually doing in phase 2 of deprived before we get into presentations our wondrous go. What's it wondrous great and a lustrous ad has something to say. um Hopefully we manage to embarrass him enough with that yeah.

F

I

Don't know who that ad is but you've got me instead, so on Sunday I, don't know whether you're aware there is a a Jew team session on DNS privacy, so I'm here to publicly thank Sarah Dickinson for freely giving her own time.

I

Thank you very much. Thank you very much Sarah. The efforts like this are really great for the IETF and, more importantly, really great for depriving getting the knowledge sharing out there and happening. Thank you and yeah that.

B

Was recorded so if people want to watch it, it's definitely worth watching. It also makes a really good thing if you want to sort of introduce others to the work that's going on here without spending all of your time talking, you know, Sarah spent her time talking so without further ado presentations up. First, we have the agenda TLS profiles. Sarah.

B

Would you like a tricky thing? Ooh have a clicky thing.

J

Right, thank you so yeah. This is a short update on the profiles draft. So this draft covers usage profiles for clients to authenticate servers, and it also discusses the mechanisms to do the authentication.

J

As Warren said, the working group must call started way back in october. Six of this there was a little bit of you during that time. Thank you to those people. It had to be extended because we didn't get enough review some others pitched in after that. Thank you to them. However, it's still sat in working group, that's cool, because the feeling is it would be. It still needs a bit more feedback to progress it for audience.

J

So the latest version is there seven version that went in just before the deadline. It does have a moderate restructure compared to the version that started working group last call and that's to clarify its position on how spk pinning is done and how it relates to the definition of that in the earlier DNS over TLS document.

J

There's a couple of issues that still hanging around on the mailing list: they're, not huge I'll, just touch on them here, they're, both just to do with drilling down right into the specifics of how we are going to define opportunistic encryption for DNS over TLS or dtls, and one of those questions. The draft currently says that clients using opportunistic privacy should try for the best case and may fall back, and the query was shouldn't that be a must: shouldn't you make clients go for the best option they can get.

J

The draft has the upper texting should and the question on the list was: why isn't that a must? The answer was the draft has written this way to leave clients some flexibility, because, for example, if they are configured with many upstream recursos, what that would force them to do is try every single one of them to get an authenticated connection before it could actually do dinner service.

J

And so, if we're going to don't go down a must root, we probably need to provide a little more advice about probing in parallel as opposing to its serial and taking the latency hit. So it would be really good to get feedback on which of these directions a working group would prefer.

J

The second question is that the way the draft is currently written, it allows for all the possible outcomes of opportunistic, as described in the opportunistic RFC, which is 73 54. There is a paragraph in that draft that says, opportunistic clients may hard fail and such it says if they believe, there's a really good reason. They should be able to authenticate. So, for example, if a server has advertised potentials and it has them, it allows for the possibility of heart failure. So this is enumerated in the draft again.

J

The question was: is that really valuable in a DNS context, or is it just much simpler to keep this simple? Take heart failure out and say opportunistic clients always always go back to clear text to get service, because people who chooses profile really want to use actually want to get dns responses. The the small want one small case that I'd sort of seen that that paragraph aloud was, for example, I'm an opportunistic client I have credentials. I talked to a server authenticate.

J

I do 100 connections and they will authenticate and then one stops the next one the authentication fails. So that's an indication something's wrong as a client I might decide to act on that and not continuous service.

J

Although the flip side of that is well, it could just be if get expired or something went wrong. I'm opportunistic I should carry on anyway, so again, feedback on whether that hard fail really make sense. A DNS would be would be great.

J

Just to reiterate, there is an implementation of this draft in stubby, which is the client demon mode of get dns, which has the NSF a TLS what's implemented in. That is the option to pick either a strict or an opportunistic profile, and you can also configure a name or an SP code pin set as the basis for authentication art. So, lastly, I apologies couldn't resist all the other protocols. Did it so and Dennis didn't, but seriously. What I really think we would like to do today is get some consensus on moving the draft forward.

J

It's really the last big piece left in terms of the recursive do stub picture and it's slightly stalled at the moment. So if we could possibly even get volunteers from the room to commit to reviewing this, that would be great because I think we need to try and define an end point for the last call and how to move that forward. So that's the requested to the working group today, I think that's. It is everything.

B

Questions comments on either of the questions.

K

Stefan BOTS mayor regarding the choice of must, should I think that it's not too big a problem because it does not. It does not create problem for interoperable Intel operability because in all case, it's only local policy decision, for instance, for the example of out fail, I mean if someone is really paranoid on, wants to offer a rather than to send anything key. They will do it, no matter what we put in the vessel. Actually, the most should hear in that case are not necessary for interoperability.

K

Their advice that we give so what we could do is just to say. Okay, here are the possible choices. Here. Are the consequence functions a consequence of strict? Is you may not have any DNS service in the case a consequence of opportunistic? Is, you may be in the queue and be exposed cetera on? So we should not, in my opinion, argue too much about Muslim should in this case, because they have no Intel probability consequences. So don't worry, be appear to dwell.

L

Paul Hoffman I'm doing things in reverse: I have reviewed it. Yes, I will. But you have a couple of open questions that I think I'm the cause of some of them, so I promise to re-review it. If other people will review it and I won't do it. If you don't um on the two questions, um I think on the mus should question on. This is only about opportunistic and I. Think you've already done a good enough job in the earlier sections on telling people how to choose between strict and opportunistic.

L

So an opportunistic someone doing opportunistic, who wants to be strict like didn't, understand the earlier text. They should be stripped. So your example of a actually this is on the next one. So I think the current one is fine, but on the going to clear text your example of well what, if they've connected hundred times and now they notice this they're not really being opportunistic, if in fact, they're noticing this and they're logging this they really are being they're acting like they're strict. They should be choosing the strict profile and again I.

L

Think you did that fine before so. I think these two questions are sort of for people who are choosing opportunistic, but they didn't understand it. So, in this case I would absolutely say, should fall back to clear text. There's absolutely no reason to fall know if you've chosen opportunistic not to fall back to clear text, we don't have an indicator for them. Even if someone was at an indicator, if someone's paying it.

L

If the human or the system is paying attention the indicator, they probably wanted to be stripped so I I believe both of these are be liberal, because we're talking opportunistic not only because we've defined strict, but we've also told people how to choose between them. So.

J

You're suggesting leaflet as a shirt and remove heart fail as an option. Absolutely hi.

C

This is Daniel Congo, more so um I think the scenario that you described- Sarah that says I you know, make the connection for a hundred times and then at that point suddenly something fails. I think you're describing a client that maybe learns to move from opportunistic district or something like that right. That may not be a strictly opportunistic strictly off in it. Sorry that may not be a purely opportunistic profile right you, the two profiles that we provided are sort of a amnesiac right.

C

We said this is a mode you can operate in and this is another mode. You can operate it and it doesn't include any idea of like shifting modes over time or anything like that. If we wanted to define some kind of sensible policy for how you could learn or latch or from one to the other, or something like that, I think that would be a separate discussion.

C

So I'm, fine, with saying opportunistic mode is opportunistic and going with what Paul said and then, if we wanted to find something that, like is a cleverer more stateful way of being that we could do that as a separate draft. I'm.

J

Hearing that hot file is toast for this draft.

D

Dan York I would just note that you're actually right their debts for the record. That's 7435 is the I'm.

J

Really good at I pizen were seen us. Thank you.

J

So I'm gonna pester is there any volunteers to review so.

B

Yeah, please please offer to review um so Stefan Alexander who's writing these down. We should you have a pen yeah. um There are many people in the front of the room. Who else please.

J

B

John, so we're not gonna, let anyone leave the room until we have at least another what five volunteers you John! Thank you oh and Stuart Cheshire. Thank you and that looks like an Andrew in the back ajs. So.

L

A way to think about this is, if you participated in the 73 5445 discussion, you know about trying to define opportunistic. You absolutely should be reviewing this document, because if you had an opinion, then this is the best way to know whether your opinion.

B

Was valid actually I'm sure your opinion was valid. This is the best way to prove that your opinion was valid. um I see I'm a pound set over there who hasn't offered to review yet just write them down. Okay, okay. We.

J

Can make out names right, yeah.

F

We'll just I'll just write names down and click people list; okay, okay,.

B

Hey anyone else last chance for the wonderful opportunity to volunteer to review the draft. It's a nice draft. Oh yes, volunteering.

F

Sorry are ya. Thank.

B

You, sir okay, thank you and next ed NSO, padding profiles.

F

M

Oh click your scenes here, thanks everyone, um so this is about the drafters sent in the individual submission draft me or hope for deprived betting profiles. I sent it in your like right before the deadline so understand. If well, not too many people have read it. So, a short recap: what seediness you're petting all about, even even recent cryptid dns, there's a there's the probability that you might be able to gather some kind of information based on the size of the encrypted packages, so there's a size based correlation side-channel attack on on on encrypted units.

M

So the idea was then to conceal the original message size by reading it in some way, and so what we did we published, RFC 7-830 inmate is here which arm has an IDI na 0 option that essentially has just certain lengths of croft headed to the package preferable. 0 bytes um in that draft are in the Darcy. However, there's there was deliberately no specification of the bedding lengths because we found that it would be easier to specify the option right away and talking about the actual application of that options. The later point in time.

M

um So actually, there was ongoing implementation work. I have listed a couple of the implementations on that page. I hope it's up to date. If you don't find your implementation on theirs and you should be an email, so in multiple implement is actually approached me and said so, what's what's the right padding yanks, do I use what what in what way to a pit? So there was no text available regarding possible strategies arm and even further. There is no text available, but the quality of a certain strategy.

M

How do we actually measure the quality of a certain strategy in which we paid um even it? More interestingly, is there a single best strategy? Is there the pony that we all want, and we believe that this is the wrong spot for too much creativity? So we think that you can. You can do a lot of things wrong and we need implement their guidance, so I created the Strommen proposal, that's actually very short craft. It's the fully baked that contains a couple of options.

M

So the most obvious option is, you simply do no padding, which obviously doesn't improve the situation at all. You can do fixed length bedding, which obviously is easily discoverable by a single packet, so it doesn't improve the situation as well. um You can do create the packet, the message to certain law. Flings, you can choose the witch which block lens you want to pay. It seems like most people either go for 64 or 128 bit by it's at the current point in time.

M

You can of course, ah do random lengths back there petting, so you use a uniformly distributed size of pairings that you spread out across all your packets, and you can also randomize the block lengths. You appeared there like it, probably a couple of more strategies arm and it sort of talks a little bit about the pros and cons for each profile of strategy. So I received a couple of comments around good. It looks like a great start arm.

M

I did clarification of one strategy I received comments that there might be more strategies, for example, what we call the full monty strategy, which is parish message to the absolute limit of of the message size and so I had the impression that it would be interesting to the working group and moving what would be a good thing. So um the most exciting thing thing this week we had a hallway discussion yesterday. That was really great.

M

It was like about an hour arm so and what what we find out this there is actually ongoing research by a couple of people on the quality estimation of that strategies. So danielle has some data that he's going to look at sarah said she probably would be able to get some research papers even in, and we also found out. I need to change it in the draft that padding shouldn't consider TM l.d.b.d the TCB message length to buy prefix.

M

We actually didn't know what the correct description of that was, but UDP and TCP a message is differ by lengths of two and we shouldn't consider that for petting, because there is a certain use case. That would make it discoverable so and also we were concerned about client fingerprinting. So if a client follows a specific reading strategy arm, then it would be possible to fingerprint a client based on its mating behavior. So that's not a good thing and a single golden strategy that we can come up with. With prevent this.

M

um We also found out that we might need to consider future Adina's options, especially on the query side, because this might change the query size of of messages, and we need media t to be fruity proof on that, and so, regarding which strategy is the best.

M

We probably found a formula that is like its privacy game versus bandwidth and processing costs. So we need to look into that so a question: um what are the next steps? So?

M

Hopefully more research is coming in soon, so we gonna look at some data that we received from from recursive DNS operators like I'm talking with my recursive DNS operators at a local university as well um and more like the questions that I'm sort of like channeling. You guys is this a problem that the working group sings a exists and pH should be addressed and yada yada. The next logical step is this document actually something that we can r adopt as a boilerplate without having a red face, or it is for this working group.

M

So that's it I had five minutes and comments, questions how many people actually read the draft or the discussion around it.

N

Oh yeah, we were gonna, ask that but yeah okay, cool I, get where you half dozen yeah.

O

Derek line I'm hoping you'll. Permit me a very naive question where or which wich of the ones described, would you say or what are the advantages or disadvantages specifically of just padding to say, MSS.

M

Well, I think it's a resource question if you have a mobile client, maybe and your may be concerned about betting, each energy, every message to the full monty lengths of what we have, but that's that's something that we need to research. What's a real impact, the.

J

Ways that we can.

M

We can probably pay it each query to 256 bytes arm and no query is larger than like 120 or something or.

O

Or padding to 1280 MTU kind.

M

Of things you sort of adding to a.

O

M

Message as I said, there are probably more strategies and we need to describe them arm. The question is whether we want to like have to drop the kombucha, bigger, bigger all the time, with all the strategies and then finally, like compact, it again to the one strategy. We came up with it's the good one. So it's a question of what such strategy for the threat I.

O

Wasn't offering it, as yesterday, I have no idea if it's a good idea or a bad idea has been just a padding to a fixed, like um so you're ready, Kelly from a.

M

O

Room to you from.

M

A privacy perspective petting each and every message to the absolute maximum after yeah.

O

I mean quick sort of. Does that too? I think at the moment right. The initial, quick exchanges I think they Pat it out to Gibby garant, among other things, to make sure that there aren't any path, MTU problems but, like you just had to TCP MSS or something right anyway. Thank you.

L

Paul Hoffman um I have I, have concern not like researched concern about some of this. For two reasons. One is I believe that the privacy are trying to get is over the name itself, the length of the name or blank name, but it ignores the fact that there's going to be other has zero options, possibly to it. So if you say pad to 100 bytes, which seems like enough for most domain names is that 100 bytes, including the Eden s0.

L

That was already that you know that the other eating of 0 options are not, and if it is including the other eating at zero options, then that this one has to be added last etc. You now have have introduced a processing thing, I, think that if you are focused on just we're trying to add length privacy to the domain name that in fact a number in you know if we figure out normal domain name sizes and add some to that light.

L

Like we look at those sort of long tail, knowing that we're going to miss some of them and so we're gonna, add zero, padding or you know obvious padding to some of them, but get ninety-five percent in I. Think that'll be ok and I. Don't think it's going to be a lot of characters, I think I. Think we're really talking 50 or something like that. So maximum, I think, is a really bad idea for many was damned and your plugin. Oh.

C

L

Not that early in the morning, um but um it you know. So if the problem statement is it's just the length of the name, do a little bit of research on name links. Don't do ridiculous ones and I think we'll be fine, because we won't be adding that much um yeah. A couple of.

M

Couple of things to that, so, first, what the I? What's the current way, the current implementations work in a way that they had betting as the last option. After all, the other in ens, your options have been added yep and all the implementations I'm aware of to petting to a certain block lengths 64 also.

J

M

And regarding coming back to a question about, is it just to conceal the name itself, the queue name or something else? My understanding from from from the from the academic working that the area is that the suspicion is that the whole length of the packet, including the corresponding response, is being used to fingerprint the name. So it doesn't just help to conceal the length of the name itself. It's the combination of the original message links and the response links. So, okay,.

J

M

So it's like the whole thing: it's okay.

J

M

Gives you sort of like a space of it's a two-dimensional matrix of query lengths and response lengths, and once you got like only three packets in that bin yeah and you see such a combination coming in? You can, like guess, between car games yeah. It.

J

M

Even worse, looking at a whole traffic of require.

E

L

M

They have like Collateral dns queries like okay,.

L

Then then you should say: if you're using this, you really should do it last I. Think.

M

That's in 7, 8 30, but I need to look it up. Okay,.

L

P

Don't remember it from there ens.

M

You're petting must be. The last option applies. Ok,.

J

Sorry, Dickinson I just wanted to express support for this draft I've sat in for hackathons we're different people have tried to implement this and every single time they SAT there and said how am I supposed to do this. um It's a real problem and I'd also like to see it move forward quickly, because the sooner we have the same mechanism across the implementations more effective. This technique is going to be so I'm willing to review and commit texture cool thanks.

M

Q

Allison Mencken um I also obviously very much support. The draft I am really glad the question about the golden standard surfaced because when you go to various gatherings of privacy researchers, it's often the case that everything you've done everything right and then a pattern from the DMS support gives you away. It gives away what you are and I think it's important to try to be very indistinguishable in that front and also remember that people may want to use an agreed-upon port such that it's not distinguishable this DNS, so facilitating.

Q

That may be a piece that isn't in the draft. At this point. Okay,.

M

Thanks for coming, it's nice.

C

This is dkg as someone who's done, implementations of padding. Thank you very much for advancing this I would be really happy if the working group would consider this for adoption and I do also offer to review sale.

M

C

I I I want to see this advance because I think if people can contribute as a strap is under discussion if they have new padding policy is like what came up earlier about TCP MSS I would love to see those contributions happen on the list. I don't have a specific preference, because I don't have the data right now, but we're working on getting the data, and hopefully we can have something that's published that compares things. So if you have a proposal, we might have a framework to be able to test that proposal.

C

But you got to let us know what what the padding mechanism is. So gathering data and trying to do research right now and I would love to have us have a concrete recommendation.

P

John Lavigne I'm sort of agreeing with Dan here is I, totally endorsed the this drafted concept. My concern about the about the details is that there's too many options right now and I'm wondering whether you know if people are really doing vigorously doing research could be Park it long enough to see. If there's some of them would speak with some of the options we could throw out, throw out and give us ideally only one or two options so go.

N

B

So as a quick show of hands who all has read this document, who all has read the document?

B

Okay, um let's try and get an idea on we'll do a quick hum on a call for adoption. It sounds as though people who support it support it fairly strongly. So we'll have to do this on list as well, but we'll try and keep it really short and a reminder to people to please comment on the list when you do an on list call for adoption, so we'll do a hum first for those who think we should adopt this document and then another one for those who think we should not adopt this document.

B

So people who think we should adopt this document, please hum now.

B

And multiple homes in the chat room, okay, people who think we should not adopt this document- please him now great for the minute taker. There was a lot of support for us adopting this. We will do it on this, but I'm assuming this will be adopted. So if people can also please stop providing feedback, so you know it can be incorporated as when etc. That.

F

Would be great, yeah look for look for a call for adoption. Probably this afternoon has that to get on the list. We're.

B

Not going to waste time yep and yep when the call for adoption happens, please actually review the document. It's only six pages long and, as you know, the first many pages always boilerplate and you know, should must etc. It's short, I fear it's going to crow, but, as I said, we can hopefully shrink it again like.

F

Them to you, like you, Rachel documents, it's made us thank.

B

You, okay thanks, so let me just double check that was all of the primary set that was the primary sir okay, so that was the primary set of things um the there's been sort of some push to. It have more of a sort of different style of working group meetings, so we're going to experimenting with sort of a buff style thing here on the phase to work.

B

Our charter doesn't actually specify that we can only work on the Phase one work, but when we started discussing this, you know we'd always discuss their being phase, one which is dubbed recursive and then phase two, which is a cursive to auth. So we're gonna discuss the phase two stuff now I'm Stefan will be leading this.

B

Yeah I guess we'll start general chat. It's going to be much less formal, although this hasn't been a particularly formal meeting so far, so picking up a cartel.

K

I would also suggest to review the milestones, because now all the milestones I've been done, so we have nothing to do we are so unless we want to go to back to sleep, we have to find some work so current state. So I said the cutter said that the primary focus is the link between the stub resolver on the Wizards 0 itself.

K

We have already ofc 78 58 about step to resolve the authentication and I hope that profile document will be published as well soon. So basically, this is done great congratulations, but door cutter also int that we can walk on the wizard virtual, so additive link on any way we can always reach out. If we think it's important. My proposal is to reuse what we have done with DNS over TLS I I. Don't really see the point of inventing a new protocol for the resolver to authoritative link. We already have FFC 78 58.

K

We should we use it or the future DNS of the dtls as well, but this leaves the big issue, which is a one of authentication. If you don't know Datuk authenticate, if you are completely opportunistic, it's okay, we can start doing with over to author a tat if TLS tomorrow, no today even today, but authentication is of course a big deal. It's the problem is quite different from the stub to resolve a problem, because in the step to resolve well, you are very few service.

K

Typically, you have a static configuration for a few resolvers that you trust and you have a TLS link with them. You you can even have a static key so which is ok. I mean the static. Keep pinging is ok for this link, but in the resolver to authoritative the wizard world. Do not talk to a few machines that it knows about. It, talks to hundred thousand dozens of thousands of authoritative servers and most case it does not have a pre-existing relationship with them.

K

So, for instance, a static key in the case of wizard were too authoritative is simply out of question, so we need something more dynamic. So there are many possible techniques in this draft. I tried to make a complete list. The goal of the draft is that to suggest one possible solution is, at this stage just to list all the possible tactics. A few of them, for instance, could be simply anchored the public key of the authoritative server in its name.

K

Then we using delegation as a way to convey authentication information, public information which why it's already done in the script. It's one possible solution. My goal here is that to say that it is a wide solution, but just to show that the problem is perfectly tractable and other possibilities to use ordinary pickax validation. I mean in the TLS answer from the authoritative server. You have a certificate, we can validate it.

K

The sort of thing you can also put the information about the certificate in the DNS itself is then it's a bit tricky because then you have a chicken-and-egg problem, but it can be solved under thou. Also support solutions are we fell to the draft if you want to have the listen, please if I forgot, one possible solution in the draft send email to the list pull request anything.

K

So one of the difficult thing is to try to find out how many solution that we use I mean we may decide that we have only one way to authenticate the white one. We may decide to have two and three, but not, of course, I. Think in the draft. There are six possible solutions: it's not realistic to try all of them, and there is a problem because, of course, if they give different results, you have to choose which one was white.

K

So if we decide to have two or three solutions, we have to design of the respective pie.

K

So now concrete things to do. In my opinion, we should try to decide not not today but were on the mailing list among the solutions in the draft which one are interesting, realistic, then, of course, white an internet draft with it I wouldn't here for that by the way, if so enough, people volunteer to be a participants, reviewers, etc.

K

That one of the things I would like to assess is if there is enough steam in the group to work on this, maybe we need to update the chart out while I'm not really interested in the bureaucratic stuff like that, but maybe it's necessary. Why not, and then it's done so open to discussion now.

L

B

Just affect no, you know we're going to have this discussion. We also need to negotiate with our ad and what we're going to be doing after this potentially getting more deployment, experience, etc is needed first, but this.

C

Is dkg? I definitely think we should push for this I worry about. If the question is how much team do we have, and we judge it on the fact that this is the last session on friday at the ITF. I hope that I hope we you know adjust for that variable.

C

It would be a real shame to wrap up deprived without trying to address this. This leg, I'm not going to get into which of the different solutions, I think, is the right one here, except to say that, in addition to, I think, picking a very small number of possible authentication mechanisms, I think we should make sure that we also think concretely about deployment strategy, because we're going to be in a mixed network for a long time, possibly forever, because at the ITF we go with the curse of the deployed base.

C

But I want to make sure that we think about proposing concrete strategies for recursive resolvers, who don't know where they're talking to appear that that can do this. And if that's the case, you know we need to make sure that we that we have a strategy for how to get how to get there. So, yes, I think we should do the stuff and I want to make sure that it also includes implementation guidance. That's practical and deployable in a mixed network, a.

K

Related implementation problem is that in the future, if this works resolve were talking to a new authoritative, it doesn't know about, we have to choose between UDP TCP TLS on DTLS, so certainly it requires some smartness.

D

Dan yerka coming in is Jabbar scribe relaying from shanker. He says, I think this is important work and supports adoption. I think the scaling properties of resolver to authoritative may mean that DNS over TLS is non optimal. I, don't know this, but it seems possible independent of the authentication problem.

L

R

L

Talked to some people about this before earlier than this week and I said, I was sort of negative on it, because I have a big concern about authoritative servers being open to attack on their CPU and memory on opening up too many TLS connections in the normal response as well Google does it and Facebook does it? Therefore, everyone can do it, and my response has been well.

L

They get paid to do that, whereas a lot of authoritative servers don't really get paid that much to do things in this week, though I talked with dkg and I actually am now much more sanguine about doing. This. I think that there are ways by pickings that frozen since maybe TLS 1.3, only suggesting using lipped occurs and such like that so I am I, am much much more positive that we can probably deployed this without opening authoritative servers who want to do it too easy cpu and memory denial service attacks.

L

Having said that, one thing: I, don't really see in your draft. Much is what we've just been spending time on, which is profiles for strict versus opportunistic and I would suspect that in the early days, and maybe even later, opportunistic will be just fine for a lot of people and therefore I agree with what Dan said that what we should do in whatever document we do is we also specify deployment strategies and it's perfectly fine, I- think for a recursive operator to be doing this opportunistically, particularly if they're a validating, recursive resolver.

L

If all they're doing this for is to get encryption and they don't really care about who I'm talking to because they're going to do DNS, SEC validation that might be sufficient for them. I, don't know I would I, haven't written down the chart of with the lines and such like that, but I would suspect. Opportunistic would actually be just fine as well so I, very much support doing this work. I think that this is a very logical next step and I agree with you that for doing authentication we should have a limited number.

L

I don't think it should be just one. We should have limit number some of the ones that you've proposed in fact work together. Well, so you can do a DNS curve, type naming scheme and P kicks, there's no reason not to, and now that we're in a world where it's fairly easy to get TLS certs. It may be that one or the other would be just fine. You know so that is, we can have both of those and someone might combine them. It's.

K

True that the profile are not in the current draft, because there is one more difference between a stub to visit van with other two authoritative. It's in the second case, it's much more difficult to report problem, authentication programs to the users. In the first case, you can imagine to be a post popping up a message saying there was not possible to interrogation. Also, deviations felt something like that in, though, is over to authoritative it's no longer possible. So, for instance, a strict is much more dangerous. Yes,.

L

I agree: the strict is more dangerous and therefore I don't want us to insist on certain kind. Insist on authentication, although I certainly want us to allow it, because I can imagine a world where a recursive operator would say I'm going to require TLS authentication. If the answers are not DNS SEC signed.

C

S

Principle, I I, molar gumus on from cloudflare in principle, I support a work like this, but there are certain serious scaling issues that we need to think about. When you sent a question to an authoritative server, it may be serving up hundreds of use, or you may have on your network hundreds of a name author of the servers, and we don't necessarily want every recursive farm to have a TLS connection to every combination of IP addresses between the two of them.

S

So any protocol that is really going to scale in this world is going to need some kind of a tunneling mechanism in my opinion, so we can tell them somehow over the protocol. Any questions for these address ranges just send them to me and I'll figure out how to get it to you. Almost I envision this some kind of a proxy service, not as ins necessary connection directly to the nameserver. Just a trusted entity on my network, I.

F

Think andrew is next and then Allison I'm.

E

Andrew Sullivan, um so I, I, guess I agree with most of the things that people have said. um I under I looked at the draft and I think that, but I didn't really very carefully and on. It seems to me that there there's an enormous number of subtleties in there. That I think the draft actually mentions, but that are maybe not entirely clear to people who have not operated this infrastructure at large scale.

E

So I I think that if this working group is going to tackle this, actually it really does need to change its charter, um because I think that the rest of the IETF might be interested in this in a way that they were not interested in the stub to resolver case uh and and and while I think it would be very difficult for somebody to object to that change of charter by getting up in public and saying no, no privacy is a bad thing because they would be called down.

E

um You know um frogs and so on upon them on the the possibility, of course, is that if we don't do something about the Charter, somebody will come along later.

E

If they've got an agenda about this and they'll complain that they weren't warned and though all the work will go for nothing so I would encourage us to work out precisely what we were going to do and then work out the range of things that are in this draft and some of the things that people just mentioned about the scope of the problems that are facing us. Because it's it's a it's a bigger piece of work, then I think it initially looks, looks like just because we've already got the model of the stub to resolver.

E

While we all used to thinking of DNS is just sort of messages that are passed around, but the operational realities are very different. Thanks. Oh and thanks for the draft, it's pretty good.

Q

um So I definitely want to give more comments. An email on the draft, but but I do also appreciate it very much. I just wanted to mention. There's a there's, a case where you might offer encrypted service to certain Authority natives, because they have sensitivities and have people aware of or be able to be signaled that they can reach those authoritative over TLS and it's a kind of a controlled case.

Q

It's not the entire global infrastructure but, for example, authoritative that serve you know, controversial or dissident they information zones, or things like that and I even chatted a little bit with Shane about the idea that you could have you like some instances of root which provide this and you just choose to go to those. If you think you need to lash up a safer, more private path, all the way, that's not quite the same as addressing making it bulletproof and making it available for the entire global Internet.

Q

So I don't know how that can, whether that's a separate little draft to say we can use this in certain circumstances. The way we have it now that could come ahead of solving the problem in the more general case.

K

One of the consequences of the first method, the DNS curve, adian script- didn't escape actually I. There is a mistake in the slide. It's actually DNS curve. One of the consequences is that it can be used as a form of signaling. You tell people that they can expect cryptography and privacy from this server, something which you cannot done with cannot do with our FC 78 58 alone. So maybe we should add something more right.

Q

Have a way to offer that for as a service for certain servers that want to try it out, yeah I think that's an interesting idea. Then.

K

Is also another way to signal that y'all ready to do TLS and privacy.

B

You know so I guess, Mike and and then John I, just.

R

B

R

B

R

Its power angle also mentioned the root servers and if you think you name is minimization, there may be an argument say you don't really need privacy at the root.

R

Oh bubs Piniella good question a.

T

Gun hello: this is smokin from I, see so stop the resolve. The communications have settled on TLS over TCP, and this seems fairly good for stop those other communications. I am worried and I wonder if TLS over TCP is the right approach for resolver to a parrot of civil communications arm.

T

There are several round trips in establishing such a such a session arm and when it is also operates. Basically, there are more than one look up, usually when you're trying to look up some domain dns s is the head of everything. So this adds to the turnaround time, for example, if you're establishing a https session to a web server, you first do the dns lookup and only then you can start a connection as you become tcp connection and then idealist session over that for HTTP. But before that you have to have your domain.

T

Looked up your your address hooked up for that web server and if the, if that is going to take a lot of time, then that adds to the turn around time of of the entire basically HTTP connection. Now, where I am in the world for a typical name, server I get about 300, milliseconds or RTT.

T

So with a UDP, lookup or plain plain, you repeat: look up over DNS, so that takes tended milliseconds. If I add tcp with the 2-way 3-way handshake with a three-way handshake. Let's not consider fast stupid right now we are still in olden times. um We uh you have at least two round trips for that, and then you establish to tell a session over that that takes even more time even more round trips, that is for one fetch from a recursive resolver to an authority of server.

T

You may have multiple fetches to deal with, so each fetch may take more than one second and you're, basically looking up for several seconds even before you actually do, even before the application is able to connect to whatever address it's trying to connect to so I, and there are other methods.

T

um My colleague, we told presented one a couple of ATF's ago in yokohama, and this is based similar to the DJ B method tienes curve, so which basically lets you use one round trip and UDP to get a encrypted connection to to an authoritative server from our recursive resolver. So I think we should. We should evaluate other approaches empirically and especially pls itself. We should evaluate it empirically to see how well it will work before we settle owner. Thank you.

B

And just be care, this discussion is mainly the you know. Do we want to move on to the phase to work? Not specifically, you know Stefan's document or any particular one of the specific solutions. The reason that we split up into phase 1 and phase 2 is because we realized phase. Two was a lot harder. There are cursive tour, you know, has a lot more scaling issues, a lot more connections, so you know lo, you need to make sure the latency is low, etc. Yeah.

T

But I'm sorry I I just looked at the graph, which basically starts with key establishment for TLS over TCP a dealer's over TLS. That's what the draft says and so that's why yeah.

K

But certainly I agree well win, but certainly it's important to get an idea of the amount of folks that we have to do on the coach we have to make on this. One is extremely important, because I took for granted that we really we use DNS over TLS. It seems up views. Apparently not everyone agrees. So this is certainly a very important discussion on decision.

K

F

And then gentleman in the back and then dkg yeah generally.

U

Speaking this for myself, self and I think the just very good idea of giving us all food for thought and, while I do think, this is something that the group should be. What kiala take things forward. One thing I would see those we've got also think that it very carefully we take this thing on about the deployment plans.

U

Dkg was mentioning before and I'm particular concern the boats, if we're going to have some self secured mechanism for securing the path between us, dub and resolving server and then doing another one to secure the path from the resolving several to the thought. The servers I think that's going to get very ugly if, after separate mechanisms beneath there was one overarching one they could apply in both circumstances appreciate, that's very, very difficult was also elastic horrible sorts of scaling issues in there.

U

It probably even can't be done, but if you're going to do this well, I think it'd be useful to try to think of it. Do there are we we should be clean and as simple as possible. We've got far too many potential paths here for doing the security for securing these communication paths already. I, don't think we should be adopted without my penknife approaching, having multiple approaches to got to keep a killing the simple.

V

Hi, my name is Tim shepparton. Actually, first I'd like to thank you all for the wonderful tutorial on Sunday afternoon. That was amazing. I had paid no attention to this working group before Sunday afternoon and I was. That was a very well done tutorial and that's why I got interested to come this afternoon. um I think well. Encryption, encrypting, Lee, query in the reply from the stub to the resolver seems to solve the problem of providing privacy. I think there's a deeper problem that the query from the resolver to the authoritative.

V

You can encrypt the query, app that comes after the IP header and whatever other header, but the IP header has in it the IP address of the authoritative server that it's going to and oh boy.

V

It seems to me that that reveals a lot about what name you might be looking up and but perhaps from depending on what resolver you're using, maybe it maybe it doesn't identify what user looked it up or something, but there's something complicated and subtle about what problem are you trying to solve to provide privacy in the traffic that flows between the the resolver and the authoritative I mean there?

V

Aren't there are a lot of authoritative servers in the world that serve up, maybe only one zone and well obviously they were trying to look up a name in that zone and then actually the route I think um what is the authority that creates new TLDs like.

B

Companies Anna I.

V

An or I Anna I anorak, I canna but I, don't know how the process works, but they're creating lots of new top-level domains. There's going to be an awful lot of stuff in the route and I guess, maybe, if you're looking up one of those, then encrypting your communication to the root does in fact provide some privacy, but anyway, bye, I, just thought, I'd think I.

V

Actually, before you figure out how to encrypt and worrying about scale, I think you actually have to stop for a moment, step back and think about what what problems are you trying to solve and maybe which problems that you might like to solve or insoluble, etc and think carefully about that? That's just a thought. So we are.

K

We excuse me, but regarding the risk of communication between the wizard on the authoritative, I believe it is well covered in RFC 7626, which is not limited to just stop to resolve. Oh- and there is a lot of discussion about this, exactly who you are talking about is the fact that you talk to this authoritative server enough information to did use what's going on on to Daisy answer is no, because, unfortunately, there is a big concentration of DNS, authoritative service to sub big provider.

K

When I see someone talking with Dinah, for instance, it gives me very little information because they asked what 200,000 amends or something like that. So it's a two-day. It's not really a problem. Now I would like to to reply about a Jones question about CUNY minimization. It depends on at what level you are. For instance, when you talk to the root, the fact that you asked comma dot org means nothing, because everyone talks to the once is interested in como dog.

K

If you worry about that JP, it may be more revealing because few people do and then the lower you are in the tree. The most revealing it is talking to the organ. Nameserver means absolutely nothing but querying them for alcoa. Alcoholics. Anonymous dog is more revealing on same thing at the third level, so in the one where the wood is a special case, because most of the time it doesn't really matter, but all the other authoritative servers can be subject to surveillance, spy sniffing, it's Tara. It.

B

Was dkg then down, then my eyes aren't good enough to see past the face.

C

This is dkg, so I fully agree with Tim that we do also need to be thinking about the sort of traffic analysis concerns, and I also have you Stefan that you know, depending on the deployment of the network, that may not be an issue for certain queries. I recommend, if anyone's interested in reading that kind of details about that kind of research, hiya Schulman has a paper called pretty bad privacy, the perils of DNS encryption, which talks about a lot of these additional channels and that we do need to be thinking about those.

C

And hopefully we can think about them in this group as well. But will we will no matter what we will still need transport encryption, regardless of how we address the other channels? Alison's point about saying that? Well, maybe you could have some authoritative that you know you will always do strong crypto, because that's where you look up the dangerous stuff that worries me a lot.

C

That's an easy target for censorship, will just block the sketchy, authoritative and the no one will be able to get to the dangerous stuff so I'm, not so sure that that's the outcome that we should be aiming for and if we find ourselves heading in that direction, I'd like to to step back and I. Thirdly- and this is my last point here- I wanted to call out something that Paul said that I think is worth noting.

C

He sort of mentioned in passing that we could profile the authoritative, the recursive to authoritative link. It is TLS profiles, so the the performance concerns are very real I. Thank you for raising them, but with TLS by the time we get around to getting the specified fingers crossed here. Don't make me don't make me liar, but TLS 1.3 will exist.

C

Sorry, TLS 1.3, combined with TLS with TCP fast open, gives you actually a one-round like the first. Basically you get data in the first packet. It's not forward secure, there's a bunch of weird other properties that you get from it, but it actually starts to look much more similar in performance characteristics to a UDP query.

C

At the very least, if you've made one additional, maybe the first time you ever talk to that server, you have to cash a little bit of data as a client, but once you do, you can then do basically like one shot request. Get it get one shot answer back, so so I'm not saying so. If we can profile the TLS bits by the time this this thing is released. We can say, if you're going to deploy this stuff, you need to pull it with a modern TLS stack.

C

Then we have an opportunity to make you to take advantage of all these additional performance tuning characteristics that we've got right now looks like that. Does note. There's no cable on that mic.

R

C

Know it smoking.

T

Again, the first time is also important in a lot of cases. You know, resolvers are moving closer and closer to actual hosts that used them. For example, system tease getting a resolver may be funny, but system T is gay. It has a resolver resolver.

C

Is a is a stub, though it talks it's only a forward. Okay,.

T

In any case, you want to be as close as possible to your validating resolver, because most applications from validate, although DNS SEC, allows into invalidation most applications, basically trust whatever the resolver gives them. So you want you well, you want your validator validating resolver to be as close to you as possible, and that's the general movement of the service as well. People are using public is always less and less and getting resolves closer and closer to their hosts, whatever using them.

T

So, in a lot of cases, you will have resolvers that are that don't have an existing trust relationship or anything existing cookie or whatever, with a remote server. So there will always be this thing about first time use all the time. If, for any as an example, you typical use cases, somebody wakes up in the morning goes to reddit or how can use opens a bunch of websites. Those are all you name. Servers lot of. Lot of them are armed known, URLs, but lot of them are random. Urls.

T

You want them to open up as soon as possible. You don't want to wait. Looking at hosting I agree.

C

With you and sorry, I'm about to sit down, I just want to point out that we may need, as a community, to clarify the distinction between having a local validating resolver that just does the validation and does forwarding to a gathering resolver right. So that's actually what the system, the implementation is doing and I totally agree with you that you want your validating resolver as close to you as possible, because you want it inside your trust boundary.

C

But that may not be the thing that does the recursive work right, you have your validating resolver that talks as a forwarder to a gathering resolver anyway, as a community. We should be documenting. This I would love to work with you on that. If your name is, we.

T

Should be trying to UM basically settle on a solution that works in every case, not just on specific cases. If I run a caching resolver by myself, I wanted to eat to perform well as well, so.

D

It's dan york, I wanted to just kind of say I think you want to brings back to I. Think you're asking us right. Do we want to do this? Work does.

B

The working group have interest in continuing this, and should we go to sleep and in right? Well,.

D

I just want say, I think from a process point of view we're getting a lot of engineering of solutions at the mics, but I think the solution you're. What you're looking for from us is. Do we want to do that and while I'm here I will say yes I think this is worthwhile to consider.

D

I have a number of concerns, some of which have been raised here by others here, but I think it's worth exploring, because if we are looking at how we truly have a trusted DNS infrastructure, this is one place where we are exposing information in ways that that need to be looked at. What the solution is. I looked it to the draft, and you know: I have opinions about various different once in there, but I think it's worth having this group look at that to see what could be there and I would echo the comments.

D

A couple people made deployability will definitely be something we need to be thinking about, but yes,.

B

Let's do it so yeah. Thank you towards the very end of this, and we've still got some time and we're going to have a we're planning on having a hum for yes, the working group wants to carry on working that on this. You know we might discover it's too hard, but at least we should investigate it too. Nope should get a sleep for a year or so and then maybe discuss this all again or three nope. This is way too hard, don't bother, it's a stupid idea.

B

Give up- and you know we'll, have that thing and then we'll chat with our ad and see what he wants us to do.

J

Sorry, Dickinson I just wanted to feed into the problem statement in terms of future proofing. The dearness I mean no be really anticipated. The way individuals data was going to be added into e DNS client subnet options and exposed recursive to authoritative and I. Don't think we're the community community can anticipate future uses of that option to expose personal data, so I think that's a really solid reason to be doing this work now, rather than going to sleep.

B

Anyone else this is the last session on friday, so I guess we're the only thing that's standing between you and whatever else you want to do so. Does our ad have any thoughts questions first or shall we try this hungry I'm come? Do you have a okay, no.

F

B

So we're going to have a three-way hum first is going to be yes, the working group wants to continue working on this and you know discussing stuff and then we'll be able to figure out if it's too hard to actually accomplish or not uh Oliver Oliver.

S

To Amazon Cloud for a quick, quick question: when you say this: do you mean solution or figure out what the problem is Oh both.

B

I'm, better defining what exactly we're trying to protect from recursive to auth, basically the whole recursive to auth side. What exactly? What needs to be projected? Does everything need to be projected, or only you know, high-value things? Is there a signaling thing and then, hopefully, once we've discovered what the problem is work on a solution, so both sides, the second part of the or yeah? The second of the three hubs will be look.

B

We should just go back to sleep for a while and maybe in a year or two will wake up again and then start talking about that. Once we have some deployment experience and then the third option will be nope. This is really a stupid idea or at armful to the internet. Let's not do it, let's not just asset, let's all go home and go shopping so.

B

There's somewhat different 2 is we're planning on probably waking up again, which that of a zombie right we're going to hiatus the idea, being god no, never touch this worst idea ever that.

F

The idea being that we don't have a lot of operational experience yet with the sub to recurse in subject, you know we don't we haven't seen that data yet and as an operational person. That makes me a little nervous. I I feel that it's actually going to work it's going to scale at that level, but until we until I think we see that we're making guesses as to what we're doing in the next step, and that has me just a little bit concerned doesn't mean I want to stop. It just means I got.

F

We want to make sure we're doing we're sort of looking at the problem in several different ways, and so and.

B

I suspect this is a hard problem, and so by the time we get anywhere near solving it, we should have some deployment experience, but joel has senior.

W

Julia lee did to summon the magd magic 8-ball. Those are answer and clear. Ask again: that's number two and signs point to know. Yeah, it's number three one.

B

Of them we closed down the other one, we get to sleep, yeah, okay, so let's do this people who think that they would like to continue discussing this, so we can figure out. You know what all the problem is if it is actually addressable etc. Please hum now.

D

Multiple hums three hums in the chatter sweet.

B

If you think that we should go to sleep for a year or so, and then you know maybe discuss this, then basically the same set of questions then he's ham. Now.

B

Okay, that was much less than for the first time, um people who think that this is a bad idea. We should close down the working group as soon as we finished the current documents and never touch this ever again. Please hum now.

B

Okay, so for the scribes strong hum for us should probably stay around, might the light hum, for we should just go to sleep and wake up in a year or two and look at it then, and we didn't hear a hum for nope all done. Yep shut down hard work, so we will need to chat with our ad and figure out what all's happening. Yeah.

B

I

You've been warned, it.

X

I

I'd like to see more discussion on the mailing list, please yeah before we get to answer discussions. Thanks, sweet see.

B

It hopefully more discussion on the mailing list. I'm guessing people are tired and that more discussion will be a couple of days before it starts up again. However, I should point out. Many people have a long flight home, so please review the profiles document and provide feedback and all might as well use the plane time for something useful, not just watching bad movies. Please also review the adns profiles document. Your.

F

Padding from the.

B

Padding profiles document not the other profiles document and provide feedback on if we should adopt it. um What are we missing any last other things: hmm I, don't.

F

Know what I'm gonna say welcome to any new people who showed up like Tim and others who showed up because of the tutorial? That's great we're actually nice people. So please, you know just I think we are woohoo.

B

Yep so, and I get to press the red button, even though there's nobody in the cute cuz the red button. Okay done done, thank you all have a safe flight.

F

B

We don't care where you go, but you can't stay here: yeah, Oh, blue sheets, if you haven't signed the blue sheets, there's one up here. If somebody else has the other blue sheet, please give it to us. You can't sell it on eBay. They don't really sell very well. The secretary gets.

F

Mad, if you try to sell them so.

N

X

X