Internet Engineering Task Force Interim Meetings, 8 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DPRIVE Virtual Interim Meeting, 2020-04-08

Description

DPRIVE Virtual Interim Meeting, 2020-04-08

A

These chair, slides, are pretty short, that's the note. Well, um y'all have seen that and we can move forward um that should be fairly straightforward. The blue sheets, it's in the ether pad the ether pad link the correct ones in these slides. It's also in the agenda.

A

We can do the next slide. We have a very shortage um agenda, mostly there's some quick updates on the documents, some current working group business and a couple and a new document coming through so next slide. Eric on the document updates, let's go to one more slide: um 7626 biz, both these um and the bcp, have both sort of been a little slow moving forward. But mostly that's because um primary officer has been tied up on some personal stuff.

A

So we've been slowly working through that and there's one outstanding item in 7626 biz that she is trying to sort out with the isg right now, um and I believe once that gets done, we'll move that forward and because that document is um enormous into the bcp op. We've sort of put the bcp up sort of second and it's basically ready to go 176 26 business is wrapped up.

A

The two of them will probably slide through right together and then on the phase two um brian and I've talked recently and I'm gonna sit down and spend some some extra spare time with um alex and jason and benno and helping them sort of make sure we get all the issues addressed and see about what we can do about moving forward. If actually that needs to be done um so I said they. They saw an email from yesterday. So then the x rover, tls draft. It's been pretty quiet.

A

There's I think they've addressed most of the outstanding issues, there's a couple of items from bob harrell that they haven't addressed um and I'm kind of waiting to see the next version of that from the author. So that's a little slight hint to sort of get them to move along next slide.

A

A

And I think that's I think, there's one before that, but mostly um there's three things on the agenda. The dinos have a quick discussion with christian who's. Next, the deprived early data document, which is very short um and we're very curious. If there's some, you know, we think it's useful and we have some interesting brian anderson discussions about that, and then daniel got something to sort of entertain us at the end on signaling feet during policies.

A

So with that, um if we can bring up christian slides and we can get right to christian and get things going, so thanks for being patient folks and, like brian said well, we don't think we'll take the full 90 minutes, but we're not going to rush through anything. So thanks a lot christian.

B

C

I am going to present the draft. We have been working on the dns over quick. We did work on that draft off and on for the last two years in the quick working group- and I just resubmitted it in the deprive working group because because of what we'll see next so I'll change the slide.

C

Is that the first slide? No? No! No! No! No! Yes! Okay! So what are we speaking about? What we want to define is a very simple mapping of dns, of a quick connection that just does dns and nothing else, and the principle of the mapping are straightforward. I mean we used a quick stream to isolate connection so isolate queries and responses.

C

So each query opens a stream and the response come on the same stream and then the stream is closed. We will have a 64k size limit on each query to be compatible with dns or ttp.

C

There is a specification of parallel processing, so there is no head of queue blocking and that's also a feature of quick and difference with tcp is that if there are several several queries in progress and one of the packet carrying one of the queries is lost in tcp, you will get head of q blocking. You will have to wait until that missing packet has been corrected to process all the other packets with quick. You don't have to do that.

C

The first target of the draft is the stop to because, if scenario, the main reason for that is that we cannot really address recursive to authoritative without having a way to discover the servers. I mean, if we don't have.

C

If the recursive don't know with certainty that this server supposed supports dns over quick, then they are going to do a dance of trying and then failing and then failing over to dns of our udp or dns of our ls, and that will be just a waste of time. So the real reason to not do stub to recursive in quick right now is because we are waiting for the discovery dns over quick operates on a dedicated port which is to be allocated by ir. It's not defined yet next slide.

C

So, to give you an idea how it works, I mean quick is a fairly lightweight protocol, but still what quick does is embed a tls to negotiate the encryption keys of the quick connection?

C

So if you see a basic, quick connection, you'll see an initial packet that carries the client hello, which is the first tls pack. Then you will see a series of udp packets coming from the server carrying the server hello in tls and then kind of all the tls extensions.

C

There will be using a basic encryption key, which is really just for a qualification of the packet for the initial packets that are not really not encrypted, and then the encryption key derived from the client, hello and server hello for the nchec packets, which carries all the tls extensions.

C

In particular, they carry the certificates, and so we have all the properties there of tls 1.3. Once the client.

D

C

That he gets the uh what we call the one rtt key, which are basically the data encryption key for the data session. So the client sends an unchecked confirmation and then sends a one rtt packet, which is the which carries the dns query.

C

B

E

C

There, because a quick as a feature called market coalescing and does this tls packet and the data packet are sent in the same udp data.

C

After that, while you get the response from the server which will carry also a bunch of ancillary things like the handshake done and indication recession ticket, maybe an acknowledgement and the dns response- and you will get a one entity acknowledgement coming back and the station will then be ready so that if there is another another query, it can be sent immediately on the query and it will repeat what we've seen where we sent and the response is received.

C

C

Okay, I get feedback on jabber that I'm not clear.

F

C

Can I I'll try to speak more slowly, see what that means. So if you see this first connection.

C

We have one rtt overhead to set up the tls connection and exchange the encryption key and then all the dns queries and response are basically one datagram art on datacom response coming back and maybe an acknowledgement after that there are all kinds of optimization in quick so that basically acknowledgement can be carried in data packet, etc.

C

C

Is so one thing we specify in the draft is the handling of connection and the ending of connection relies heavily on the fact that you can resume connection very quickly with quick.

C

So we don't have the same kind of penalty that we have in tcp to have to reset the connection, and- and we start everything again in quick, because you have this zero rtt series.

C

What you can do is that if the connection has been idle for some time and the vc doesn't know whether the the server has dropped, the connection or not recursive can simply start a new connection and it could use the rtt to send the dns query together with the tls request and the server similarly could send the pls responses and coalesce with that the dns response.

C

So basically, what we say is that if we restart the connection by opposition to starting the connection from zero, the response can come immediately without waiting with an additional delay and that's very useful for connection handling, because that means that servers can have a pool of connections. But they don't have to have that pool be very large. I mean the servers and.

E

C

Can drop a connection of say something like 20 seconds and there are very little penalty doing that because it doesn't impede. I mean it doesn't create new delays for the connection.

C

Next slide, please.

C

What happens in either case when you have additional queries, I mean additional queries can be sent at any time by the client.

C

There is a mechanism in quick to exercise flow control, so if the server wants to it can limit the number of queries that the client can send on a connection and and do flow control to limit that, but I'm not showing that here and basically, I'm seeing here a client sending two queries in two separate streams: stream, 4 on stream 8 and the server sending back responses in stream, 8 and stream 4. This illustrate the fact that the response don't have to be sent in order if the response were ready.

C

At the same time, they could fly in the same udp packet, so that was basically a set of ladder diagrams to explain how that works. Next slide.

C

Please now the question is: why do we want to have this dns of a quick specification, and I show here how dns of a quake differs from dns or tls and from dns over hdb3.

C

The dns of http 3 is effectively the same specification as dns about gtp2.

C

There is no radical difference, so what works with a dns or http 2 will works in the same way with dns of http 3 and using quick instead of tcp and tls.

C

There is a lot of similarity between dns over quick and dns over http 3., the main difference being that we don't have the http 3 layer and so on one hand for the nf of hgv3 that gives to dns or http an integration with the web, but it also brings all the web implementation into the protocol which, at the minimum increase the complexity, is about. Quick does not need.

E

C

Net layer and doesn't have a dependency on the http platform, which makes it a more compact implementation.

C

The advantage over dns over this, our tls is that we use quick instead of tls and tcp. So we have all these benefits of having one rtt establishment or zero rtt work, which is very easy.

C

We often hear discussion about whether these solutions can cross firewalls or not. Well, in truth, any of those could cross the firewalls if you mix it with encrypted sni and or accurate client hello that are being defined in the ts working group.

C

So I'm I'm not going to dive into firewall over solder and pretty much the end of my presentation next slide. Please.

C

C

We started working on this, as I said a couple of years ago, and the reason with the progress is that the quick transport was very much in flux two years ago.

C

It is pretty much ready now the spec is largely frozen. Most of the changes that we see are clarification on the specification. Basically final touches.

C

There are more than 16 interpreting implementations of the quick transport and there are, inter events scheduled regularly.

C

So that means that the quick transport is now stable and we can work on a protocol on top of quick outside of the quick working dns over quick does not require changes in quick, at least in the quick transport.

C

It defines a new implementation and there is no requirement on the quick working group, except to after spec as it is.

C

There is some work to do in deep five, specifically on connection management on the details of the dns packet mapping, things like what to do with edns what to do with packet size. What to do with packet. Ids specification in the draft we'll get a better specification with the next version, because we got some feedback.

C

There is also a point about using zero rtt. As I said, zerot is great for performance, but we have to mitigate privacy issues and the security issues in event with zero rtt. So we'll work on that and we have a presentation letter on 0tt, so we'll listen to that too, but basically.

E

C

Take is that at that point the draft is in sufficiently good shape and the quick transport is sufficiently stable, that we can start working on that in the deep water and my question in the next slide.

C

Is should the working group adopt that as a work item and I'll stop and listen for questions.

G

Thanks christian um first one in the in the queue is, uh is ecker.

D

Hi erica um yeah, I'm sort of neutral on adopting this. um I I, I think, you're making an incredibly persuasive case for why we don't just do d dns or http 3, but, like I'm not going to lie down the root over it. um uh I have two sort of technical comments. um uh You said this um needs uh um uh is his own port. um I certainly see why it needs his own port as opposed to um port 53.

D

But it's not clear to me why can't running on on um on udp 443, because the lpm lets you debunk those um and um you know generally, I think they.

D

You know it opens a much more effective mechanism than port numbers um uh and secondly, on this um on this question about um uh uh esni um uh um echo and alpn filtering, um you know, while a huge fan of echo, um I think it's quite probable that a large number of um of uh environments will basically ban echo and we'll do that by suppressing um uh by suppressing the dns queries.

D

You need to retrieve an echo, and um so, in those cases on uh doe three will look at the file much better than on the queue. Thank you.

C

Thank you uh well, what you say is correct. I.

H

C

We are in the business of uh designing the best viral travel source. Then addition is not what you want to do at the same time. What you said about dns over quick could just as well be said about dns about tls. It's exactly the same reasoning. I agree, and so I mean I, I don't think there is there's a new debate here. It's it's a it's an issue on one hand using a ddt ticket port, make it easier for network managers to see what's happening.

C

On the other hand, running overport, 443 and running as much like http as you want, makes it easier to sneak out from a network that might be somewhat of style. So yeah I mean there are two designs and I will just leave it at that.

G

Okay, next up uh jim reed.

I

Thanks guys, uh christian, I think this is a good idea and I support working with adoption. I'm just curious draft mentions that the dns must be set to zero. You can't explain the rationale for that. It doesn't seem sensible to you thanks.

C

Well, the rational is that you have to be clear what you are de-mixing on. So if you are de-mixing on the screen on the stream number, you don't want to be also de-mixing on the query id and and making the query id 0 makes that crystal clear.

C

Otherwise, you get an initial layer. I mean you get an actual layer of complexity either way, but 0 appears simpler. Now, there's a kind of stuff that we can definitely discuss in the working group and changing the draft in a later version. If there is consists in the working.

F

Group all right uh next up is uh ben schwartz, hi ben schwartz here um to jim's point I'll, just mention that dough uh does the same thing says the query id to zero.

F

I wanted to say something somewhat similar to what ecker said, uh but also a little different. I think that echo does not apply at least as currently specified to dns transports, because uh dns transports uh are the thing that you use to get your dns queries, but echo requires you to be able to perform a dns query before you can use it.

F

So uh if, especially, if use cases that don't have a bootstrap resolver are in scope, for example, cases where I say: okay, here's my dns over quick server and here's its uh the name that you should validate and here's the ip address. Then uh you should uh you can connect directly, but you can't do echo uh overall. My my thought on this is that this all seems like it will absolutely work and has some very small performance advantage over dns over https.

F

I think for client use cases. It's not really very interesting for client recursive. I think it's potentially much more interesting for recursive to authoritative, where the performance differences might be more.

C

Meaningful well, yes- and uh it's indeed I mean when I was looking at that my personal inclination was to design it for the recursive to automatic case. But, as I said, we can only do that after we have solved the discovery issues.

F

I'm done, I don't hear any response.

C

Ben, do you hear me now.

C

We can hear your question okay, so so I think ben is correct. I mean uh first on the um esni eco point. I I don't want to handle the use of esi.

A

C

Viral torso issues in this draft. I think that that belongs to deployment considerations and they.

C

For the recursive case, I do agree with ben that dns of earthquake make a lot of sense for the recursive authoritative case, because first we don't have to fire all problems in any case.

C

Second, it makes a lot of sense to have a lightweight protocol in that environment, if only because a lightweight protocol has a much smaller attack surface, which is a consideration, that's what motivates me most, but then we have to get experience and it's much easier to get experience in the uh in this top to recursive mode, because you can always configure the stub to use exactly this recursive with that protocol.

C

So that's the reason we.

E

C

With the stub I agree with, then we will have to work on the recursive auto scenario. Just do that later.

G

Okay and ted hardy.

J

Thanks this is ted hardy speaking uh first, I'm strongly in favor of supporting uh adoption. I think that uh this is a a very good use of of quick, and I think that uh it will get um uh deployment and some of the use cases that we're currently seeing uh dns for uh tls or dns or gtls suggested um because it has the head of one locking avoidance, uh that uh christian outlined, uh which I think is, is a very useful uh performance improvement over dta dot, org dtls.

J

I also agree with christian uh that there there is an advantage here for an eventual um recursive to authoritative, especially with zero rtt.

J

um The ability to to go back to an authoritative and get fresh data is is clearly going to be uh very useful, but I think the head-of-line blocking problem in the study to recursive is is actually one that this will improve a good bit um simply because you'll you'll end up in situations where you get a resource say a web page, and you want to do all the dns lookups in it at once.

J

But I think uh quick is a very useful uh way of approaching that I I understand people may want to do doh over quick as well.

J

um I don't think that that's uh something that this group needs to to take up or block it's already sort of handled by the fact that two different versions of http are available, um but I do think that the the caching semantics are are significantly similar, uh simpler sorry uh in this, and I I personally think that that means uh we should take out the work and and then have the discussions of things like what port numbers are et cetera in the working.

G

Group all right, thanks ted.

K

G

And christian uh so tim and I are going to take an action item to actually start a work group. uh Adoption call for this, so that you should see that on the mailing list in the next day or so so, please, chime in on your support or objections to to us taking this work on.

G

If there are no other questions, we're going to move on to alessandro and the early data over tls.

L

Oh hello, can you hear me okay, good, um so hello, I'm alessandro, I'm gonna give a quick update on the using early data and dns overkill as dropped next slide. Please.

L

uh Yeah so a quick recap: first tls 1.3 introduced a feature called zrt session resumption, which allows a client to send application data. In the first round trip of the n check this data being called early data, it can be used by dns the last clients to send dns queries to uh dns over tls server, without having to wait for the handshake to complete, and it can be useful in cases where maintaining a long-lived connection to a dns server is not feasible.

L

For example, a mobile clients connected to unstable network, uh the tls connection to a server might need to be re-established, often or in the case of uh resolver, to authoritative server. um The resolver might decide to drop some connections um that are maybe not used often and then using the rtt. They can reduce the cost of having to re-establish the connection uh next slide.

L

There are some caveats to the use of zeratity and early data, uh most notably the fact that early data can be intercepted by onpath attackers, and it can be replayed by said attackers to the server. So if the early data as uh causes side effects to the tls and dns server, an attacker might be able to exploit this by replaying data to the server multiple times.

L

For this reason, um application protocols that want to use zero, rtt and early data need to define a policy for when it is safe to do so, and that's what this document is trying to do next slide. Please.

L

So the drop was originally presented at itf 105 and it already went through a couple of rounds of discussion on the mailing list. So I'm going to present some of the changes that came out of those next slides.

L

One of the main complaints from reviewers was that the language around which dns messages should be allowed in early data and which should not be allowed, was not um was not very clear and it could be improved. So, for example, the original drop said something like dns updates and zone transfer. Messages cannot be sent over early data.

L

The new version of the draft weber says that only dns messages with a query opcode are allowed, so that also um removes other ed cases and other cases that were not previously considered.

L

In addition to that, uh the new dropped version also defines a white list of rr types that can be used within query messages within early data.

L

The the white list is defined as a an ayanna registry, so it can be expanded later on. um However, the list is not complete, uh there's a lot of our types that are currently defined and I do not know what most of them do. So I only added a few entries to the list, but if the draft ends up being adopted, we will need to discuss which additional error types need to be added to the list, and then there were a bunch of other editorial changes to clarify language that reviewers reported next slide. Please.

L

So, uh having said that, um I'm not a hundred percent sure we actually need the rr type uh white list, and um it might be that only a restricting on the query. Opcode is enough to uh achieve the goal here, which is only allow dns messages that are idempotent um again. I don't know what a lot of the r types defined do, so this might use some input from people with more dns experience and then, if we decide that the list needs to remain, we will need to discuss which are our types to add.

L

L

So I guess the question now is whether the working group is interested in this work and whether it should be adopted uh any questions.

G

All right, it looks like we have a uh alumni benz here so uh first in the queue is that course.

F

I support adoption and I don't think we need a list.

G

And ben must be invoked. Thrice cadet.

M

This is ben k duck. I had a couple points. One is that I think that having the white list is basically what we had in mind when we were writing. 84 46 and I know ecker's on the call.

M

So you can disagree if he wants to, um but I think that it's reasonable to have the white list both for the query, opcode and the specific r types, even if we end up allowing most of the error types uh and then my second point was regarding the description of the xero tt data requests as meaning to be item potent. I think it's actually a little bit stronger condition than that. Because item potent we usually think of as just sort of relating to the same query, being reordered or reapplied with itself.

M

But I think we actually need a stronger criterion that the query has the same results and the same side effect when reordered with other queries. That might be happening or other events that might be happening on the server, which doesn't necessarily seem like a problem off the top of my head. But I just wanted to point out that it is a stronger condition. We have to consider.

L

Okay, yeah, that makes sense, I'm not quite sure what the language in the draft is right now, um so if it needs to be clarified, I'm happy to do that.

M

L

M

Be clarified a little bit.

L

G

And a question from christian.

C

Yes, well, it's it's interesting to ask, but uh I think that it misses one of the points that dkg has been making about replaying of zero rtt. The problem of replaying. The rtt is that if a client sends a request in zero rtt, an adversary can copy that and repeat it and look at the side effects of that request at the server, for example, does the request triggers a query from the server to a specific name server on the other side?

C

And I I am not sure I didn't see that in alessandro's presentation I didn't see this uh issue of side effects and how side effects can be privacy leaks. I think that should be discussed and the best way would be to go to dkg's original analysis and incorporate it.

C

Apart from that. Yes, I do support encryption, because that's what I suggested is exactly the kind of thing that we should do in the working group.

L

Right so to to the point of dkg's analysis, uh the draft already includes uh some security considerations around uh at least one specific attack that was identified in a discussion from I think was a year ago or a couple years ago, from the discussion with the dkg, and um it might be that we also need to add something around, for example, caching, uh but yeah. I I'm happy to to add some language there or accept pr's to to add that.

G

Thanks alessandra, um you know much like the the first draft tim and I are going to craft a call for adoption and we encourage everyone to voice their opinion of support or disagreement with taking on this kind of work. So right before we move on to our third presentation from daniel. I just want to encourage everybody who has not signed a blue sheet to go to the ether pad and sign the blue sheet.

G

So next is going to be daniel.

N

Hi, can you hear me we can hear you okay good, so this presentation is going to be about signaling, resolver's, filtering policies. So next slide.

N

So the motivation for um these mechanisms is that um currently filtering policies implemented by the resolver seems an important things to know in order to proceed to a potential selection of a resolver.

N

Currently filtering is a is clearly associated to parental control and uh it's being performed through a cannery domain, and so the main motivation for this presentation and document is to have a standard mechanism so that we can have an explicit announcement from um from a resolver to a client to say the filtering policy, I'm implementing, as well as a standardized mechanism for a client to request a resolver which are the filtering policies and posts next slide.

N

So because either the resolver should be able to inform the dns client and the dns client should be able to request a resolver. We get two kind of different mechanisms, so one that's where the resolver can inform the dns client and another one when the dns client in relation with the resolver can request, which are the filtering policy put in place next slide.

N

So communications between a dns, client and a resolver have already some history and um in our case we are largely inspired by um the communication of a trust anchor. So it's somehow different, so we're using an ed and s0, as well as a specific dns square. Next slide.

N

N

um So how do we represent the filtering policies? So in this case we represent them through a datagram that we designated the data and the resolver is advertising the filtering policy by carrying this data through an edna zero record and when the client is willing to request to that resolver.

N

um This data is going to be carried through, um going to be associated to a special special fqdn next slide.

N

So here is basically how the data is um is built. So it's it's built. We basically defined some um some filtering categories and the full filtering policies is an aggregation of those filtering policies which assumes that in this case it's um an addition of all of those um I mean the the names, so the names of the filtering policies are not, um I mean, have to be standard defined through the aina. Only provided.

N

Some examples, of course we can increase those, but the idea is to remain quite simple and not to have billions of combinations next slide.

N

So when you advertise those, I mean this data is being carried through um edna series options next slide and when the dns resolver wants to actually check um which policies are being enforced by the resolver, so he sends a specific request.

N

So what is important is that queue type is set to null and the filtering policy and the queue name is set to underscore filteringpolicies.example.com, where example.com is the domain name, so the fqdn of the resolver.

N

So in some cases the application is may only know the ip address, in which case a reverse resolution might be needed to derive the domain next line.

N

N

There are some.

B

N

Some point of discussions- probably so um I mean that's worth being mentioned- um edna zero is- is not protected via dns sec, so it might be considered. So when the server is advertising the filtering policies- and in this case using this mechanism, we will not be able to protect that um using the nsx.

N

Why, when the client is um requesting that um dnse can be used- and there is also the case of when I have a resolver that is depending on different upstream resolvers, so probably all these filtering policies should be aggregated and it to the dns client.

N

Other things is that such mechanisms might assume that we have one policy per fqdn, so per resolver, which is a little bit different from a situation where different policies are made available by one resolver to a dns client. So um this is one aspect of it and maybe an another consideration. Is that whether we should support different characteristics of the filtering policies, or should we only advertise?

N

We, we are filtering, it's a binary, boolean values, first or not so well, I leave the floor open to any suggestions.

N

G

Looks like we got a couple of questions. uh First up is.

O

Alex um thanks for the presentation, um I think it's it's actually an interesting idea. um I see actually two problems with that. One thing is with the with the table of the possible filtering descriptions. I mean illegal uh caused me to cringe a little bit, because illegal depends on the on the jurisdiction.

O

Is that the jurisdiction of the server is that the jurisdiction of the client so there's all kind of uh complications to that to the very table. So I think that table is really opening the can of worms. I I don't have a suggestion how to improve that, though, um so I think the question is also. Do we want to have a really specific indication of which what what each category means or do we have like a rough indication of what category is the name server is attacking and the second one is.

O

um I don't really like the solution with the with the queue name of using the domain name of the resolver.

O

So I don't have a solution to that at the moment, but um I don't think it's very elegant, particularly because of the reverse, resolving of the resolver name, and then you need to identify what is actually the domain name of the resolver. Do we want to apply the the public suffix list to that name? After we have reversed, look up, looked looked up and so on and forth. So so these are the two uh things that I think we need more work on.

N

Okay, so um well, thank you for the suggestion.

N

um Yes, so I I agree with you that um if we have to define some categories, we might go into um unnecessary debates um so yeah, so that this is actually something I'd like to and to to know um whether people are more in favor of having um some of those categories or none of those we may simply add filtering is present, I'm funny the ways.

F

N

So that's um it's um some something that um needs to be discussed and um agreed. um I don't have a strong feeling going into one or the other directions um either also, um regarding the other one.

N

Having a special domain name, so what I came to also is, um if only the problem could is, um is due to the reverse resolution. um We could also agree, maybe on um on a very special name, um like we have um unspecified name like a home.harper that are not valid outside the home network, so we could have maybe uh similar names that won't be um valid outside the end resolver.

N

So maybe we can come with those things, but so what I don't know is that is that the pro problem due to the reverse resolution- or um you don't want this to be addressed through a dns exchange.

O

Quick response: no, I think it's okay to address this to us through dns exchange the filtering policies itself, but I think that the the the discovery of the domain of the resolver is an is a step. That's not necessary anywhere else. So if we can come up with some.

O

Old name or whatever, um okay.

C

Then that would be preferred because.

O

I think it needs to be. The client needs to do this once just because to discover the filtering policies, which would be much easier if we could agree on like an ayana registered name for that, and that opens up another kind of forms, but that's a different story.

N

Okay, yeah. Okay, so I see your point. um Another thing that was also being mentioned is that um if we have a service I mean a resolver discovery protocol. It's also something you could learn uh this way. For example, if you using uh svcb record, you could have that as an a key, a key parameter, a key value that specified those data also, so that's um another way to to discover that which is complementary to the mechanism described here. I think so. Thank you. Maybe we can go next unless you have something to add.

G

Thank you all right. Next, in the queue is uh erica scorla.

D

Hi hi daniel, um so uh I guess my question is: um do you know of anyone who wants to consume this information in this form? Do you know, do you know, do you do you know any client which wants to consume this information.

N

So one of those client could be um the client using the um the canary domain.

D

Yeah so yeah, I guess my question is: if you talk to anybody who's, doing one of the canary domains um and wants to do this so.

N

The the people I talked to were the people setting the canary domains- I I understand, but but.

D

But that the relevant question is, who would wish like is he wish? Is the people who are who are looking at the canary domain want to look at it? This way.

N

Yeah, that's uh so that's why I'm waiting for your comment. Oh.

D

Okay yeah, um so I mean so. It seems to me that there are two things that make this proposal not like super awesome. For me, um the first is that um having it stuffed in like easy and s0 means that I have to go figure out whether like the operating system, resolver will. Let me get this information and the nice thing about the canary domain, or something like it is that I can like guarantee.

D

Do it with, like the queries that I can actually make out of the operating system, resolver for basically any operating system, and that's like a pretty hard requirement, because if on my my own resolver pretty much, it has to be the case that, if you can't like get this information by doing like get adder or some other thing, that every other system has it's like kind of a nonstartup for me. um The second is that um this sort of detailed information about what kind of filtering policy um seems to create like a lot of confusion.

D

Ambiguity doesn't actually help me very much, because um the only thing I'm really interested in um and.

D

Is their policy enforcement on this resolver or not um because, like it's just too hard to explain to the user? Well, here is like some like kind of. Maybe you set up for policies which you have to like um you know. Somehow maybe you want this. Maybe you don't.

N

Okay, so um let me rephrase that so I mean um I I heard some cut during the response. So um you don't do you don't think have um filtering policies is a good thing. It's more confusing than anything else.

D

Yeah, I just don't know what.

N

I'm going to tell the user.

D

N

Bear in mind bear in.

D

Mind that, like what firefox does now when it says they can hear to me, it's just silently disabled, um you know, we've talked about having it be. um Like you know, we've been told to disable dough, because we you we disable like flagging into the user, but, like I just don't think we've liked the user. It's been. It's been flagged because of like these three different filtering policies but defensively your network enforces.

N

Okay, um that's fine, and um the other point is that um edna zero is that I mean you, you don't like, because, because of middle blocks that could strip the daniel zero.

D

No, um I is, will the operating system um resolver interface? Let me get it okay like basically. Basically I understand that, like firefox does not have its own doe 53 resolver, um it just uses the um it just uses the uh uh um you know the operating system resolver, um I think chrome- has his own deal, 53 resolver, um but not everybody does, and so um in that case you want, you want to be able to do something. You can do an operating system call rather than rather than be something you have to say.

D

You can't- and I don't my impression is this date is not available to me on every operating system or in fact, maybe any operating.

N

N

Okay right, so, if, if um at least on one operating system, if you can't have access to data information, it's um I mean um you, you won't be able to use that. So that's correct, um in which case you I mean so. Would you suggest that we only focus on a client requesting and not the ed nets options.

D

Yeah, I think, as I said, I think people can have access to right. I think I I guess I would want to do one thing not several and um and so I'm going to want to do things. Others say that I can get the existing operating system apps.

N

So, basically limit the scope to only having this dns exchange, not with the option.

D

As I say, the requirement is that it has to work with like get adder. You know get you know the existing os apis. That's the underlying requirement.

N

Okay, thank you, yeah, um I'm fine to implement. um I mean to update the document with um your inputs. um Well yeah, so yeah, I'm fine with that. I mean it makes sense to me.

G

Okay, next in the key is chris box.

H

Hello, yes, chris, um so I can see that the idea of learning filtering policies is useful.

H

So right now we have cloudflare offering specific ip addresses for different filtering sets, so one one one two for malware 1113 for the combination of malware with parental filtering.

H

So when I work into a hotel and connect to the wi-fi, it may be useful to learn what's happening in that resolver. So my question is: could you clarify how you see this relating to add? Because I think you said it was complementary and, to my mind, add is charged with solving the problem of how you discover which results are available and and selecting from them and as part of the selection process. You might want to learn these filtering policies.

H

How do you see that sitting so.

N

Yeah, it's um it's a it's a good question. um I think at that point, um so I mean the same information could be disclosed through um a specific discovery. Protocol.

N

N

It might not be available through that way, and so, if you're connected to one server, you want to to know um whether this uh I mean.

N

It's a it's a different way to discover that I would tend to say, but um I mean suppose we have a lot of different.

N

Things to to discover we, we won't be able to add those all those all those keys to um svc svcb record, for example.

N

So, if you're connected to one resolver- and you want maybe specifically know what whether is implementing some filtering- if this resolver is not implementing the service discovery, the resolver discovery protocol, so that's. um This is why I would mention that as complementary.

H

Okay, thank you.

G

All right uh next in the queue is victoria.

K

Okay, well, personally, I think I'd find something like this useful, but I agree with ricker I mean in the end, this is useful only if there are clients that want to implement it. So I think that that's the first thing we should understand and same for the level of detail in.

K

It will to be more newest than that than what you have now, but then I too complex for basically being useful. So perhaps this should be done in two steps. So, first maybe we should agree on the functional requirements so which kind of information we need to communicate and then start by shedding on how do you fit this data into a dns communication?

K

And finally I mean I also had this this issue about. Where does this fit better? If it's more like idd draft, I mean, I know that there's another draft there. That already does something like this. I think- and this looks more like I mean fit in the second point in the led chart, so I don't have any strong view and fine with whatever, but at least we should make sure that all the work related to these kind of things goes into a specific working group.

N

Okay, so um yeah so I mean depending.

N

So I I well given all the feedback. I I think everyone agrees that um we should not have a detailed uh filtering policy so that my first um conclusion of all the things that come I've received um and I'm fine with that now um related. To the I mean the relations between add, I mean this work, I mean if this work could have been hosted in add um I agree it could have been host.

N

I mean on my point of view it could have been hosted, but uh um we discussed with the chair and um the add chair said um deprived is more appropriate for that.

N

So that's what the reason is in deprived now anything I was mentioning.

N

Could it be discovered through a discovery protocol provided in add my answer is yes, we can still have a svc key parameters, saying um filtering true or not, and that could be advertised, but um so it's a different way to advertise a parameter um outside a service discovery protocol.

N

um So so yeah, that's uh what uh I meant and.

N

I

N

um I don't think it's a conflictual at that point, um but um it's um yeah. We should not have a overlaps or if we think it's a conflictual.

G

Okay, next in schwartz.

F

Hi, this is ben schwartz, uh so yeah. I I agree with some previous commenters that this kind of work should not be in deprived. This is not a privacy enhancement for dns.

F

uh It also clearly overlaps with some work, that's ongoing in add, and uh you know, if it, if it wasn't included there, then maybe that reflects a lack of space in add for additional work, and maybe this needs to be combined with the existing proposals on this topic.

F

Another reason that I think we need to be combining it is because I do not want us to end up with a separate discovery mechanism for every aspect of metadata about the user's resolver resolution path. We need a unified metadata scheme, so we can't invent uh information, discovery mechanisms for each piece of information, we'd like to learn. We need a general information, discovery mechanism and, lastly, on the particular kind of information that is proposed to be discovered here.

F

I want to point out that, in my view, this is an evil bit, which is to say that it is a a claim made by one party in the protocol that the other party is somehow being expected to use but cannot verify, and that actually makes it very different from the canary domain, where the thing that the client checks is uh it measures a behavior of its resolver and so in effect, it verifies the property that it is attempting to measure.

N

So um the first comment.

B

N

Whether it should be only well, I understand that the first comment is that we should not have a specific discovery mechanisms outside the resolver discovery mechanisms. um So I don't know if it's. um If it's it's a valid comment, um if people agree this way, I'm fine with that.

N

It's not obvious that every everyone is going to configure and to adhere to the discovery mechanisms. Also, so that's the thing I'd like to nuance, and this is a something that could be immediately actionable. um It could um I mean- and we have all the things um like for exa if you want to know which um um ksk is being used by the resolver.

N

Is that something that should be discovered by the dns client, or should it be advertised to um generate resolver discovery protocol? So I'm not sure that I I do somehow share your point, but uh I'm not sure it's um we could. We can have a single mechanism for um everything so.

F

In case that wasn't clear, this is ben schwartz. I just want to clarify that. I'm not saying that this all needs to be rolled into the mechanism by which you learn of the existence of a resolver, but rather that all of the metadata about a resolver that you might want to know should be discovered through a single mechanism other or at least a unified framework. Otherwise we end up with a a novel metadata discovery mechanism for every piece of metadata that we intend to learn.

N

Okay, so just to clarify um you would like um underscore metadata so that we got all of those data meter instead of having underscore metadata one underscore metadata two and so on.

F

Yeah so in particular, the dns op working group already has an adopted draft called the resolver info, uh rr type res info, which proposes a unified framework for learning metadata about a resolver.

F

I don't know that that draft is the final uh perfect answer to this problem, but that's the architecture that I think we should be aiming for.

N

Yeah yeah, okay,.

I

N

um Yeah correct.

H

N

I, if you could point this exact draft, it would be helpful, but um this is also something uh I thought that that if we defined something it could be extended to, it should not be only about um filtering um services which could be extended to other future.

N

Functionalities, so I agree with that now I I think you mentioned that um you you wanted this to be part of add instead of this uh deprived.

N

I I mean to me: I'm I I don't care which working group it is. um It has been decided, it has been deprived. I mean it was mostly the add chairs that uh prefer this to be hosted by deprived. So I mean for me, I'm equal regarding the whether it's being hosted.

P

Okay, this is eric wink here. The responsible ad for the group.

L

P

Also believe that this document is not really fitting the price charter.

N

N

It's um I can, um but so well. The thing is um what I'd like to clarify.

N

Is um I'm fine sending that to add, but um I mean do we think it has no places no working group or do we think add, is the right place.

G

So daniel, I think the uh the right answer here is, is, I think, first of all to go off and uh and maybe take a look at what that dns opt resolver info draft says and whether or not you could actually incorporate the information that you have in your document into that framework.

G

And then I think once once that is figured out, then we can. We can talk between the the worker, chairs and and the area directors to see where it actually makes sense to do the work.

B

Brian, this is barry liba responsible ad for add, um remember the add, has a very tight tightly scoped charter right now and that I've, given the I've, asked that the chairs to be very selective about what they accept to start off small. It may be daniel that what you're proposing makes sense to go into add later, and it may just make sense that right now we need to hold off, but ryan's suggestion is the way to approach it right now.

A

And daniel this is tim. I put the link to the resolver info draft in the webex chat and um there's. I agree with one thing.

A

Ben said that I think we really need to take forward is we need a common framework, a unifying metadata framework, and I think that you know a lot of the the drafts that I see like this are very interesting, but they all have their own way of sort of solving the same problem and- and I think pune and paul have a draft that um if you take a look at it, hopefully can fit. You know what you're doing or maybe it can be extended right.

A

The whole goal that one is to make something you can you know, put your own metadata into so yeah yeah.

N

A

Better totally encourage everybody to take a look at that yeah thanks.

N

Thank you all right. So, let's.

G

Move on to the cue uh eric klein is.

C

C

G

G

All right we'll see if he can circle back around um next up, is uh benno all right. Query.

E

From the jabber room uh question, uh so one of the questions was already answered in the previous discussion, so one still open is: why do you use of? Can you use also a bit mask instead of a single number for the filtering policies?

E

N

Yeah so well, if we remove the filtering policies, um we don't have to think.

N

Otherwise, how to do that, but um yeah, I agree it could have been implemented with a bit mask thanks.

G

uh And next on, the list is jim reed.

I

Because I think that's also very well made and my question to you daniel, is: why did you choose to go from a dns option rather than a dedicated resource circuit type? Would that not be a better option all around assuming this needs to move forward? Maybe that results I could type might be the best info thing.

N

So um the question to why did I use uh the edna zero? um It's um well? It was mostly because I I saw that a lot of information um were provided through edna zero option. um It's not that I'm! I was not open to any other things. I I thought that I mean we had already experienced in that field, so um I wanted to benefit from this experience, but um I'm happy to to take other means more appropriate.

I

G

Okay, so I think that's it for this queue um and um oh, is eric back.

Q

uh Perhaps does this work.

G

Q

ah Okay, thank you. I apologize, I seems like webex told me, I was unmuted, but then it also did not tell me that I could not find a mic, so I was both unmuted and mikeless.

Q

I think um most of uh the things I wanted to say others said more eloquently.

Q

uh I just wanted to also note that I I I'm a little skeptical of the ultimate usefulness of some of all of this, because I think we could easily end up in a lot of different scenarios, one of which is where all resolvers announce that they do filtering, because all resolvers and all clients are in some jurisdiction somewhere and just by virtue of being in a jurisdiction.

Q

You know all governments may have you know we may end up in a world where they're they're just illegal mindful of policies, and so it's not clear to me.

Q

Also things like you know: if somebody passes a law about uh their their their their filtering policies uh apply to their citizens wherever they travel throughout the world, then you need to know the citizenship of the person who's, making the query or who owns the device.

Q

uh I I I have some some some skepticism in this area.

N

So I do understand, um there are two things: some uh some filter I mean, and it's a it really depends what we want to advertise or the meeting the meaning of that bit or maybe value we want to advertise.

N

But it it's true that um legal enforcement force you to implement some kind of filtering and those depends to the generations. The resolver is, um but it's it's not the same type of filtering that we expect for when we subscribe to um filtering mechanisms based on anti-malware, deception, detection or filtering ideal content, um so yeah so.

Q

We have to be there, it's a voluntary filtering that the resolver is doing on its own, not as bad, it's, okay, so the the illegal that also, I guess, doesn't make sense. Then.

N

Q

Yeah yeah, but definitely by definition,.

N

That's what you're saying, but.

Q

The illegal bit is implied at all times.

N

So it's um yeah, it really depends what you I mean. What I meant meant by illegal is a content that are not that are illegal, but initial directions, but uh I mean the words behind them.

N

um I mean I, I I mostly wanted to express some different ways to do filtering and whether it might be useful to to have those different categories, um but um my understanding is that it it's not. It's not useful to go into the details. So um having a single bit saying we do filtering and in which case it's going to be filtering um being performed by the resolver. In addition to um what is jude prediction is uh asking to do.

Q

Interested thanks, thank you.

G

All right, thank you, daniel. um I think that wraps everything up for for this session. So even though I said we were, I thought we were going to end early. We are basically ending on time. The um the two call for adoptions are out on the mailing list, one for the dns over quick and one for the early data track.

G

So please voice your opinions there on on those two calls. uh One final reminder for everyone to go sign the blue sheet. uh The link is both in the jab arrow and in either in the um webex chat.

G

So without that, I think I want to wrap everything up thanks everybody for for joining us, and we will see you soon. Hopefully thank.

G