Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-02.txt
On Tue, Mar 10, 2020 at 2:54 PM Paul Vixie wrote: > httpssvc is not > an alternate service description permitting fallback to the > non-alternative; > httpssvc is the service description itself. > 7.2. Relationship to Alt-Svc Publishing a ServiceForm HTTPSSVC record in DNS is intended to be similar to transmitting an Alt-Svc field value over HTTPS, and receiving an HTTPSSVC record is intended to be similar to receiving that field value over HTTPS. no-one would use this for h3 if that were not the case. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-02.txt
alt-svc is quite robust to reachability failures of the alternative origins should some client find itself on a network that filters full transit. This process is already existing technology (rfc 7838). From that perspective the DNS record is just a way to bootstrap it over DNS rather than the default host/port for the URI. -Patrick On Tue, Mar 10, 2020 at 12:24 PM Paul Vixie wrote: > On Tuesday, 10 March 2020 13:30:53 UTC Patrick McManus wrote: > > another positive feature of ports in this record is that it provides some > > address space independent of the origin security model of the URI. By > this > > I mean that https://www.foo.com(implicit :443) and > https://www.foo.com:555 > > are different origins with different web security boundaries. While two > > different httpssvc records for 443 and 555 (both for https:// > www.foo.com) > > are in the same origin.. this level of indirection can be used for A/B > > testing or even for encoding load balancing information in a IP > constrained > > space. Just like the address is distinct from the URL, the port separates > > the 'what' from the 'how' and that's good. > > your reply above precisely demonstrates the risk offered by allowing a > service > operator to select a non-default port. please read my down-thread response > to > erik nygren and consider the non-reachability impacts of such selection on > far > edge managed private networks, who will only build NAT, AGM, or firewall > flow > state for permitted (in-policy) flows. > > there's a separate problem on retermination, but i'll address that in > quic-wg. > > -- > Paul > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-02.txt
another positive feature of ports in this record is that it provides some address space independent of the origin security model of the URI. By this I mean that https://www.foo.com(implicit :443) and https://www.foo.com:555 are different origins with different web security boundaries. While two different httpssvc records for 443 and 555 (both for https:// www.foo.com) are in the same origin.. this level of indirection can be used for A/B testing or even for encoding load balancing information in a IP constrained space. Just like the address is distinct from the URL, the port separates the 'what' from the 'how' and that's good. On Mon, Mar 9, 2020 at 10:42 PM Erik Nygren wrote: > On Mon, Mar 9, 2020 at 10:32 PM Paul Vixie wrote: > >> On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote: >> > It occurs to me that I hit "publish" on this draft without updating the >> > release notes, so I'll mention some of the many changes since -01 here >> > instead: >> > >> > ... >> > >> > As always, please review and send comments. We also expect to do a >> > presentation on this draft (remotely) in the DNSOP session. >> >> i propose that section 6.2 for "port", and all references to same, be >> removed. >> > > We discussed this some on one of our authors' calls following > my seeing you allude to this a few weeks ago. > > The rationale for keeping port is that HTTPS is not just about the "web" > use-case. > While for Web use-cases it is common for most things to always tcp/443, > there > are plenty of non-"Web" use-cases (such as API calls in data centers, > service meshes, etc.) > where non-standard ports are commonly used. I know that Tim keeps > highlighting > a desire to make sure we consider these use-cases. > > There's a default when port is left out (perhaps that should be clarified > better?) > but there are cases when being able to switch to an alternate port has > value. > Another case where this applies is QUIC/UDP where udp/443 is commonly > used but where operators may wish to situationally use different ports. > > Adding a warning that the use of non-default ports could have > operational challenges might be warranted. (There are also > some confused deputy risks around non-default ports for servers > that don't validate the port in the Host header, but others convinced > me that that's a problem for another day.) > > A closely related issue is this one: > > https://github.com/MikeBishop/dns-alt-svc/issues/111 > > (regarding clarifying the default port.) > > Does this help address the concern? > It's helpful to know the historical context. > >Erik > > > > > > >> this is: >> >> --- >> >> 6.2. "port" >> >>The "port" SvcParamKey defines the TCP or UDP port that should be >>used to contact this alternative service. >> >>The presentation format of the SvcParamValue is a numeric value >>between 0 and 65535 inclusive. Any other values (e.g. the empty >>value) are syntax errors. >> >>The wire format of the SvcParamValue is the corresponding 2 octet >>numeric value in network byte order. >> >> === >> >> in the SRV RR (from RFC 2782) we specified a port number as part of the >> RData >> because a client would otherwise have to have an up-to-date /etc/services >> file >> (or local equivalent) to know what (TCP) port number a listener would >> listen >> on, and this seemed archaic. >> >> for HTTPSSVC and SVCB, the service is a constant (HTTPS) and its >> transport >> layer port number (443) is known. inviting listener operators to specify >> a >> different port number will result in unpredictable (other than >> wide-spread) >> failures for those accessors behind NAT, firewalls, or ALG's. >> >> please leave out this legacy from DNS SRV as you go forward with HTTPSSVC. >> >> -- >> Paul >> >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] SVCB chain lengths
we should not limit the alias chain length across zones (other than for
loop protection which should be standardized) because there is no
administrative consistency across zones - its just a pointer. So the alias
you're pointing at now might become an alias itself later totally out of
your control.. or it might inconsistently do so thanks to
localized/balanced results you don't have any view into. Or, vice-versa,
someone might be pointing an alias at you when you do add an alias record
and you break them suddenly. You can say "don't point at an apex", but the
property of an apex isn't a constant one either - so someone adds a new
apex and breaks everyone that has an alias pointing at them. This is not
centrally coordinated so adding rules that need to be socially tracked
beyond the configuration you actually control is an un-necessarily fragile
system.
I also don't think a value of 1 achieves performance goals because when it
works it just replaces aliases with cnames and they perform the same. Plus,
it creates situations where it doesn't work - and that definitely performs
worse :)
As for use cases, I don't think there is any reason to think an apex wants
fewer redirections than non-apex. We all know that 0 is a real problem, and
that non-apex can have quite a few. redirections are a performance problem,
but substituting cname pointers for alias pointers doesn't improve that.
The loop protection text should indicate that the length of the chain is
inclusive of both kinds of indirections.
-P
On Mon, Dec 9, 2019 at 1:03 PM Ben Schwartz wrote:
> Changed title to reflect this thread's topic.
>
> I wanted to add some background on this question (which is also
> tracked on Github:
> https://github.com/MikeBishop/dns-alt-svc/issues/57).
>
> SVCB supports two forms, one of which ("AliasForm") acts somewhat like
> a CNAME, and in principle could be chained indefinitely. The current
> draft says
>
> > Chains of consecutive SVCB and CNAME records SHOULD be limited to (8?)
> prior to reaching terminal address records.
>
> This discussion is about finding a good replacement for this
> placeholder language. (IMHO the placeholder is also problematic
> because it arguably alters requirements for CNAME handling.)
>
> SVCB is fully "mixable" with CNAME, so there's no need to use SVCB's
> AliasForm when CNAME will do. CNAME chains are followed at every step
> of SVCB resolution. AliasForm's only significant* advantage is that
> it can be used at a zone apex.
>
> AliasForm also has a serious downside compared to CNAME: clients whose
> recursive resolver is not SVCB-aware will have to follow the alias
> themselves, resulting in significantly slower resolution than a CNAME.
> For this reason, domain owners should avoid using AliasForm if CNAME
> will suffice.
>
> If zone owners are testing/benchmarking with recursive resolvers that
> are SVCB-aware or have very low latency (as seems likely), they may
> not expect this penalty, and there is no way for them to detect or
> measure it after deployment. I have heard this called a "performance
> footgun". Hopefully this explains why some developers have asked to
> limit the use of AliasForm.
>
> Currently (pre-SVCB), the number of apex names that can be present in
> a chain is zero (excluding the final name). The question at hand is:
> should we increase this limit to 1? 2? 8? Unspecified? We have a
> clear use case for 1 (aliasing https://example.com/), but I have yet
> to hear of a use case that needs a limit higher than 1.
>
> There are also several other possible ways to discourage unnecessary
> uses of AliasForm. For example, we could:
> - make it possible for zone owners to tell whether their clients are
> using an SVCB-aware recursive, by making clients' alias chasing
> behavior different from recursives'
> - extend the W3C Resource Timing API (at the W3C) to indicate when
> multiple DNS queries were required
> - ask SVCB-aware recursives to SERVFAIL on AliasForm records that are
> not at an apex (excluding _prefixed labels)
>
> --Ben
>
> *For HTTPSSVC (but not SVCB), another difference is that CNAME would
> affect all protocols, whereas AliasForm only affects HTTP connections.
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 feedback
On Fri, Dec 6, 2019 at 5:45 PM Eric Orth wrote: > > >- Therefore, unless somebody comes up with a good reason that longer >chains need to be supported, we intend to only follow 1 or 2 links before > > > I'm sure you're not trying to undermine the standards process, but that's what happens as a side effect of statements like that. We're at an -01, let's discuss (as Brian does downthread) the reasoning behind design decisions and see if we can get to consensus on them without threatening to take the ball and go home already. If there is eventual consensus and you're in the rough and feel its bad for your product then the appropriate thing to do is not to implement a standard you don't believe in. but implementing a different protocol and calling it httpsssvc does nothing but lead to breakage and undermine the entire point of having a standards based definition. Maybe you mean you strongly believe this standard should allow at most 2 links? Brian has got a good point that these are pointers, and pointers don't know how long the list is and the parties in the list are not strongly coordinated (which is what makes a pointer powerful - its permissionless). This also complicates ESNI, but its a fact of life. Also, people trade latency off against indirection all of the time for reasons they think are valuable (that's true of DNS but also in general). It would be interesting to study the distribution of chain lengths, but I can say off the cuff that 3 is really common in web space and imo, this spec should be aligning itself with existing deployment strategies in order to make its own path to deployment as frictionless as possible. ;; ANSWER SECTION: download.microsoft.com. 1471 IN CNAME 2-01-4ca6-0004.cdx.cedexis.net. 2-01-4ca6-0004.cdx.cedexis.net. 19 IN CNAME main.dl.ms.akadns.net. main.dl.ms.akadns.net. 160 IN CNAME download.microsoft.com.edgekey.net. download.microsoft.com.edgekey.net. 12 IN CNAME e3673.dscg.akamaiedge.net. e3673.dscg.akamaiedge.net. 8 IN A 23.46.196.215 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error
extended codes are pretty important in the DoH space - which doesn't require library intermediaries. IIRC the very important use case was disambiguating DNSSEC validation errors from other errors (as retry behavior could very well be different). So this has been eagerly anticipated. On Tue, Oct 22, 2019 at 6:49 AM Tony Finch wrote: > Petr Špaček wrote: > > > > 2. Second problem is that it is uncelar if there is going to be a > > consumer: Did *anyone* from stub resolvers said a word about this draft? > > Is it useful as it is? > > I expect almost no-one can do anything with EDE without > getaddrinfo() EAI_ return code extensions. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > Plymouth: Variable 4 or less. Smooth or slight, occasionally moderate > later in > west. Mainly fair. Good.___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 9:58 AM Ray Bellis wrote: > > > On 25/03/2019 09:28, Ian Swett wrote: > > One way DoH may be faster than DoT in the near future is that DoH can go > > over HTTP/3 via QUIC and avoid head of line blocking like Do53. > > Head of line blocking shouldn't happen on a modern Do53 server. > > See RFC 7766 §6.2.1.1 > > I've seen this confusion before, so I can clear it up! Ray is (I believe) referring to the flexible re-ordering of DNS request-reply pairs of a TCP channel.. similar to HTTP/2 (though with less flexibility in granularity iirc). That addresses hol-blocking problems due to the time the server spends building replies. Ian is (I believe) referring to head of line blocking problems related to TCP's in-order delivery semantic and packet loss. TCP packet loss will delay the delivery of received packets if there are outstanding unreceived lower-numbered packets. If the data in these packets are unrelated (e.g. different DNS request/reply pairs) - that causes head of line blocking to the application. That's true of http/2 and RFC7766 (anything tcp based really). QUIC streams provide a mechanism for identifying which sequences actually need to have that dependency. DoH with H3 would use separate streams for separate requests (as different HTTP exchanges are inherently on different streams). Its a shame that the term hol blocking is used for both scenarios - it has caused a lot of confusion. hth -Patrick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson wrote: > > >> >> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do > not believe anyone has proposed explicit downgrade triggers. > that's the downgrade I am referring to > Or do you mean, when a DoT connection is blocked by e.g. a firewall (or > other network enforcement device), that an RST is generated? I believe the > RST requires sequence number validation before it can be processed by the > TCP stack, which means the entity doing the RST generally needs to be in > the data path. Other than "lucky guess" or "high volume attempts", I don't > believe RST to be a serious threat. > path manipulation attacks are real. arp attacks.. bootp attacks.. rouge access points. stingray. all kinds of things. unauthenticated network packets are just that: unauthenticated. RST (or blackhole) is a good indication that a path isn't going to work - its not a good indication of who is expressing that policy (or whether it is a policy at all). Anyhow - I'm really not trying to amp up this thread.. I just felt that there were a few relevant points to the discussion that had not been introduced. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft for consideration:
ts nice to have a thread where bike shedding of terms is actually on topic, and the point of the draft. On Mon, Mar 25, 2019 at 9:39 AM Vittorio Bertola wrote: > > > I don't know if these terms are already defined somewhere else, but the > distinction that I've found most useful in the DoH discussion is "local > resolver" (i.e. the one provided on/by the local network the user connects > to) vs "remote resolver" (i.e. any other resolver, requiring traffic to go > beyond the Internet access provider's network). Some of the issues happen, > and already happen today, as soon as the user adopts a remote resolver, > even with plain old DNS. > > I agree with you that this is the important logical distinction. My only quibble is that local and remote can have varied (and multiple) scopes - so its a little hard to apply the terms concretely. I'm thinking more along the lines of Access Network Resolver and Network Independent Resolver to capture the same idea. [I originally sent this note by accident to Vittoria without a cc to the list. Sorry Vittorio for the dup!] On Mon, Mar 25, 2019 at 9:39 AM Vittorio Bertola wrote: > > Il 24 marzo 2019 alle 7.42 Paul Hoffman ha > scritto: > > > > > > Greetings again. As y'all have seen over the past few weeks, the > discussion of where DNS resolution should happen and over what transports > has caused some people to use conflicting terms. As a possible solution to > the terminology problems, I am proposing a few abbreviations that people > can use in these discussions. The draft below, if adopted by the DNSOP WG, > would update RFC 8499 with a small set of abbreviations. > > I don't know if these terms are already defined somewhere else, but the > distinction that I've found most useful in the DoH discussion is "local > resolver" (i.e. the one provided on/by the local network the user connects > to) vs "remote resolver" (i.e. any other resolver, requiring traffic to go > beyond the Internet access provider's network). Some of the issues happen, > and already happen today, as soon as the user adopts a remote resolver, > even with plain old DNS. > > I agree that another set of problems derives instead from applications > using a resolver different than the one configured in the operating system, > which may or may not be the local resolver. So it's fine to define a couple > of terms like "DaT" and "DaO", though I don't really like these two > acronyms :-) In my draft I introduce the terms "network-level name > resolution", "application-level name resolution" and "application-level > resolver selection". They are not acronyms, but I think they would be more > understandable in a discussion than more and more acronyms. > > (I don't even like "Do53", I think "unencrypted DNS" or "plain DNS" is > just clearer.) > > Ciao, > -- > > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bert...@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
I'm not pushing against DoT per se in this thread, I am pushing against the
notion that a client has an obligation to the network to provide a clear
channel for traffic analysis and downgrade triggers.
One of the notions presented here is that unauthenticated RST injection
forgery is an acceptable, perhaps in the minds of some even desirable,
signal for DoT to trigger downgrades and, further, that clients are
obligated to create a clear signal to the network to enable this approach.
One issue is that you cannot differentiate this signal between a party you
may want to cooperate with (e.g. your enterprise controller) and an
attacker - that's the nature of an unauthenticated injection. But there are
authenticated enterprise configuration methods available for expressing
policy directly to the client in a trusted way. Indeed my post centered
around the notion of https interception being a necessary outcome of DoH in
the enterprise - my point is basically if you can do https interception
then you are doing enterprise config - consider a config to still do
secured DNS with a server that implements the enterprise policy rather than
doing interception.
And if you do that an enterprise client can, by using its own do{th}
server, also enjoy the benefits of transport security and be confident that
the policy server it intends to use is actually the one in use.
fwiw - there are lots of reasons an http client is going to be interested
in an http substrate beyond just traffic analysis defense. It has the
potential for better overall application responsiveness - by sharing
connections and handshakes with other http data. I don't think that
particular discussion is important to this thread.
On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson
wrote:
>
>
> Sent from my iPhone
>
> On Mar 24, 2019, at 10:42 PM, Patrick McManus
> wrote:
>
>
> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>> This is important for network operators in identifying encrypted DNS
>> traffic,
>>
>
> not all clients acknowledge a network's right to do such things at all
> times. And of course it would be useful to tell the difference between
> policy and a RST injection attack.
>
> If the client does acknowledge the network has the right to set policy -
> then the policy can be set on the client using existing configuration
> mechanisms that allow the client to differentiate between authorized
> configuration and perhaps less-authorized folks identifying their DNS
> traffic. This is well worn ground in the HTTP space.
>
>
> What I find interesting, is that as far as I can tell, everything you
> wrote applies equally to DoH and DoT, if the transport is the only
> difference. E.g. Same client browser, same DNS service, accessed via DoH or
> DoT.
>
> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>
> Brian
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson < brian.peter.dick...@gmail.com> wrote: > > This is important for network operators in identifying encrypted DNS > traffic, > not all clients acknowledge a network's right to do such things at all times. And of course it would be useful to tell the difference between policy and a RST injection attack. If the client does acknowledge the network has the right to set policy - then the policy can be set on the client using existing configuration mechanisms that allow the client to differentiate between authorized configuration and perhaps less-authorized folks identifying their DNS traffic. This is well worn ground in the HTTP space. > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
I want to add one thought to the general argument that goes along the lines of "I need to enforce a policy on my network, and doh will just encourage more https interception - we have gotten nowhere." This argument assumes a scenario where the network is trusted by the application and can require/achieve host or application configuration. Indeed - deploying trust anchors to these clients is the only way you're going to intercept https as the notion of network defined configuration of "trusted proxies" and the like is consistently rejected by clients. That seems like the right standard for DNS as well - go ahead and configure a different policy but do it via an existing authenticated configuration mechanism like you would use for adding a trust root. However, rather than adding a root I would suggest that if you're doing client configuration for network-local DNS policy, that you deploy a DoH server that enforces that policy and point DoH clients at it through the various enterprise config mechanisms. It doesn't require any kind of access that adding a trust root does not. This has the desirable property that the application can reliably know what server is providing DNS service in a fully authenticated way. Perhaps in a "my way or the highway" scenario it will choose the highway. That's fair enough - that should be a real choice. When you just intercept 8.8.8.8:53 an informed decision cannot be made. Use of non-default trust roots is also a property generally visible to applications. Most allow it as a matter of user configuration. -Patrick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] [EXTERNAL] Re: New I-D: draft-reid-doh-operator
On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister wrote: > > Don't overplay the privacy provided by DoH it has no effect on the DNS > provider The major effect of the transport security on the privacy practices of the provider is that it allows the client to authenticate the provider. Trust in their privacy practices needs to be establish some other way (and the best way we have right now is 'out of band' - hopefully that gets better) - but with DoH you can be confident that you're having a private conversation with the entity you've decided to trust. That's a pretty big distinction from port 53. Without that assurance its reasonable to be concerned about what names you lookup. This of course applies to local and enterprise configs as well as the cloud configs contemplated by most of this thread. An enterprise DoH server expresses and enforces a policy - if an application needs to use that policy it should be comforted in transport security providing confirmation that it is doing so rather than reading in whatever might be showing up on port 53. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Resolverless DNS Side Meeting in Montreal
Hi All - This is a wrap-up email for the Resolverless DNS meeting held on July 16 in Montreal. We had, by my rough count, about 50 people and two sets of minutes are attached. If you attended, contributed, or took minutes (Thanks Shane and Ben!) thank you - it was, imo, a productive, professional, and even pretty focused discussion. We identified a next step: using an AD sponsored list (See Below!), identify one minimal context or use case that provides value for using DNS information without direct recursive resolver contact, and enumerate the concerns and potential mitigations for those concerns. If we can focus on that and make some progress then we might have a proposal for a future BoF - if we cannot make progress then that is also telling. Adam and Warren have setup a list for us to use. I apologize to the various working group's cc'd on this so far (and thank them for their indulgence) - future communications should move to the new list. New List Info --- https://www.ietf.org/mailman/listinfo/resolverless-dns -Patrick On Mon, Jul 9, 2018 at 10:49 PM, Patrick McManus wrote: > Hi All, > > I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in > Montreal. > > We have often talked about the benefits and concerns of DNS information > obtained from sources that are, shall we say, less globally trusted than a > recursive a resolver. The central use case is DoH when pushed from an > endpoint that isn't a recursive resolver but there have been other > proposals. > > For example www.example.com pushes you a record for img1.example.com. > Should you use it? What if it is for img1.img-example.com ? Do the > relationship between these domains matter? What kind of relationship (i.e. > it could be a domain relationship, or in the context of a browser it might > be a first-party tab like relationship, etc..)? What are the implications > of poison? Trackers? Privacy of requests never made? Speed? Competitive > shenanigans or DoS attacks? > > This was out of scope for DoH. > > *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to > 17:30 on Monday July 16th.* > > This is a meeting of interested folks looking to see if we can agree on > next steps - we're not going to work out the details (nor should a side > meeting try and do so). so we'll have a tight agenda that I suggest > organizaing as follows: > > 1] What forms of transport could be in scope? HTTP/2 push is one such > vector, but I've heard others. Spray paint for example. > > 2] What needs to be considered when using such data? (signatures? scope? > etc?) > > 3] Who are the stakeholders for 1 + 2? > > 4] Is there enough interest to explore further? Next steps as output > > I hope you can come! > > -Patrick > > Patrick: My goal is to find whether there are enough interested people to try to solve something. My use case is very simple: skipping an on-the-wire DNS exchange can provide better security, privacy, and performance. Can we do it safely? Part 1: What are the possible use cases and transports? HTTP/2 PUSH? Part 2: When is it safe to use these records? DKG: I think this is potentially useful in a lot of different places. We need to be very clear about the context of the data. Not only "is it acceptable data?", but "when might this data be usable?". In TLS, we were just talking about DNSSEC-chain TLS extension, but there will be many other opportunities. We have to John Richardson: I'm really concerned that doing DNS over DOH introduces the possibility of the internet looking different depending on which webpage you're using at a given time. We need to talk about whether we will honor the traditional single root of DNS. Paul Hoffman: I think we're going to have an issue that the subject line said "Resolverless", and in DOH there is a resolver (the HTTP server). We have two use cases here: the one that's actually "resolverless" and DOH where there is. DKG: I think we're talking about getting DNS from places where we haven't gotten DNS in the past, e.g. HTTP/2 PUSH from a random website. I didn't ask for those records. Paul Hoffman: That site was not a configured DOH server. Patrick: Right, this is about a case where you get a record from a server that is not configured. Do we want to take a next step to give that some meaning. John: You talked about "where the DNS comes from". Do you mean the server, or the zone? In my mind, it comes from the authoritative server. DKG: I meant that the channel by which the application received the record may not be indicative of how reliable it is. Tale: You don't necessarily need a resolver in that pipeline. If you're talking to a CDN, they can tell you information about zones that they host, with DNSSEC signatures, without ever having
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
On Thu, Jul 19, 2018 at 3:07 PM, Patrick McManus wrote: > > Am I correct in saying that what you're getting at is not so much a wire > issue as a convention among configuration and implementations? i.e. > wildcards are synthesized - they aren't actually sent as responses that > clients use in some kind of short-cut kind of way? > > [replying to myself] I see now that the wildcards are part of things like axfr which form an open definition for interoperability.. so they are a wire protocol element of a sort. Thanks! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
Hi Jan, On Thu, Jul 19, 2018 at 2:48 PM, Jan Včelák wrote: > Patrick, I believe my understanding of the SNI consumer side is the > same. I'm talking about inability to use DNS wildcard on SNI producer > side: > > Let's say I get domain example.com and wildcard certificate > *.example.com. I want to run a couple of services on the subdomains of > the esni keys are completely independent of the associated certificates. Indeed it is anticipated that the same set of esni keys would cover many different parties and certificates that only share a TLS termination point in common. (i.e. the esni keys don't encrypt or authenticate https, they just encrypt the SNI field). so for clarity we should probably move on from certificate properties. nonetheless, it is indeed the point of ESNI that the same TXT (or perhaps ESNI RR-type) content applies to multiple domains - that's what forms the anonymity pool. > example.com and I want to use ESNI. If a TLS client want's to connect > for instance to www.example.com, it will resolve www.example.com > A/ record to get server IP and _esni.www.example.com TXT to get > the key to encrypt SNI. Is that right or did I miss something about > your draft? > > sounds right > If the above true, then my objection is that I cannot use DNS wildcard > for _esni record and I will have to create explicit one for each > subdomain (service) on example.com. Another annoying thing is that > existence of _esni.www.example.com TXT record will prevent expansion > of *.example.com A/ for www.example.com. The solution would be to > request new DNS RR type for ESNI which could be used with > *.example.com DNS name. > > got it (and as I hinted above, the RRTYPE is an open issue in the bug tracker - I think there's significant support for making the change though this is the first I've heard this argument, so I'll add it to the list. thanks). Am I correct in saying that what you're getting at is not so much a wire issue as a convention among configuration and implementations? i.e. wildcards are synthesized - they aren't actually sent as responses that clients use in some kind of short-cut kind of way? Thanks for the help. > Jan > On Thu, Jul 19, 2018 at 2:27 PM Patrick McManus > wrote: > > > > the tls server side (aka the cert side) can definitely use a wildcard > (or a list of explicit names, or a mix of both!) But that's the SNI > consumer. The draft is about the SNI producer which does not use wildcards. > > > > e.g. the ESNI work is about what is put in the TLS client handshake > (historically the SNI and according this draft a new extension carrying the > encrypted SNI) - and that is always an explicit name. And that's also the > subject of the DNS query in order to obtain the keys. The DNS query and SNI > leak similar amounts of information (although perhaps to different > parties), so an encrypted DoT or DoH is an important part of the system. > > > > > > On Thu, Jul 19, 2018 at 1:53 PM, Tim Wicinski > wrote: > >> > >> Patrick > >> > >> Can I go and order a SSL Cert with a standard name and a wildcard name > for SNI? We do that now. > >> > >> So, I think Jan is onto something. > >> > >> > >> On Thu, Jul 19, 2018 at 1:47 PM, Patrick McManus > wrote: > >>> > >>> > >>> On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák wrote: > >>>> > >>>> Hey, > >>>> > >>>> I just scanned the draft and focused mainly on the DNS bits. The > >>>> described method for publishing encryption keys for SNI in DNS won't > >>>> allow use of wildcard domain names. > >>>> > >>> > >>> Thanks! > >>> > >>> I believe the draft is OK on this point because wildcards aren't > needed. While certificates can be valid for wildcard domains, the SNI is > always a specific hostname (and the plaintext hostname informs the DNS > question) > >>> > >>> > >>> > >>> ___ > >>> DNSOP mailing list > >>> DNSOP@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dnsop > >>> > >> > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
the tls server side (aka the cert side) can definitely use a wildcard (or a list of explicit names, or a mix of both!) But that's the SNI consumer. The draft is about the SNI producer which does not use wildcards. e.g. the ESNI work is about what is put in the TLS client handshake (historically the SNI and according this draft a new extension carrying the encrypted SNI) - and that is always an explicit name. And that's also the subject of the DNS query in order to obtain the keys. The DNS query and SNI leak similar amounts of information (although perhaps to different parties), so an encrypted DoT or DoH is an important part of the system. On Thu, Jul 19, 2018 at 1:53 PM, Tim Wicinski wrote: > Patrick > > Can I go and order a SSL Cert with a standard name and a wildcard name for > SNI? We do that now. > > So, I think Jan is onto something. > > > On Thu, Jul 19, 2018 at 1:47 PM, Patrick McManus > wrote: > >> >> On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák wrote: >> >>> Hey, >>> >>> I just scanned the draft and focused mainly on the DNS bits. The >>> described method for publishing encryption keys for SNI in DNS won't >>> allow use of wildcard domain names. >>> >>> >> Thanks! >> >> I believe the draft is OK on this point because wildcards aren't needed. >> While certificates can be valid for wildcard domains, the SNI is always a >> specific hostname (and the plaintext hostname informs the DNS question) >> >> >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [internet-dra...@ietf.org: I-D Action: draft-rescorla-tls-esni-00.txt]
On Thu, Jul 19, 2018 at 1:36 PM, Jan Včelák wrote: > Hey, > > I just scanned the draft and focused mainly on the DNS bits. The > described method for publishing encryption keys for SNI in DNS won't > allow use of wildcard domain names. > > Thanks! I believe the draft is OK on this point because wildcards aren't needed. While certificates can be valid for wildcard domains, the SNI is always a specific hostname (and the plaintext hostname informs the DNS question) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] 4 DNS presentations on MAPRG (Thu 9:30 @Place du Canada)
I will say that maprg has become my favorite "value added" event of IETF week - terrific opportunity to learn about how the Internet really works in ways a bit beyond (but relevant to) our usual focuses. (whatever those focuses might be). Highly recommend. On Wed, Jul 18, 2018 at 2:21 PM, Tim Wicinski wrote: > Thanks Giovane. I am hoping some DNSOP folks will show up. > > It does conflict with DNS-SD, but those look like interesting talks. > I've included the links for the click-adverse: > > https://datatracker.ietf.org/meeting/102/materials/slides- > 102-maprg-dmap-automating-domain-name-ecosystem- > measurements-and-applications-giovane-c-m-moura-00 > https://datatracker.ietf.org/meeting/102/materials/slides- > 102-maprg-monitoring-dns-with-open-source-solutions-felipe-espinoza-00 > https://datatracker.ietf.org/meeting/102/materials/slides- > 102-maprg-when-the-dyke-breaks-dissecting-dns- > defenses-during-ddos-giovane-c-m-moura-00 > https://datatracker.ietf.org/meeting/102/materials/slides- > 102-maprg-dnssec-ksk-2010-trust-anchor-signal-analysis-wes-hardaker-00e > > > > On Wed, Jul 18, 2018 at 2:13 PM, Giovane C. M. Moura < > giovane.mo...@sidn.nl> wrote: > >> >> >> Hello Folks, >> >> So in the end of today's session, I briefly mention that there will be 4 >> presentations on MAPRG tomorrow about DNS. After that, some people told >> me they'd would have liked to know a bit more these presentations and >> the group itself, since many people on DNSOP may not be aware of MAPRG. >> >> While I cannot speak for the MAPRG chairs[1], the group brings Internet >> measurement folks to the IETF , and many of the works are about >> evaluating protocols engineered here. >> >> Tomorrow's session will have 4 presentations on DNS[2], and two of them >> are 20min long: >> >> * When the Dike breaks: dissecting DNS Defenses during DDoS (by me, so >> I can elaborate a bit): >> >> There has been various DDoS attacks against DNS; with different impact >> on users. DNS recursives has various built-in mechanisms >> (caching,replication, retries). In this paper, we evaluate the user's >> experience, based on the built-in resilence of DNS, in emulated DDoS >> attacks using Ripe Atlas. There is various tips for ops teams in >> engineering auth servers for DDoS. >> >> * Finding the source of DNS resolver users that were using old DNSSEC >> keys, by Wes Hardaker >> >> Then, there are two 'heads-ups' presentations (5min each): >> >>* Heads-up talk: Dmap: Automating Domain Name Ecosystem Measurements >> and Applications, by me too >> >>* Heads-up talk: Monitoring DNS with open-source solutions, by Felipe >> Espinoza >> >> >> So it would be nice to have some DNSOP folks in the room for some >> interesting discussions. It will start at 9:30 at Place du Canada. >> >> Best, >> >> /giovane >> >> >> [1] https://datatracker.ietf.org/group/maprg/about/ >> [2] https://datatracker.ietf.org/meeting/102/materials/agenda-10 >> 2-maprg-02 >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal
yes; and.. dns has always provided a point of indirection that is useful. dynamically rewriting markup might be infeasible.. and many fetch() like things are driven from script where the markup changes are not obvious or perhaps ill fitting.. and of course there are questions of cached content that might like to late bind. so lots to think about; but the markup example is very illustrative of a very conservative way of scoping things. perhaps too conservative. worth exploring. On Tue, Jul 10, 2018 at 11:02 AM, Adam Roach wrote: > On 7/10/18 11:34 AM, Joe Abley wrote: > >> On Jul 10, 2018, at 17:22, Adam Roach wrote: >> >> Basically, you're describing a solution space that could be realized as >>> something like: >>> >>> https://example.com/img/f.jpg; ip="192.0.2.1"> >>> >> Ok, interesting. I would suggest considering a richer scheme that >> accommodates address families and multiple addresses with priorities, >> but I see how that kind of thing would allow a client to do so >> certificate matching and resource retrieval without using the DNS. >> >> But this is really equivalent in just about every important way to >>> sending the normal https://example.com/img/f.jpg;> along with >>> a pushed DNS record that indicates that "example.com" resolves to >>> "192.0.2.1" -- and this latter thing is (to my understanding, at least) in >>> scope of the conversation that Patrick is proposing to have. >>> >> My question is why you would involve the DNS at all if all the >> performance-based resolution decisions can be made without it. You're >> just adding cost and complexity without benefit. >> > > In large part because DNS provides "a richer scheme that accommodates > address families and multiple addresses with priorities". > > > /a > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal
probably not (whatever is available will be adhoc) - its a side meeting (aka bar bof) meant to take advantage of whomever is there. It has no process value. I'll make an effort to take minutes and report out though. On Tue, Jul 10, 2018 at 9:42 AM, manu tman wrote: > > > On Mon, Jul 9, 2018 at 7:49 PM Patrick McManus > wrote: > >> >> *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to >> 17:30 on Monday July 16th.* >> > > Will it be recorded and will there be everything set for remote > participants? > > Manu > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Resolverless DNS Side Meeting in Montreal
> Assuming that in the context of DoH reply size is not an issue, is seems to > me that this use case is already solved by DNSSEC. Just push all required > signatures, key material and DS records that allow the receiving side to > validate the additional information. > > that validates its a valid dns record. And maybe that's the whole answer - at which point we still need to write that down along with the scope of where its valid. otoh - maybe its not the same valid dns record another resolver might want you to use. perhaps you have a stronger trust relationship with that other resolver. hmm. otoh - maybe an unsigned record is ok in an https context where DNS isn't the https security model. this is the kind of stuff that I expect is in scope for discussion. > Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC no. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Driu] Resolverless DNS Side Meeting in Montreal
this is essentially a bar bof - though lacking in a bar and I'm fond of more professional terms so I call it a side meeting. It has no standing. If you're interested then please come, if you're not or are conflicted then you're missing anything process wise. Someday it might graduate to becoming a bof - but I would never put a bof forward that didn't have a proposal I was comfortable with. This is indeed a side meeting for anyone interested to see if there is a shared vision for what such a proposal might look like. Its not in scope for any wg as there isn't a proposal. Its quite possible that it might have multiple outcomes which are in scope for multiple application groups; I've tried to cc the likely suspects here. But that is presupposing outcomes. -P On Mon, Jul 9, 2018 at 10:55 PM, Ted Lemon wrote: > This sounds an awful lot like an unapproved bof. The reason we don’t do > those is that they tend to make it hard for people to participate. Why > isn’t this in scope for dnsop? > > On Mon, Jul 9, 2018 at 10:49 PM Patrick McManus > wrote: > >> Hi All, >> >> I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in >> Montreal. >> >> We have often talked about the benefits and concerns of DNS information >> obtained from sources that are, shall we say, less globally trusted than a >> recursive a resolver. The central use case is DoH when pushed from an >> endpoint that isn't a recursive resolver but there have been other >> proposals. >> >> For example www.example.com pushes you a record for img1.example.com. >> Should you use it? What if it is for img1.img-example.com ? Do the >> relationship between these domains matter? What kind of relationship (i.e. >> it could be a domain relationship, or in the context of a browser it might >> be a first-party tab like relationship, etc..)? What are the implications >> of poison? Trackers? Privacy of requests never made? Speed? Competitive >> shenanigans or DoS attacks? >> >> This was out of scope for DoH. >> >> *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to >> 17:30 on Monday July 16th.* >> >> This is a meeting of interested folks looking to see if we can agree on >> next steps - we're not going to work out the details (nor should a side >> meeting try and do so). so we'll have a tight agenda that I suggest >> organizaing as follows: >> >> 1] What forms of transport could be in scope? HTTP/2 push is one such >> vector, but I've heard others. Spray paint for example. >> >> 2] What needs to be considered when using such data? (signatures? scope? >> etc?) >> >> 3] Who are the stakeholders for 1 + 2? >> >> 4] Is there enough interest to explore further? Next steps as output >> >> I hope you can come! >> >> -Patrick >> >> ___ >> DRIU mailing list >> d...@ietf.org >> https://www.ietf.org/mailman/listinfo/driu >> > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Resolverless DNS Side Meeting in Montreal
Hi All, I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in Montreal. We have often talked about the benefits and concerns of DNS information obtained from sources that are, shall we say, less globally trusted than a recursive a resolver. The central use case is DoH when pushed from an endpoint that isn't a recursive resolver but there have been other proposals. For example www.example.com pushes you a record for img1.example.com. Should you use it? What if it is for img1.img-example.com ? Do the relationship between these domains matter? What kind of relationship (i.e. it could be a domain relationship, or in the context of a browser it might be a first-party tab like relationship, etc..)? What are the implications of poison? Trackers? Privacy of requests never made? Speed? Competitive shenanigans or DoS attacks? This was out of scope for DoH. *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to 17:30 on Monday July 16th.* This is a meeting of interested folks looking to see if we can agree on next steps - we're not going to work out the details (nor should a side meeting try and do so). so we'll have a tight agenda that I suggest organizaing as follows: 1] What forms of transport could be in scope? HTTP/2 push is one such vector, but I've heard others. Spray paint for example. 2] What needs to be considered when using such data? (signatures? scope? etc?) 3] Who are the stakeholders for 1 + 2? 4] Is there enough interest to explore further? Next steps as output I hope you can come! -Patrick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] re original_transport indicator
Hi All, We've had quite a thread re the -05 optional parameter to the dns-udpwireformat registration. The parameter is defined as having no meaning for DoH, but was included to accommodate a use case the dnsop wg is considering. Future proofing, if you like. Upon consideration (and a read of 6838), I think including this in doh is premature because Media Type registrations can be updated by mechanisms laid out in RFC6838 and in this case such an update could occur without impacting existing DoH deployments. (i.e. it does not need to be future proofed). Therefore the definition of the parameter should accompany the work that makes use of it if a future standards document chooses to go down that path. As a bonus we avoid unused clutter if it doesn't happen. I also get the feeling that there isn't yet strong consensus on the anticipated use case or the exact form it needs to take - we should let that process work itself out separately before registration. I've chatted with Paul, and our recommendation is to remove the original_transport parameter from DoH and encourage dnsop to update the registration if/when a different standard needs to make use of it. thoughts? -Patrick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS over HTTP Bar Bof Tuesady 6:45 Studio 7
On Mon, Nov 14, 2016 at 7:52 AM, Patrick McManus <pmcma...@mozilla.com> wrote: > Our Bar BOF will be Tuesday evening at 6:45 in Studio 7 on the 6th Floor > of the Conrad. See you there! I should have mentioned - plan on a duration of 1 hour. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS over HTTP Bar Bof Tuesady 6:45 Studio 7
Our Bar BOF will be Tuesday evening at 6:45 in Studio 7 on the 6th Floor of the Conrad. See you there! as a reminder - this is our scope: DNS over HTTP comes up again and again - each time the context is a bit different. Some efforts try and extract information from the DNS via HTTP, others try and modify the DNS information via HTTP, others try and use HTTP as a tunnel for the DNS protocol, and still others aim to integrate DNS information directly into the HTTP protocol stack. Along the way there are firewalls, caches, markup languages, content-encodings, half solutions, security challenges, and other dragons. Someone made the excellent suggestion that we try and get a broad set of expertise here - both from the folks that understand DNS, the folks that are more experienced with HTTP, as well as the folks well versed in interfaces together to build a more complete set of requirements and after that's done we can make a gut check on whether that's a problem we want to solve together. Let's hold an informal bar-bof in Seoul (time and place TBD) on the topic and see if we can get critical mass together for the effort - we can discuss forums/etc for this work along the way - but I'm most interested to see if we can get the attention of the diverse set of folks necessary to make it succeed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsoverhttp] Bar BOF in Seoul and Mailing List - DNS over HTTP ideas
Hi all - Let's set the meeting time for Tuesday at 1845 - so shortly after the last session of the day - budget an hour of time. Space is technically TBD but will be at the meeting hotel. I'll let you know when I know - but that might not be until IETF week. -Patrick On Fri, Oct 21, 2016 at 7:42 PM, Paul Hoffman <paul.hoff...@icann.org> wrote: > On Oct 20, 2016, at 9:57 AM, Patrick McManus <pmcma...@mozilla.com> wrote: > > We're planning an informal Bar BOF on this topic Tuesday night in Seoul. > The place is TBD - but I'll reply to this mail as we get closer with the > detail. Just hold the place on your dance-card. > > The official agenda just came out, and there is no Social Event listed for > Tuesday. > > Patrick: please pick a time as well as a place. The last IETF meeting ends > at 1820. We could meet right then in order to not push dinner off too much, > or we could meet "after dinner". We'll all have different preferences, so > let's leave it to Patrick to disappoint some of us. :-) > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Bar BOF in Seoul and Mailing List - DNS over HTTP ideas
Hi All - an update on this: We're planning an informal Bar BOF on this topic Tuesday night in Seoul. The place is TBD - but I'll reply to this mail as we get closer with the detail. Just hold the place on your dance-card. If you haven't joined the list, there is some good discussion there and even a draft (thanks Paul and Joe!) - check it out on the archives. -Patrick On Tue, Sep 13, 2016 at 11:22 AM, Patrick McManus <pmcma...@mozilla.com> wrote: > Hi All - > > DNS over HTTP comes up again and again - each time the context is a bit > different. Some efforts try and extract information from the DNS via HTTP, > others try and modify the DNS information via HTTP, others try and use HTTP > as a tunnel for the DNS protocol, and still others aim to integrate DNS > information directly into the HTTP protocol stack. Along the way there are > firewalls, caches, markup languages, content-encodings, half solutions, > security challenges, and other dragons. > > Someone made the excellent suggestion that we try and get a broad set of > expertise here - both from the folks that understand DNS, the folks that > are more experienced with HTTP, as well as the folks well versed in > interfaces together to build a more complete set of requirements and after > that's done we can make a gut check on whether that's a problem we want to > solve together. > > Let's hold an informal bar-bof in Seoul (time and place TBD) on the topic > and see if we can get critical mass together for the effort - we can > discuss forums/etc for this work along the way - but I'm most interested to > see if we can get the attention of the diverse set of folks necessary to > make it succeed. > > There is a new list as a way to prepare for that meetup. > > List address: dnsoverh...@ietf.org > Archive: https://mailarchive.ietf.org/arch/search/?email_list=dnsoverhttp > To subscribe: https://www.ietf.org/mailman/listinfo/dnsoverhttp > > I know some folk are working in this space already - please join > dnsoverhttp and share what you're working on (or have worked on in the past > and lessons learned from it) > > Thanks! > -Patrick > > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Bar BOF in Seoul and Mailing List - DNS over HTTP ideas
Hi All - DNS over HTTP comes up again and again - each time the context is a bit different. Some efforts try and extract information from the DNS via HTTP, others try and modify the DNS information via HTTP, others try and use HTTP as a tunnel for the DNS protocol, and still others aim to integrate DNS information directly into the HTTP protocol stack. Along the way there are firewalls, caches, markup languages, content-encodings, half solutions, security challenges, and other dragons. Someone made the excellent suggestion that we try and get a broad set of expertise here - both from the folks that understand DNS, the folks that are more experienced with HTTP, as well as the folks well versed in interfaces together to build a more complete set of requirements and after that's done we can make a gut check on whether that's a problem we want to solve together. Let's hold an informal bar-bof in Seoul (time and place TBD) on the topic and see if we can get critical mass together for the effort - we can discuss forums/etc for this work along the way - but I'm most interested to see if we can get the attention of the diverse set of folks necessary to make it succeed. There is a new list as a way to prepare for that meetup. List address: dnsoverh...@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=dnsoverhttp To subscribe: https://www.ietf.org/mailman/listinfo/dnsoverhttp I know some folk are working in this space already - please join dnsoverhttp and share what you're working on (or have worked on in the past and lessons learned from it) Thanks! -Patrick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
