From nobody Tue Dec 1 15:05:00 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696503A0AE8 for ; Tue, 1 Dec 2020 15:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s-AoS8j5mnI for ; Tue, 1 Dec 2020 15:04:54 -0800 (PST) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC6F3A0AE6 for ; Tue, 1 Dec 2020 15:04:54 -0800 (PST) Received: by mail-vs1-xe2f.google.com with SMTP id q10so641508vsr.13 for ; Tue, 01 Dec 2020 15:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zVyLWmo0ep9OEgpqCqfx/HCupW0sPnMPQCO0y6v1rdA=; b=FAwryMk7falh/wfBN+FKU+A+ub8/Ihul99am4IsdPfQB7WxL+IMeSXpFZL1qAsRINm UGJ8qgX7tiEi77CpRBClUgQxIHrhITrf+ywCIXkYW5g2sL8w5SHOeTZpLIYUcL3oTjxw j/eFQ+cQtX6mv00jTY3P2BJXAF413DT04qXVI2emQ0oqsk/CXyhPWMVUP58Ektf4xZly DolpwF71bpyW3U2YDUfTrydDMkHb3FTfJYBK3fDixs00lHZTEOfQpI8iL1FN7PJ5Tr6u uqfV3zP0J0KLO7+Q6uPxbNpsPPOtbIrCKLiBdXcxfdAkOE9H27BWl/Z5DYS1blBenwMM T3VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zVyLWmo0ep9OEgpqCqfx/HCupW0sPnMPQCO0y6v1rdA=; b=m3lC0DI4b333dofp2Ys6zw1skZbg+rdpxw8S94FXbYz0/przAhHWNdODmtcQ9nix8f GqByQlLphsrPwQ++dLIoWbWr9j5Lnna6AKOwLDBu7xB8RXpnn4MRug603DKUY8D1uuLJ GXjkD/NbuSDILTjLjSUSgDC452NDN5Eyeglm5OTjVdPAf3HUVMIslFD54G3lsbI5nCTe /P00KI5lal3SPbrEuvoLt4WBrcn734I+kV85C+/Zqjds3X71dtIWzNVnaa90JjQu/ZGY x6+Q9OWh72fnQxBabFdV64LK8viKGpaR/ajog7IKR+m116b7AiGtmedlGy5b7xorqpKh RZTw== X-Gm-Message-State: AOAM530DCWVeLQAudhWMpk5GgIo78idm4oN6lgIxNl7py0ixtmH9Lo7F yeczINztkr9pmk7XKV/Ytr7P3UkO2nOUITrYvNT329MTOG4= X-Google-Smtp-Source: ABdhPJzmy1q8fGz9sg1q0i+bebzC3+i2cc12A1Dl006GekyWaj25AXEiszEaO8b1BdYMYbB3c12jV+8pDWtOrnxDooU= X-Received: by 2002:a67:fb46:: with SMTP id e6mr1307547vsr.40.1606863892910; Tue, 01 Dec 2020 15:04:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Tue, 1 Dec 2020 18:04:41 -0500 Message-ID: To: Ben Schwartz Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000008a15ad05b56f2758" Archived-At: Subject: Re: [Add] draft-schwartz-svcb-dns-01 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 23:04:59 -0000 --0000000000008a15ad05b56f2758 Content-Type: text/plain; charset="UTF-8" Thanks for the response. Please see additional information / comment inline. Yours, Daniel On Mon, Nov 30, 2020 at 2:57 PM Ben Schwartz wrote: > > > On Wed, Nov 25, 2020 at 5:10 PM Daniel Migault > wrote: > >> Hi, >> >> Please find my comments below for draft-schwartz-svcb-dns-01 >> > > Thanks for the detailed review. > > Yours, >> Daniel >> Service Binding Mapping for DNS Servers >> draft-schwartz-svcb-dns-01 >> [...] >> >> 1. Introduction >> >> The SVCB record type [SVCB] provides clients with information about >> how to reach alternative endpoints for a service, which may have >> improved performance or privacy properties. >> >> >> It is unclear to me if "alternative" >> means "various flavors of DNS resolvers" >> or if it assumes the previous knowledge >> of one flavor of the resolver. I do not >> believe the latest is appropriated. >> > > This is a general summary of SVCB. When using SVCB, there is a single > logical "service" that can be accessed via different "endpoints". I'm not > sure what you mean by "flavor", but SVCB assumes that the service's > behavior does not greatly depend on which endpoint you use to access it. > > Maybe I am using unappropriated language, but I see the dns resolution service as being declined into different "flavors" or "(sub) services" like Do53, DoH, DoT. But I think my question was regarding the term "alternate". It i sunclear if alternate hee means "different" or if they are taking the place of something in which case who they are taking the place to. > The input of a SVCB query is a FQDN, and >> that FQDN is not necessarily related to >> a Do53 resolver for example. It could >> typically an entry point used to >> discover all different flavors of DNS >> resolvers. Assuming a previous knowledge >> of one resolver seems to preclude some >> assumption on the FQDN, which seems >> independent from the description of SVCB >> fro DNS. >> >> > > Sorry, I'm still not understanding, possibly because I do not understand > the idea of a "flavor". The draft assumes a DNS server (or "service") > identified by a domain name, with Do53 service available via A and AAAA > records for that name (if a Do53 service exists, which seems likely to be > common but is not required). > It seems to me that the draft considers as the entry point the FQDN associated to the Do53 server, that is in your example below. resolver.example is the Do53 service and requesting resolver.example/AAAA will give me the IP address I need to send the DNS requests to. $ORIGIN example. _dns.resolver 7200 IN SVCB 1 resolver ( alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} ) _dns.resolver 7200 IN SVCB 2 resolver ( port=8530 echconfig=... ) _dns.resolver 7200 IN SVCB 3 fooexp.resolver ( port=5353 echconfig=... alpn=foo no-default-alpn foo-info=... ) If my understanding is correct, there are two questions I am wondering: 1) Why do we mandate that the input of the SVCB query - in your example resolver.example - needs to be associated to the Do53 server. I do not think that should be in the specification as mandatory and and would consider this as simply good to know. I do see the following hierarchy: DNS resolution v v v DoH resolvers DoT resolvers, Do53 resolvers v v v IPs, IPs, IPs In this case I would consider the _dns.example, _53._dns.foo, _853._dns.foobar .. as services. A request for all DNS servers associated to the FQDN example would be _dns.example A request for all DoT servers associated to the FQDN foorbar would be _853._dns.foobar A request for all Do53 servers associated to the FQDN foo would be _53._dns.foo I seems to me that a request for foo AAA is configured to return the IP addresses of one server under _53._dns as a feature to provide some sort of retrocompatibility with legacy Do53 resolvers but it seems unclear to me why this should be required. Just to make myself clear, I do see the FQDN example as representing the input for searching the various available services. an example is then - at least to me - different than the FQDN associated to the terminating Do53 server. Having them equal is "nice" if we want to provide a FQDN to a device that may do requests of type SVCB or AAAA. Unless I am missing something, it seems that legacy devices take an IP address - not an FQDN - and so we do not need to have such compatibility with legacy devices. 2) I am wondering how Do53 server are represented in SVCB. It seems to me that different Do53 DNS server may still be offered with different SvcParameters and so should be listed with SVCB RRsets. In addition, I would favor Do53 is explicitly mention so that went it is not deployed, the DNS client can actually knows this explicitly. > > The service is >> identified by a "scheme" indicating the service type, a hostname, and >> optionally other information such as a port number. A DNS server is >> often identified only by its IP address (e.g. in DHCP), but in some >> contexts it can also be identified by a hostname (e.g. "NS" records, >> manual resolver configuration). >> >> >> I like the paragraph, but I believe it >> might help the reader to add that DNS >> servers can be authoritative or resolver >> which are quite common term. I am >> wondering however, if there are any >> reasons for not mentioning them. >> >> >> > > This is a deliberate omission: this draft is concerned only with DNS as a > protocol, not with the types of queries and responses that are encoded. In > principle, this SVCB mapping can be applied independently of whether the > server is authoritative for any names, or supports recursion. > Ok so that is an editorial choice. I am wondering though, if that would be a nosense to have a SvcParameter saying whether the end point is a resolver, authoritative, forwarder - either here or somewhere else. > > >> Names are formed using Port-Prefix Naming ([SVCB] Section 2.3). For >> example, a DNS server with the name "dns1.example.com", listening >> (unusually) on non-default port number 5353, would be represented as >> "_5353._dns.dns1.example.com.". >> >> >> While this seems conform to the SVCB >> spec ;-) I would have envisioned the >> port number prefix as designating the >> service rather that actual port on which >> the service is run. Typically in Do53 >> would be designated as _53._dns and if >> that service is run on port 5353 I would >> expected the number being provide by the >> port SvcParameter. >> > > The port SvcParam is also supported, but its meaning is different. The > port prefix identifies the service. The port SvcParam provides the > location of the alternative endpoint. > This seems to be my understanding. , but then "_5353._dns.dns1.example.com." seems to me misleading as 5353 represents while the text mentions the server is listening to an unusual port. My expectation was that a DNS server was listening on 5353 instead of 53. From my understanding of the text I would have expected to have 5353 in the SvcParameter. I think more text is needed here to disambiguate the signification of the port. Currently what we designate as the port does not seem to be the port. I would expect some clarification on where the port is defined. > > One specific reason for doing so is that >> the unconventional port cannot be >> guessed without previous knowledge. >> > > If the client has not been specifically informed that the service's > identity contains an unconventional port, it will assume the default port > (53), and query for SVCB records at _dns.$SERVER_NAME (no port prefix). > Each SVCB record returned may contain a port SvcParamKey indicating where > to find that alternative service endpoint. > This requires so two entries _dns.${server} and _5353._dns.${server} - probably CNAMed. I think the notation is mixing service and implementation of the service, and I am wondering if there are any reasons we need to do that here in this spec. Similarly, it seems to me that the convention to have port 53 as a default port is a convention that is specified in this document and that we could define it otherwise. If so, given that the service can be DoT, DoH, DoQ. I am wondering why couldn't we define _dns as the service abstraction of DNS that could be declined in DoT, DoH Do53.... without precluding a default port. I also believe that the port needs to explicitly mention how the port value is handled in _port._dns > > I believe that some specific convention >> should considers that _dns may designate >> the DNS service including all flavors. >> > > As above, I don't understand what is meant by a "flavor". > flavor meant to me DoT, DoQ, DoH, Do53... > > >> This key is used to indicate the target port for connection. If >> omitted, the client SHALL use the default port for each transport >> protocol: 853 for DNS over TLS and 443 for DNS over HTTPS. >> >> >> I have the impression some text is needed to define how the transport is >> determined. >> I favor that port is being specified in >> this field as opposed to in the prefix. >> I also believe that the port number >> should not be defined at two distinct >> places. >> > > These two port numbers have separate meanings: the prefix is an "input" > identifying the service, and the SvcParam is an "output" that locates the > endpoint. > > I agree, what I was trying to say is that the default port is defined from the transport, but the text does not indicate how transport is derived. I suppose that a reference to the alpn section could be added as well as an order in which the parameters needs to be looked at. > It seems that the default values depends >> on other SvcParameters - alpn or absence >> of it. >> > > Correct: in this draft, there is no single default value for "port". > Instead, in the absence of a specified port, each transport uses its own > default port. This enables a single SVCB record to represent both DNS over > TLS on port 853 and DNS over HTTPS on port 443, as in the draft's first > example: > > _dns.resolver 7200 IN SVCB 1 resolver alpn=h2,h3 echconfig=... > dohpath=/dns-query{?dns} > > (This example enables DNS over TLS on port 853 implicitly.) > > We could change default behavior for "port", but it would likely make > typical usages more verbose. > I am fine with this, this matches my understanding. > > This key is automatically mandatory if present. >> >> >> I might be missing some context here, >> but the latest sentence is a bit hard >> for me to understand. >> >> The condition " if present" seems >> contradicting the term "mandatory". I >> cannot figure out also what >> automatically mandatory means. >> >> >> > > Yes, "automatically mandatory" is a specific term from the SVCB draft: > https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02#section-7. > I've added a cross-reference for clarity: > https://github.com/bemasc/svcb-dns/commit/535df722c9404413020af34d3d0e7209e3a206c1 > > >> >> ok, will look at it. > 4.2. alpn and no-default-alpn >> >> These keys indicate the set of supported protocols. The default >> protocol is "dot", indicating support for DNS over TLS [DOT]. >> >> If the protocol set contains any HTTP versions (e.g. "h2", "h3"), >> then the record indicates support for DNS over HTTPS [DOH], and the >> "dohpath" key MUST be present (Section 5.1). All keys specified for >> use with the HTTPS record are also permissible, and apply to the >> resulting HTTP connection. >> >> >> I believe the text may specify the >> absence of alpn means DNS over UDP. >> > > If the "alpn" key is absent, the default is "dot". > > >> I am >> unsure whether no-default-alpn means >> that alpn key is omitted or not, but if >> that is the case, it does not seem >> necessary to introduce its designation. >> > > The default ALPN is "dot", so "no-default-alpn" means "DNS over TLS is not > supported". If the "alpn" key is then omitted, the record is useless/null: > it indicates no supported protocols at the alternative endpoint, so no > client will ever attempt to make use of that record. > > I think some text could be added to specify the meaning of no-default-alpn in the context of this spec. I am wondering in light of comments provided earlier, if one could not consider alpn mandatory and when omitted meaning Do53. This would remove the need to define no-default and include Do53 as a potential service. > Instead it might be clear enough to >> mention the alpn default value considers >> DNS over UDP. >> > > This draft does not currently offer any way to describe a DNS over UDP > alternative endpoint. > I think I start seeing this, but I am still not convinced this is appropriated to consider Do53 as different from other services. > > It also worth mentioning that alpn needs >> to be parsed before port and potential >> dohpath. >> >> > > I expect that a client would parse a record completely before attempting > to make use of it, so I'm not concerned with this dependency. > Parsing was maybe inappropriate, but I would say start looking at alpn before looking at port. > > 4.3. Other applicable SvcParamKeys >> >> These SvcParamKeys apply to the "dns" scheme without modification: >> >> * echconfig >> >> * ipv4hint >> >> * ipv6hint >> >> >> not sure we need this section as the >> document is limited on the DNS >> transport. >> > > Yes, this is perhaps redundant. We could instead adjust the wording in > the SVCB draft to indicate that these keys are assumed to be broadly > applicable. However, I don't think it hurts to remind the reader of other > keys that they can use in this context. > > I am however wondering if we should >> distinguish between authoritative and >> resolver. >> > > This draft is not intended to be specific to one server role or the > other. This is noted in Section 6. > > >> I am wondering if ther is any room for >> searching specifically doh server by >> requesting: >> >> _443._dns.resolver 7200 IN SVCB 1 resolver ( >> alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} ) >> >> If that is not the case, it seems we >> should clarify this. >> The same case occurs with DoT, Do53. >> >> The advantage would be that it enables >> to narrow down the search and prevents >> the search of non supported transports. >> > > This is an interesting idea, but the SVCB framework does not support this > approach. With SVCB, the client sends a request that describes a logical > service, and receives an RRSet of alternative endpoints covering all the > service's supported protocols. > I understand that _443._dns does not represent DoH for example. but instead a service DNS can could (eventually) be DoT. In other words, with standard ports _443._dns does not exist. I am wondering if this a choice we make - and that could be otherwise - or if there are a higher philosophy that makes us take this path - from svcb-https. If so, and for clarification, I am wondering if the definition of DoH as a service would require the definition of _doh for example. I do not necessarily thinks here this is a good idea. One thing that remains unclear to me is the relation between URL scheme and service. Currently the port indicate sthe protocol (DoT, DoH, ) which makes it difficult to have DoT on port 6777. I am wondering how this matters. > > The downside is that it requires some >> synchronization between SVCB RRsets and >> when multiple supports are supported by >> one client multiple queries may be >> performed. It also may require to define >> some preference across SVCB RRsets over >> multiple domains. >> > > Personally, I expect that servers will typically implement only a small > number of protocols (at most ~4), and clients will often support more than > one, so transferring the entire configuration in a single RRSet seems > likely to be more efficient overall than issuing multiple queries. > > One aspect that I have not seen in the spec is the SVCB 0 and I expect this to be used to delegate to third parties that will host multiple instances of the service. What I think my increase the size of the number of service instances is the services associated to the DNS resolution service. > >> >> 9. Security Considerations >> >> 9.1. Adversary on the query path >> >> This section considers an adversary who can add or remove responses >> to the SVCB query. >> >> Clients MUST authenticate the server to its name during secure >> transport establishment. This name is the hostname used to construct >> the original SVCB query, and cannot be influenced by the SVCB record >> contents. >> >> I understand that after the SVCB >> exchange, the DNS client sets a TLS >> session with the DNS server. I think >> this is only valid when TLS is >> supported and Do53 woudl not fit in this >> category. >> > > Yes. This draft does not provide a way to describe a Do53 alternative > endpoint. > > It sounds to me difficult to have a >> requirement that says, when a https >> server supports https the session must >> be authenticated. >> > > I'm not sure I understand. Authenticated transport is a requirement for > HTTPS. > I do not think it is possible not to authenticate either, so it might not be necessary to require such authentication. It is a nit. > > >> I am tempted to say >> that the https server should not serve >> non secure sessions. On the other hand, >> one can also envisioned the case where >> a given IP/FQDN is shared by DoH and >> Do53, which makes such assumption >> difficult. >> Unless I am missing something, it sounds >> to me the MUST statement is difficult to enforce. >> > > This section is only meant to tell clients to perform SSL certificate > validation in the usual way. > > >> I think it is good to specify what name >> must be present in the certificate. >> Though what is unclear to me is why the >> name should be the one of the query as >> opposed as the one in the RDATA. >> > > The RDATA is potentially untrusted. In the absence of DNSSEC, an > intermediary could rewrite the RDATA to contain any name. > I think the reasoning should be provided with a recommendation as it assumed the input is provided in a trusted way and that DNSSEC is not enabled. > > I understand the text as saying that >> connecting to fooexp.resolver.example, the >> certificate should have >> resolver.example. >> > > Correct. > > >> If that is correct, >> and unless I am missing something, I >> would be more inclined to authenticate >> fooexp.resolver.example. >> One case I see is an ISP delegating to a >> DNS resolver provider - like akamai. It >> should rather let the user authenticate >> akamai than the ISP hostname. Other >> scenario could ignore the hostname and >> use a footprint or the entire >> certificate. >> Of course this would require DNSSEC. >> >> It seems such recommendation is limited >> to the case when DNSSEC is not used and >> when the SVCB name is provisioned in a >> trusted manner. >> > > Yes. However, the service provider does not know that the name was > provisioned insecurely, and it does not know that the client is validating > DNSSEC, so it has to include the service name in its certificate. Since > all service providers will place the service name in the certificate, > clients should check for this name, regardless of whether they validate > DNSSEC. > Unless I am missing something, it seems to me the responsibility of the DNS client to perform the appropriated checks. If the service provider is resolver.com, it's responsibility seems limited to serve the request it receives. The responsibility of the DNS client is to make sure there is a trusted delegation to the provider. That the service name isp.resolver is in the certificate is only one way to do so and put the constraints too high on the service provider - in my opinion. I would add this as a recommendation. A typical use case may be a resolver redirecting to public resolvers. > > >> If an attacker is likely >> to update the SCVB content, he might >> potentially have provided the false >> entry to initiate the SVCB query, in >> which case there may not be any need to >> update the SVCB parameters. >> >> I believe the primary recommendation should be >> to use DNSSEC and then consider the very >> specific use case where DNSSEC cannot be >> used with a trusted SVCB entry. >> >> > > This draft's approach to authentication is inherited from SVCB, which > similarly does not rely on DNSSEC. In both cases, I think the current > drafts are taking the best approach. In many or most of the anticipated > applications, DNSSEC is not widely deployed, and we do not need it in order > to deploy SVCB securely. > I do not believe that seems appropriated in the scope of DNS to explicitly not consider DNSSEC not being used. The application is question is the discovery of resolvers and there is no specific reasons it does not implement DNSSEC. Though I admit it is unclear to me why the browser industry is so reluctant to DNSSEC. > > Although this adversary cannot alter the authentication name of the >> server, it does have control of the port number and "dohpath" value. >> As a result, the adversary can direct DNS queries for $HOSTNAME to >> any port on $HOSTNAME, and any path on "https://$HOSTNAME", even if >> $HOSTNAME is not actually a DNS server. If the DNS client uses >> shared TLS or HTTP state, the client could be correctly authenticated >> (e.g. using a TLS client certificate or HTTP cookie). >> >> This behavior creates a number of possible attacks for certain server >> configurations. For example, if "https://$HOSTNAME/upload" accepts >> any POST request as a file upload, the adversary could forge a SVCB >> record containing "dohpath=/upload", causing the client to upload >> every query, resulting in unexpected storage costs. >> >> As a mitigation, a client of this SVCB mapping MUST NOT provide >> client authentication for DNS queries, except to servers that it >> specifically knows are not vulnerable to such attacks. Also, if an >> alternative service endpoint sends an invalid response to a DNS >> query, the client SHOULD NOT send more queries to that endpoint. >> >> >> The attack is limited to DoH and DoT is >> not concerned. >> > > Correct. > > This attack is targeting the https >> server, but in general the motivation >> for the client to authenticate the >> server is to protect its privacy. It >> seems this should be added or clarified. >> >> > > OK, I've added an explanation of why this is privacy-relevant and > strengthened the recommendation: > https://github.com/bemasc/svcb-dns/commit/e311a4e94edd67e17724e693ad2038396fba8b4f > -- Daniel Migault Ericsson --0000000000008a15ad05b56f2758 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the response. Please see addit= ional information / comment inline.=C2=A0

Y= ours,=C2=A0
Daniel

On Mon, Nov 30, 2020 at 2:57 PM Ben Schwartz <= ;bemasc@google.com> wrote:
<= /div>


On Wed, Nov 25, 2020 at 5:10 PM Daniel Migault <mglt.ietf@gmail.com&= gt; wrote:
Hi,=C2=A0

Please find my comments below for= =C2=A0draft-schwartz-svcb-dns-01

Thanks for the detailed review.

Yours,=C2=A0
Daniel
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Service Binding Mapping for DNS Servers
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-schwartz-s= vcb-dns-01
[...]

1.=C2=A0 Introduction

=C2=A0 =C2=A0The SV= CB record type [SVCB] provides clients with information about
=C2=A0 =C2= =A0how to reach alternative endpoints for a service, which may have
=C2= =A0 =C2=A0improved performance or privacy properties. =C2=A0

<mgl= t>
It is unclear to me if "alternative"
means "vari= ous flavors of DNS resolvers"
or if it assumes the previous knowled= ge
of one flavor of the resolver. I do not
believe the latest is appr= opriated.

This = is a general summary of SVCB.=C2=A0 When using SVCB, there is a single logi= cal "service" that can be accessed via different "endpoints&= quot;.=C2=A0 I'm not sure what you mean by "flavor", but SVCB= assumes that the service's behavior does not greatly depend on which e= ndpoint you use to access it.

=
<mglt>
Maybe I am using unappropriated language, but I= see the dns resolution service as being declined into different "flav= ors" or "(sub) services" like Do53, DoH, DoT.=C2=A0 But I th= ink my question was regarding=C2=A0the term "alternate". It i sun= clear if alternate hee means "different" or if they are taking th= e place of something=C2=A0in which=C2=A0case who they are taking the place = to.=C2=A0
=C2=A0</mglt>

</mglt>
=C2=A0
The input of a SVCB= query is a FQDN, and
that FQDN is not necessarily related to
a Do53 = resolver for example. It could
typically an entry point used to
disco= ver all different flavors of DNS
resolvers. Assuming a previous knowledg= e
of one resolver seems to preclude some
assumption on the FQDN, whic= h seems
independent from the description of SVCB
fro DNS. =C2=A0 =C2= =A0 =C2=A0
</mglt>
Sorry, I'm still not understanding, possibly because I do = not understand the idea of a "flavor".=C2=A0 The draft assumes a = DNS server (or "service") identified by a domain name, with Do53 = service available via A and AAAA records for that name (if a Do53 service e= xists, which seems likely to be common but is not required).

<mglt>
It seems to me t= hat the draft considers as the entry point the FQDN associated to the Do53 = server, that is=C2=A0in=C2=A0your example below.=C2=A0
resolver.e= xample is the Do53 service and requesting resolver.example/AAAA will give m= e the IP address I need to send the DNS requests to.=C2=A0

=C2=A0 $ORIGIN example.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_dns.= resolver 7200 IN SVCB 1 resolver (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0alpn=3Dh2,h3 echconfig=3D... dohpath=3D/dns-query{?dns} )
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0_dns.resolver 7200 IN SVCB 2 resolver (
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0port=3D8530 echconfig=3D... )
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_dns.resolver 7200 IN SVCB 3 fooexp.resolver= ( port=3D5353
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0echconfig=3D... = alpn=3Dfoo no-default-alpn foo-info=3D... )

If= my understanding is correct, there are two questions I am wondering:
=

1) Why do we mandate that the input of the SVCB query -= in your example resolver.example - needs to be associated to the Do53 serv= er. I do not think that should be in the specification as mandatory and and= would consider this as simply good to know.=C2=A0

I do see the following hierarchy:
DNS resolution=C2=A0
=C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
DoH resolvers=C2=A0 DoT resolvers, = Do53 resolvers
=C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v=C2=A0 = =C2=A0=C2=A0
IPs,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPs,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0IPs

In this case I would consi= der the=C2=A0 _dns.example, _53._dns.foo, _853._dns.foobar .. as services.= =C2=A0

A request for all DNS servers associa= ted to the FQDN example would be=C2=A0 _dns.example
A request for= all DoT servers associated to the FQDN foorbar would be=C2=A0 _853._dns.fo= obar
A request for all Do53 servers associated to= the FQDN foo would be=C2=A0 _53._dns.foo

I seems = to me that a request for foo AAA is configured to return the IP addresses o= f one server under _53._dns as a feature to provide some sort of retrocompa= tibility with legacy Do53 resolvers but it seems unclear to me why this sho= uld be required.=C2=A0

Just to make myself=C2=A0cl= ear, I do see the FQDN example as representing the input for searching the = various available services. an example is then - at least to me - different= than the FQDN associated to the terminating Do53 server.=C2=A0 Having them= equal is "nice" if we want to provide a FQDN to a device that ma= y do requests of type SVCB or AAAA. Unless I am missing something, it seems= that legacy devices take an IP address - not an FQDN - and so we do not ne= ed to have such compatibility with legacy devices.=C2=A0=C2=A0
2) I am wondering how Do53 server are represented in SVCB. It = seems to me that different Do53 DNS server may still be offered with differ= ent SvcParameters and so should be listed with SVCB RRsets. In addition, I = would favor Do53 is explicitly mention so that went it is not deployed, the= DNS client can actually knows this explicitly.=C2=A0=C2=A0

<= /div>
</mglt>

The service is
=C2=A0 =C2=A0identified by a "scheme" indicat= ing the service type, a hostname, and
=C2=A0 =C2=A0optionally other info= rmation such as a port number.=C2=A0 A DNS server is
=C2=A0 =C2=A0often = identified only by its IP address (e.g. in DHCP), but in some
=C2=A0 =C2= =A0contexts it can also be identified by a hostname (e.g. =C2=A0"NS&qu= ot; records,
=C2=A0 =C2=A0manual resolver configuration).

<mgl= t>
I like the paragraph, but I believe it
might help the reader to= add that DNS
servers can be authoritative or resolver
which are quit= e common term. I am
wondering however, if there are any
reasons for n= ot mentioning them.

</mglt>

This is a deliberate omission: this draft is conc= erned only with DNS as a protocol, not with the types of queries and respon= ses that are encoded.=C2=A0 In principle, this SVCB mapping can be applied = independently of whether the server is authoritative for any names, or supp= orts recursion.
<mglt>
O= k so that is an editorial choice. I am wondering though, if that would be a= nosense=C2=A0to have a SvcParameter saying whether the end point is a reso= lver, authoritative, forwarder - either here or somewhere else.
<= br>
</mglt>=C2=A0
=C2=A0
=
=C2=A0 =C2=A0Names are formed using Port-Prefix Naming ([SVCB] Secti= on 2.3).=C2=A0 For
=C2=A0 =C2=A0example, a DNS server with the name &quo= t;dns1.example.com", listening
=C2=A0 =C2=A0(unusually) on non-default port number = 5353, would be represented as
=C2=A0 =C2=A0"_5353._dns.dns1.example.com.".=

<mglt>
While this seems conform to the SVCB
spec ;-) I = would have envisioned the
port number prefix as designating the
servi= ce rather that actual port on which
the service is run. Typically in Do5= 3
would be designated as _53._dns and if
that service is run on port = 5353 I would
expected the number being provide by the
port SvcParamet= er.

The port Sv= cParam is also supported, but its meaning is different.=C2=A0 The port pref= ix identifies the service.=C2=A0 The port SvcParam provides the location of= the alternative endpoint.
<mglt><= /div>
This seems to be my understanding. , but then "_5353._dns.dns1.example.com." seems to = me misleading=C2=A0as 5353 represents while the text mentions the server is= listening to an unusual=C2=A0port. My expectation was that a DNS server wa= s listening on 5353 instead of 53. From my understanding of the text I woul= d have expected to have 5353 in the SvcParameter.=C2=A0
I think m= ore text is needed here to disambiguate the signification of the port. Curr= ently what we designate as the port does not seem to be the port. I would e= xpect some clarification on where the port is defined.=C2=A0
<= /mglt>=C2=A0

One specific = reason for doing so is that
the unconventional port cannot be
guessed= without previous knowledge.
<= br>
If the client has not been specifically informed that the ser= vice's identity contains an unconventional port, it will assume the def= ault port (53), and query for SVCB records at _dns.$SERVER_NAME (no port pr= efix).=C2=A0 Each SVCB record returned may contain a port SvcParamKey indic= ating where to find that alternative service endpoint.
<mglt>
This requires so two entries _dns.${s= erver} and _5353._dns.${server} - probably CNAMed. I think the notation is = mixing service and implementation of the service, and I am wondering if the= re are any reasons we need to do that here in this spec.=C2=A0
Similarly, it seems to me that the convention to have port 53 = as a default port is a convention that is specified in this document and th= at we could define it otherwise. If so, given that the service can be DoT, = DoH, DoQ. I am wondering why couldn't we define _dns as the service abs= traction of DNS that could be declined in DoT, DoH Do53.... without preclud= ing a default port.=C2=A0=C2=A0

I also believe tha= t the port needs to explicitly mention how the port value is handled in _po= rt._dns
</mglt>=C2=A0

<= div>
I believe that some specific convention
should considers that _= dns may designate
the DNS service including all flavors.
=

As above, I don't understa= nd what is meant by a "flavor".
<mglt>
flavor meant to me DoT, DoQ, DoH, Do53...
</mglt>=C2=A0
=C2=A0
=C2= =A0 =C2=A0This key is used to indicate the target port for connection.=C2= =A0 If
=C2=A0 =C2=A0omitted, the client SHALL use the default port for e= ach transport
=C2=A0 =C2=A0protocol: 853 for DNS over TLS and 443 for DN= S over HTTPS.

<mglt>
I have the impression some text is nee= ded to define how the transport is determined.
I favor that port is bein= g specified in
this field as opposed to in the prefix.
I also believe= that the port number
should not be defined at two distinct
places.

These two port n= umbers have separate meanings: the prefix is an "input" identifyi= ng the service, and the SvcParam is an "output" that locates the = endpoint.

<mglt>
I agree, what I was trying to say is that the default port is defin= ed from the transport, but the text does not indicate how transport is deri= ved. I suppose that a reference to the alpn section could be added as well = as an order in which the parameters needs to be looked at.
</m= glt>=C2=A0
It seems that the d= efault values depends
on other SvcParameters - alpn or absence
of it.= =C2=A0

Correct= : in this draft, there is no single default value for "port".=C2= =A0 Instead, in the absence of a specified port, each transport uses its ow= n default port.=C2=A0 This enables a single SVCB record to represent both D= NS over TLS on port 853 and DNS over HTTPS on port 443, as in the draft'= ;s first example:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0_dns.resolver 7200 IN SVCB 1 resolver alpn=3Dh2,h3 echconfig=3D... dohpa= th=3D/dns-query{?dns}

(This example enables DN= S over TLS on port 853 implicitly.)

We could chang= e default behavior for "port", but it would likely make typical u= sages more verbose.=C2=A0
<mglt>
I am fine with this, this matches my understanding.
<= /mglt>=C2=A0

=C2=A0 =C2=A0= This key is automatically mandatory if present.

<mglt>
I mi= ght be missing some context here,
but the latest sentence is a bit hard<= br>for me to understand.

The condition " if present" seems=
contradicting the term "mandatory". I
cannot figure out al= so what
automatically mandatory means.

</mglt>

Yes, "automatically ma= ndatory" is a specific term from the SVCB draft:=C2=A0https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02#section-= 7.=C2=A0 I've added a cross-reference for clarity:=C2=A0https://github.com/bemasc/svcb-dns/commit/535df7= 22c9404413020af34d3d0e7209e3a206c1
=C2=A0

<mglt>= ;
ok, will look at it.
</mglt>=C2=A0
4.2. =C2=A0alpn and no-default-alpn

=C2=A0 =C2=A0= These keys indicate the set of supported protocols.=C2=A0 The default
= =C2=A0 =C2=A0protocol is "dot", indicating support for DNS over T= LS [DOT].

=C2=A0 =C2=A0If the protocol set contains any HTTP version= s (e.g. "h2", "h3"),
=C2=A0 =C2=A0then the record in= dicates support for DNS over HTTPS [DOH], and the
=C2=A0 =C2=A0"doh= path" key MUST be present (Section 5.1).=C2=A0 All keys specified for<= br>=C2=A0 =C2=A0use with the HTTPS record are also permissible, and apply t= o the
=C2=A0 =C2=A0resulting HTTP connection.

<mglt>
I b= elieve the text may specify the
absence of alpn means DNS over UDP.

If the "alpn"= key is absent, the default is "dot".
=C2=A0
I am
unsure whether no-default-alpn means
that alpn key is omitted= or not, but if
that is the case, it does not seem
necessary to intro= duce its designation.

The default ALPN is "dot", so "no-default-alpn" = means "DNS over TLS is not supported".=C2=A0 If the "alpn&qu= ot; key is then omitted, the record is useless/null: it indicates no suppor= ted protocols at the alternative endpoint, so no client will ever attempt t= o make use of that record.
=C2=A0
<= div><mglt>
I think some text could=C2=A0be added to specify= the meaning of no-default-alpn in the context of this spec.

=
I am wondering in light of comments provided earlier, if one cou= ld not consider alpn mandatory and when omitted meaning Do53. This would re= move the need to define no-default and include Do53 as a potential service.= =C2=A0
</mglt>
=C2=A0
<= div>Instead it might be clear enough to
mention the alpn default value c= onsiders
DNS over UDP.

=
This draft does not currently offer any way to describe a DNS ov= er UDP alternative endpoint.
<mglt>= ;
I think I start seeing this, but I am still not convinced this = is appropriated to consider Do53 as different from other services.=C2=A0
</mglt>=C2=A0

It also worth mentioning that alpn needs
to be parsed before port and= potential
dohpath.
</mglt>

I expect that a client would parse a record comple= tely before attempting to make use of it, so I'm not concerned with thi= s dependency.
<mglt>
Par= sing was maybe inappropriate, but I would=C2=A0say start looking at alpn be= fore looking at port.
</mglt>=C2=A0

4.3.=C2=A0 Other applicable SvcParamKeys

=C2= =A0 =C2=A0These SvcParamKeys apply to the "dns" scheme without mo= dification:

=C2=A0 =C2=A0* =C2=A0echconfig

=C2=A0 =C2=A0* =C2= =A0ipv4hint

=C2=A0 =C2=A0* =C2=A0ipv6hint

<mglt>
not= sure we need this section as the
document is limited on the DNS
tran= sport.

Yes, thi= s is perhaps redundant.=C2=A0 We could instead adjust the wording in the SV= CB draft to indicate that these keys are assumed to be broadly applicable.= =C2=A0 However, I don't think it hurts to remind the reader of other ke= ys that they can use in this context.

I am howev= er wondering if we should
distinguish between authoritative and
resol= ver. =C2=A0

Thi= s draft is not intended to be specific to one server role or the other.=C2= =A0 This is noted in Section 6.

<mglt>
= I am wondering if ther is any room for
searching specifically doh server= by
requesting:

_443._dns.resolver 7200 IN SVCB 1 resolver (
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alpn=3Dh2,h3 echconfig=3D... dohpa= th=3D/dns-query{?dns} )

If that is not the case, it seems we
shou= ld clarify this.
The same case occurs with DoT, Do53.

The advanta= ge would be that it enables
to narrow down the search and prevents
th= e search of non supported transports.

This is an interesting idea, but the SVCB framework = does not support this approach.=C2=A0 With SVCB, the client sends a request= that=C2=A0describes a logical service, and receives an RRSet of alternativ= e endpoints covering all the service's supported protocols.
=
<mglt>
I understand that _443._dns = does not represent DoH for example. but instead a service=C2=A0DNS can coul= d (eventually) be DoT.=C2=A0 =C2=A0In other words, with standard ports _443= ._dns does not exist.
I am wondering if this a choice we make - a= nd that could be otherwise - or if there are a higher philosophy that makes= us take this path - from svcb-https. If so, and for clarification, I am wo= ndering if the definition of DoH as a service would require the definition = of _doh for example. I do not necessarily thinks here this is a good idea.<= /div>

One thing that remains unclear to me is the relati= on between URL scheme and service. Currently the port indicate sthe protoco= l (DoT, DoH,=C2=A0 ) which makes it difficult to have DoT on port 6777. I a= m wondering how this matters.=C2=A0=C2=A0
<mglt>=C2=A0

The downside is that it requires= some
synchronization between SVCB RRsets and
when multiple supports = are supported by
one client multiple queries may be
performed. It als= o may require to define
some preference across SVCB RRsets over
multi= ple domains.

Pe= rsonally, I expect that servers will typically implement only a small numbe= r of protocols (at most ~4), and clients will often support more than one, = so transferring the entire configuration in a single RRSet seems likely to = be more efficient overall than issuing multiple queries.

<mglt>
One aspect that I ha= ve not seen in the spec is the SVCB 0 and I expect this to be used to deleg= ate to third parties that will host multiple instances of the service. What= I think my increase the size of the number of service instances is the ser= vices associated to the DNS resolution service.=C2=A0

<= div></mglt>=C2=A0
</mglt= >

9.=C2=A0 Security Considerations

9.1.=C2=A0 Adversary on= the query path

=C2=A0 =C2=A0This section considers an adversary who= can add or remove responses
=C2=A0 =C2=A0to the SVCB query.

=C2= =A0 =C2=A0Clients MUST authenticate the server to its name during secure=C2=A0 =C2=A0transport establishment.=C2=A0 This name is the hostname used= to construct
=C2=A0 =C2=A0the original SVCB query, and cannot be influe= nced by the SVCB record
=C2=A0 =C2=A0contents. =C2=A0
<mglt>I understand that after the SVCB
exchange, the DNS client sets a TLSsession with the DNS server. I think
this is only valid when TLS is
= supported and Do53 woudl not fit in this
category.
=

Yes.=C2=A0 This draft does not provi= de a way to describe a Do53 alternative endpoint.

It sounds to me difficult to have a
requirement that says, when a http= s
server supports https the session must
be authenticated.

I'm not sure I understand= .=C2=A0 Authenticated transport is a requirement for HTTPS.
<mglt>
I do not think it is possible no= t to authenticate either, so it might not be necessary to require such auth= entication. It is a nit.=C2=A0
</mglt>=C2=A0
=C2=A0
I am tempted to say
that the https se= rver should not serve
non secure sessions. On the other hand,
one can= also envisioned the case where
a given IP/FQDN is shared by DoH and
= Do53, which makes such assumption
difficult.
Unless I am missing some= thing, it sounds
to me the MUST statement is difficult to enforce.

This section is only= meant to tell clients to perform SSL certificate validation in the usual w= ay.
=C2=A0
I think it is good to specify what namemust be present in the certificate.
Though what is unclear to me is why= the
name should be the one of the query as
opposed as the one in the= RDATA.

The RDA= TA is potentially untrusted.=C2=A0 In the=C2=A0absence of DNSSEC, an interm= ediary could rewrite the RDATA to contain any name.
<mglt>
I think the reasoning should be provided= with a recommendation as it assumed the input is provided in a trusted way= and that DNSSEC is not enabled.=C2=A0 =C2=A0
</mglt>=C2=A0=

I understand the text as say= ing that
connecting to fooexp.resolver.example, the
certificate shoul= d have
resolver.example.

Correct.
=C2=A0
If that is correct,
and = unless I am missing something, I
would be more inclined to authenticate<= br>fooexp.resolver.example.
One case I see is an ISP delegating to a
= DNS resolver provider - like akamai. It
should rather let the user authe= nticate
akamai than the ISP hostname. Other
scenario could ignore the= hostname and
use a footprint or the entire
certificate.
Of course= this would require DNSSEC.

It seems such recommendation is limited<= br>to the case when DNSSEC is not used and
when the SVCB name is provisi= oned in a
trusted manner.
<= br>
Yes.=C2=A0 However, the service provider does not know that t= he name was provisioned insecurely, and it does not know that the client is= validating DNSSEC, so it has to include the service name in its certificat= e.=C2=A0 Since all service providers will place the service name in the cer= tificate, clients should check for this name, regardless of whether they va= lidate DNSSEC.

<mglt&g= t;

Unless I am missing something, it seems to me t= he responsibility of the DNS client to perform the appropriated checks. If = the service provider is resolver.com,= =C2=A0it's responsibility seems limited to serve the request it receive= s.=C2=A0
The responsibility of the DNS client is to make sure the= re is a trusted delegation to the provider. That the service name isp.resol= ver is in the certificate is only one way to do so and put the constraints = too high on the service provider - in my opinion. I would add this as a rec= ommendation.=C2=A0

A typical use case may be a res= olver redirecting to public resolvers.=C2=A0
</mglt>=C2=A0<= br>
=C2=A0
If an attacker is likel= y
to update the SCVB content, he might
potentially have provided the = false
entry to initiate the SVCB query, in
which case there may not b= e any need to
update the SVCB parameters.

I believe the primary r= ecommendation should be
to use DNSSEC and then consider the very
spec= ific use case where DNSSEC cannot be
used with a trusted SVCB entry. =C2= =A0
</mglt>

This draft's approach to authentication is inherited from SVCB, w= hich similarly does not rely on DNSSEC.=C2=A0 In both cases, I think the cu= rrent drafts are taking the best approach.=C2=A0 In many or most of the ant= icipated applications, DNSSEC is not widely deployed, and we do not need it= in order to deploy SVCB securely.
<m= glt>
I do not believe that seems appropriated in the scope of = DNS to explicitly not consider DNSSEC not being used. The application is qu= estion is the discovery of resolvers and there is no specific reasons it do= es not implement DNSSEC. Though I admit it is unclear to me why the browser= industry is so reluctant to DNSSEC.=C2=A0=C2=A0
</mglt>=C2= =A0

=C2=A0 =C2=A0Although= this adversary cannot alter the authentication name of the
=C2=A0 =C2= =A0server, it does have control of the port number and "dohpath" = value.
=C2=A0 =C2=A0As a result, the adversary can direct DNS queries fo= r $HOSTNAME to
=C2=A0 =C2=A0any port on $HOSTNAME, and any path on "= ;https://$HOSTNAME", even if
=C2=A0 =C2=A0$HOSTNAME is not actually= a DNS server.=C2=A0 If the DNS client uses
=C2=A0 =C2=A0shared TLS or H= TTP state, the client could be correctly authenticated
=C2=A0 =C2=A0(e.g= . using a TLS client certificate or HTTP cookie).

=C2=A0 =C2=A0This = behavior creates a number of possible attacks for certain server
=C2=A0 = =C2=A0configurations.=C2=A0 For example, if "https://$HOSTNAME/upload&= quot; accepts
=C2=A0 =C2=A0any POST request as a file upload, the advers= ary could forge a SVCB
=C2=A0 =C2=A0record containing "dohpath=3D/u= pload", causing the client to upload
=C2=A0 =C2=A0every query, resu= lting in unexpected storage costs.

=C2=A0 =C2=A0As a mitigation, a c= lient of this SVCB mapping MUST NOT provide
=C2=A0 =C2=A0client authenti= cation for DNS queries, except to servers that it
=C2=A0 =C2=A0specifica= lly knows are not vulnerable to such attacks.=C2=A0 Also, if an
=C2=A0 = =C2=A0alternative service endpoint sends an invalid response to a DNS
= =C2=A0 =C2=A0query, the client SHOULD NOT send more queries to that endpoin= t.

<mglt>
The attack is limited to DoH and DoT is
not co= ncerned.

Correc= t.=C2=A0

This attack is targeting the https
s= erver, but in general the motivation
for the client to authenticate the<= br>server is to protect its privacy. It
seems this should be added or cl= arified.
</mglt>

OK, I've added an explanation of why this is privacy-relevant an= d strengthened the recommendation:=C2=A0https://github.com/bemasc/svcb-dns/commit/e311a4e94edd67e17724e693ad2038= 396fba8b4f


--
Daniel Migault
Ericsson
--0000000000008a15ad05b56f2758-- From nobody Wed Dec 2 13:29:30 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54C23A1795 for ; Wed, 2 Dec 2020 13:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jMAsKFV4lh9 for ; Wed, 2 Dec 2020 13:29:14 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C773A17AC for ; Wed, 2 Dec 2020 13:27:04 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id t13so2940696ilp.2 for ; Wed, 02 Dec 2020 13:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NRV/rld/myZyzqgUGJLq8RLkHGrEdGE6alYfWsLHfsw=; b=Ho2cwf28qDniGv35EyVzaUt4/PqDG8bSMweNMwJYq1by9iaptsr/h8EE+2zuSlb0Ho 3kh5Jjhhu1gicuryPzkg7QDOYCQCcqKpz+BAzcXdhiWVIsNvBnpoGchXnYKNshptMXjV r4BoW0hi7nINRowowJZaB72pXES7OL6025/8jH6wihIn7yzph7B9v3pibt+9VuKNwRl0 /jz1X9Oe7xtcQe5zAdt28VzuhC+e4c2XgssSqPlSyU3G8+899KYlttrjlLfLbEquGmuh faoVM3pVBD2EkitfpttJ8W7rPS71nf5n/1mU0i+Of6lAFPh8aUMZOBIoBu2XZvbwOMS+ a9NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NRV/rld/myZyzqgUGJLq8RLkHGrEdGE6alYfWsLHfsw=; b=sSnSqZN4Chh3dGBPr+qb1LNfrxSf3WscCMsNCGDfiWdd2WXwxkLLLUjYuXx5hxxFgR I2mljuzgkvJB/D0xUDvONuxF7gu/nGnXEq4p0JrTGKK/SqMZiQ3MDI4lWNudhcruvot4 9MLpA2LkmiVwPFMGIfyhxv/AYrAU+pH716Tv8ureKS0ppyzIN+HQiweBeilT2ap+uOJK 2iPksgbXMXCKXxfWtvKiIL2e5Zd/J22EXfbAMZHFzw7M6ofkosVapBoKn3Kgu4S/k52n X6iZAe88k3WWcSYO5vcc/qj5kY9kdef6KD7Rwtt+EYIxghLDZ66gYL4D41gUgu72NNN1 1fHQ== X-Gm-Message-State: AOAM531SfqpJm8XsEGsGdmRrheKZbq7CkSnYkbQYtoiZku52Rj6ZP7wq VkDIIpRBBOAIE8xik8y4e+QC0KhpfaQGsddtodsPBA== X-Google-Smtp-Source: ABdhPJx//+WGYuL8oyohfnWqYh76OKEtj3Urw2TwggZSvhuUwRz1Yefo7EoK+VoEYfmLDCWH9iyjSC5G/F/tFneh2e4= X-Received: by 2002:a92:d5c5:: with SMTP id d5mr4230545ilq.24.1606944422844; Wed, 02 Dec 2020 13:27:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Wed, 2 Dec 2020 16:26:50 -0500 Message-ID: To: Daniel Migault Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000089fb7c05b581e77c" Archived-At: Subject: Re: [Add] draft-schwartz-svcb-dns-01 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 21:29:28 -0000 --00000000000089fb7c05b581e77c Content-Type: multipart/alternative; boundary="0000000000007fbdd305b581e737" --0000000000007fbdd305b581e737 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 1, 2020 at 6:04 PM Daniel Migault wrote: > Thanks for the response. Please see additional information / comment > inline. > > Yours, > Daniel > > On Mon, Nov 30, 2020 at 2:57 PM Ben Schwartz wrote: > >> >> >> On Wed, Nov 25, 2020 at 5:10 PM Daniel Migault >> wrote: >> >>> Hi, >>> >>> Please find my comments below for draft-schwartz-svcb-dns-01 >>> >> >> Thanks for the detailed review. >> >> Yours, >>> Daniel >>> Service Binding Mapping for DNS Servers >>> draft-schwartz-svcb-dns-01 >>> [...] >>> >>> 1. Introduction >>> >>> The SVCB record type [SVCB] provides clients with information about >>> how to reach alternative endpoints for a service, which may have >>> improved performance or privacy properties. >>> >>> >>> It is unclear to me if "alternative" >>> means "various flavors of DNS resolvers" >>> or if it assumes the previous knowledge >>> of one flavor of the resolver. I do not >>> believe the latest is appropriated. >>> >> >> This is a general summary of SVCB. When using SVCB, there is a single >> logical "service" that can be accessed via different "endpoints". I'm not >> sure what you mean by "flavor", but SVCB assumes that the service's >> behavior does not greatly depend on which endpoint you use to access it. >> >> > Maybe I am using unappropriated language, but I see the dns resolution > service as being declined into different "flavors" or "(sub) services" like > Do53, DoH, DoT. But I think my question was regarding the term > "alternate". It i sunclear if alternate hee means "different" or if they > are taking the place of something in which case who they are taking the > place to. > > The word "alternative" here means "in addition to some default". You're right that it's not strictly necessary for there to be a default, but presumably a default will be present when adding SVCB to any use case that already exists, because existing clients will not support SVCB. > > > > >> The input of a SVCB query is a FQDN, and >>> that FQDN is not necessarily related to >>> a Do53 resolver for example. It could >>> typically an entry point used to >>> discover all different flavors of DNS >>> resolvers. Assuming a previous knowledge >>> of one resolver seems to preclude some >>> assumption on the FQDN, which seems >>> independent from the description of SVCB >>> fro DNS. >>> >>> >> >> Sorry, I'm still not understanding, possibly because I do not understand >> the idea of a "flavor". The draft assumes a DNS server (or "service") >> identified by a domain name, with Do53 service available via A and AAAA >> records for that name (if a Do53 service exists, which seems likely to be >> common but is not required). >> > > > It seems to me that the draft considers as the entry point the FQDN > associated to the Do53 server, that is in your example below. > I agree: that's how it's described, and I expect that to be the main use case. > resolver.example is the Do53 service and requesting resolver.example/AAAA > will give me the IP address I need to send the DNS requests to. > > $ORIGIN example. > _dns.resolver 7200 IN SVCB 1 resolver ( > alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} ) > _dns.resolver 7200 IN SVCB 2 resolver ( > port=8530 echconfig=... ) > _dns.resolver 7200 IN SVCB 3 fooexp.resolver ( port=5353 > echconfig=... alpn=foo no-default-alpn foo-info=... ) > > If my understanding is correct, there are two questions I am wondering: > > 1) Why do we mandate that the input of the SVCB query - in your example > resolver.example - needs to be associated to the Do53 server. > I don't think the draft contains such a mandate, but I do think that's likely to be true in most use cases. > I do not think that should be in the specification as mandatory and and > would consider this as simply good to know. > > I do see the following hierarchy: > DNS resolution > v v v > DoH resolvers DoT resolvers, Do53 resolvers > v v v > IPs, IPs, IPs > > In this case I would consider the _dns.example, _53._dns.foo, > _853._dns.foobar .. as services. > In SVCB's terminology, these are all endpoints of a single service, which is defined by its ability to provide access to particular information. These endpoints all represent the same service because they all provide the same DNS behavior. The choice of transport is hidden behind an abstraction barrier: a DNS client does not care which transport is used, so the transport can be selected independent of the query. Just as the HTTP content layer doesn't care whether the transport is HTTP/1.1, HTTP/2, or HTTP/3, the DNS content layer doesn't care whether the transport is DoT, DoH, etc. A request for all DNS servers associated to the FQDN example would be > _dns.example > A request for all DoT servers associated to the FQDN foorbar would be > _853._dns.foobar > A request for all Do53 servers associated to the FQDN foo would be > _53._dns.foo > This is a conceivable design, but it is not the design considered by SVCB. I prefer the SVCB approach (a single query returns all options), which seems conceptually and operationally simpler. I seems to me that a request for foo AAA is configured to return the IP > addresses of one server under _53._dns as a feature to provide some sort of > retrocompatibility with legacy Do53 resolvers but it seems unclear to me > why this should be required. > It is not required by this draft, but it is a common case, and may be required in some use cases. For example, authoritative DNS servers are already identified in NS records by a name that resolves to the IPs of the port 53 service. If SVCB-for-DNS is applied there in some fashion, backwards compatibility will require that Do53 service remain available on the IPs for that name. Just to make myself clear, I do see the FQDN example as representing the > input for searching the various available services. an example is then - at > least to me - different than the FQDN associated to the terminating Do53 > server. Having them equal is "nice" if we want to provide a FQDN to a > device that may do requests of type SVCB or AAAA. Unless I am missing > something, it seems that legacy devices take an IP address - not an FQDN - > and so we do not need to have such compatibility with legacy devices. > There are a variety of client types with different compatibility requirements. For example, Android phones allow the user to enter the hostname of a DNS-over-TLS server, which the phone will resolve to an IP and connect on port 853. For backwards compatibility with that mode of deployment, port 53 service is not required, but A/AAAA records (and port 853 TLS service on those IPs) are required. This draft does not attempt to lay out all the compatibility requirements for each potential use case. It merely describes the format used for the SVCB records, and leaves most of the questions of how they can be deployed to other drafts (such as DEER). 2) I am wondering how Do53 server are represented in SVCB. > In the current draft, they are not. The only way to use Do53 is when a compatible SVCB record is not available. > It seems to me that different Do53 DNS server may still be offered with > different SvcParameters and so should be listed with SVCB RRsets. > This is a possible design, but I would prefer to avoid including Do53. Do53 is not a secure or privacy-preserving transport, which makes it radically different from DoT, DoH, DNS over QUIC, etc. Just as SVCB does not support insecure HTTP, I think it makes sense to avoid adding support for insecure DNS transport. When a service is identified by name, I think we should be ensuring that we are actually communicating with the named service. With Do53, we have no ability to do this. In some configurations, allowing Do53 in SVCB would create a security vulnerability. In addition, I would favor Do53 is explicitly mention so that went it is > not deployed, the DNS client can actually knows this explicitly. > I don't think this is necessary. The draft already says: A client that attempts a connection using an encrypted DNS transport from a SVCB record SHOULD NOT fall back to unencrypted DNS if connection fails. (https://tools.ietf.org/html/draft-schwartz-svcb-dns-01#section-9.2) Therefore, the existence of a Do53 service is typically irrelevant to SVCB-enabled clients when SVCB records are present: they will not use it, whether or not it exists. > >> >> The service is >>> identified by a "scheme" indicating the service type, a hostname, and >>> optionally other information such as a port number. A DNS server is >>> often identified only by its IP address (e.g. in DHCP), but in some >>> contexts it can also be identified by a hostname (e.g. "NS" records, >>> manual resolver configuration). >>> >>> >>> I like the paragraph, but I believe it >>> might help the reader to add that DNS >>> servers can be authoritative or resolver >>> which are quite common term. I am >>> wondering however, if there are any >>> reasons for not mentioning them. >>> >>> >>> >> >> This is a deliberate omission: this draft is concerned only with DNS as a >> protocol, not with the types of queries and responses that are encoded. In >> principle, this SVCB mapping can be applied independently of whether the >> server is authoritative for any names, or supports recursion. >> > > Ok so that is an editorial choice. I am wondering though, if that would be > a nosense to have a SvcParameter saying whether the end point is a > resolver, authoritative, forwarder - either here or somewhere else. > > I think that is a possibility, but I don't see an immediate need for it, so I haven't defined such a SvcParamKey. In every existing use case, the client already knows whether it is going to set the "recursion desired" bit in its queries. If we find a use case that requires such an indication, we can extend the mapping at that time. > Names are formed using Port-Prefix Naming ([SVCB] Section 2.3). For >>> example, a DNS server with the name "dns1.example.com", listening >>> (unusually) on non-default port number 5353, would be represented as >>> "_5353._dns.dns1.example.com.". >>> >>> >>> While this seems conform to the SVCB >>> spec ;-) I would have envisioned the >>> port number prefix as designating the >>> service rather that actual port on which >>> the service is run. Typically in Do53 >>> would be designated as _53._dns and if >>> that service is run on port 5353 I would >>> expected the number being provide by the >>> port SvcParameter. >>> >> >> The port SvcParam is also supported, but its meaning is different. The >> port prefix identifies the service. The port SvcParam provides the >> location of the alternative endpoint. >> > > This seems to be my understanding. , but then "_5353._dns.dns1.example.com." > seems to me misleading as 5353 represents while the text mentions the > server is listening to an unusual port. My expectation was that a DNS > server was listening on 5353 instead of 53. From my understanding of the > text I would have expected to have 5353 in the SvcParameter. > I think more text is needed here to disambiguate the signification of the > port. Currently what we designate as the port does not seem to be the port. > I would expect some clarification on where the port is defined. > OK, I've attempted to clarify that we are speaking here about the port number that identifies the service, as opposed to the port number used to connect to the alternative endpoint: https://github.com/bemasc/svcb-dns/commit/fb867ece57236028b8e78496429ef50f3100f1cb > > >> >> One specific reason for doing so is that >>> the unconventional port cannot be >>> guessed without previous knowledge. >>> >> >> If the client has not been specifically informed that the service's >> identity contains an unconventional port, it will assume the default port >> (53), and query for SVCB records at _dns.$SERVER_NAME (no port prefix). >> Each SVCB record returned may contain a port SvcParamKey indicating where >> to find that alternative service endpoint. >> > > This requires so two entries _dns.${server} and _5353._dns.${server} - > probably CNAMed. > The second entry would only exist if the operator has been advertising ${server}:5353 as a DNS service. If this service is equivalent to the service at ${server}:53, then the operator could simply publish a CNAME as you describe. However, if the two ports operate differently (e.g. with different behaviors or policies), then they would need separate sets of alternative endpoints. > I think the notation is mixing service and implementation of the service, > and I am wondering if there are any reasons we need to do that here in this > spec. > I view this as clearly separating the identity of the service from its implementation. The service is identified by a hostname and a port number (encoded in the QNAME), and its implementation is located by a hostname and a port number (the TargetName, port=...). These hostnames and port numbers can be the same or different; they are independent. Similarly, it seems to me that the convention to have port 53 as a default > port is a convention that is specified in this document and that we could > define it otherwise. If so, given that the service can be DoT, DoH, DoQ. I > am wondering why couldn't we define _dns as the service abstraction of DNS > that could be declined in DoT, DoH Do53.... without precluding a default > port. > I'm not sure I understand this, but the draft is indeed designed so that the vast majority of operators will never need to use a port prefix name or a port SvcParam. An explicit port prefix is only needed when the DNS service is identified by a non-default port number, and an explicit port SvcParam is only needed when operating an alternative endpoint on a non-default port number. I also believe that the port needs to explicitly mention how the port value > is handled in _port._dns > I don't think I understand this question. > > >> >> I believe that some specific convention >>> should considers that _dns may designate >>> the DNS service including all flavors. >>> >> >> As above, I don't understand what is meant by a "flavor". >> > > flavor meant to me DoT, DoQ, DoH, Do53... > > >> >> >>> This key is used to indicate the target port for connection. If >>> omitted, the client SHALL use the default port for each transport >>> protocol: 853 for DNS over TLS and 443 for DNS over HTTPS. >>> >>> >>> I have the impression some text is needed to define how the transport is >>> determined. >>> I favor that port is being specified in >>> this field as opposed to in the prefix. >>> I also believe that the port number >>> should not be defined at two distinct >>> places. >>> >> >> These two port numbers have separate meanings: the prefix is an "input" >> identifying the service, and the SvcParam is an "output" that locates the >> endpoint. >> >> > I agree, what I was trying to say is that the default port is defined from > the transport, but the text does not indicate how transport is derived. > OK, I've swapped the "alpn" and "port" sections so that the reader learns how transports are selected before encountering that concept in the "port" section ( https://github.com/bemasc/svcb-dns/commit/02c0c474bedab28f892d535a40a095fc3367ea52 ). > I suppose that a reference to the alpn section could be added as well as > an order in which the parameters needs to be looked at. > > ... > 4.2. alpn and no-default-alpn >>> >>> These keys indicate the set of supported protocols. The default >>> protocol is "dot", indicating support for DNS over TLS [DOT]. >>> >>> If the protocol set contains any HTTP versions (e.g. "h2", "h3"), >>> then the record indicates support for DNS over HTTPS [DOH], and the >>> "dohpath" key MUST be present (Section 5.1). All keys specified for >>> use with the HTTPS record are also permissible, and apply to the >>> resulting HTTP connection. >>> >>> >>> I believe the text may specify the >>> absence of alpn means DNS over UDP. >>> >> >> If the "alpn" key is absent, the default is "dot". >> >> >>> I am >>> unsure whether no-default-alpn means >>> that alpn key is omitted or not, but if >>> that is the case, it does not seem >>> necessary to introduce its designation. >>> >> >> The default ALPN is "dot", so "no-default-alpn" means "DNS over TLS is >> not supported". If the "alpn" key is then omitted, the record is >> useless/null: it indicates no supported protocols at the alternative >> endpoint, so no client will ever attempt to make use of that record. >> >> > > I think some text could be added to specify the meaning of no-default-alpn > in the context of this spec. > I'd rather not duplicate the explanation of these keys, but I've added a cross-reference to the original source: https://github.com/bemasc/svcb-dns/commit/4c7509333b7d1279c6f59b1fd80531712e1010a0 > I am wondering in light of comments provided earlier, if one could not > consider alpn mandatory and when omitted meaning Do53. This would remove > the need to define no-default and include Do53 as a potential service. > > I think that would be possible, if we want to support insecure transports. > Instead it might be clear enough to >>> mention the alpn default value considers >>> DNS over UDP. >>> >> >> This draft does not currently offer any way to describe a DNS over UDP >> alternative endpoint. >> > > I think I start seeing this, but I am still not convinced this is > appropriated to consider Do53 as different from other services. > > >> >> It also worth mentioning that alpn needs >>> to be parsed before port and potential >>> dohpath. >>> >>> >> >> I expect that a client would parse a record completely before attempting >> to make use of it, so I'm not concerned with this dependency. >> > > Parsing was maybe inappropriate, but I would say start looking at alpn > before looking at port. > > I don't think there's a clear ordering requirement there. A compliant client must inspect both keys, and could do so in either order. > 4.3. Other applicable SvcParamKeys >>> >>> These SvcParamKeys apply to the "dns" scheme without modification: >>> >>> * echconfig >>> >>> * ipv4hint >>> >>> * ipv6hint >>> >>> >>> not sure we need this section as the >>> document is limited on the DNS >>> transport. >>> >> >> Yes, this is perhaps redundant. We could instead adjust the wording in >> the SVCB draft to indicate that these keys are assumed to be broadly >> applicable. However, I don't think it hurts to remind the reader of other >> keys that they can use in this context. >> >> I am however wondering if we should >>> distinguish between authoritative and >>> resolver. >>> >> >> This draft is not intended to be specific to one server role or the >> other. This is noted in Section 6. >> >> >>> I am wondering if ther is any room for >>> searching specifically doh server by >>> requesting: >>> >>> _443._dns.resolver 7200 IN SVCB 1 resolver ( >>> alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} ) >>> >>> If that is not the case, it seems we >>> should clarify this. >>> The same case occurs with DoT, Do53. >>> >>> The advantage would be that it enables >>> to narrow down the search and prevents >>> the search of non supported transports. >>> >> >> This is an interesting idea, but the SVCB framework does not support this >> approach. With SVCB, the client sends a request that describes a logical >> service, and receives an RRSet of alternative endpoints covering all the >> service's supported protocols. >> > > I understand that _443._dns does not represent DoH for example. but > instead a service DNS can could (eventually) be DoT. In other words, with > standard ports _443._dns does not exist. > I am wondering if this a choice we make - and that could be otherwise - or > if there are a higher philosophy that makes us take this path - from > svcb-https. If so, and for clarification, I am wondering if the definition > of DoH as a service would require the definition of _doh for example. I do > not necessarily thinks here this is a good idea. > I think we are trying to build a machine that takes three inputs -- (1) a service identity, (2) a set of alternative endpoints, and (3) the client's capabilities -- and arranges a successful connection. 1. The DNS service identity consists of a hostname and (very rarely) a port number. 2. Each alternative endpoint consists of a hostname, a port number (often default), various transport layers (DoT, DoH, HTTP/2, HTTP/3, etc.), and potentially other parameters (e.g. echconfig) 3. The client's capabilities include the set of supported transports, the set of supported protocols within those transports, and possibly other relevant capabilities (e.g. ECH) In SVCB, the client sends (1) in the QNAME, gets back (2), and applies (3) locally to identify an optimal connection. In your proposal, the client would send (1) and also part of (3) in the QNAME, get back a subset of (2), and then apply any remaining filtering locally. That would work too, but I think it's more complicated. It also creates tricky possibilities for skew: operators would need to be careful when changing their records, because changes are no longer atomic. One thing that remains unclear to me is the relation between URL scheme and > service. Currently the port indicate sthe protocol (DoT, DoH, ) which > makes it difficult to have DoT on port 6777. I am wondering how this > matters. > > Yes, in my view you would need a QNAME that contains "_dns", "_dot", the hostname, and the identifying port number (if non-default port number identities are supported). The downside is that it requires some >>> synchronization between SVCB RRsets and >>> when multiple supports are supported by >>> one client multiple queries may be >>> performed. It also may require to define >>> some preference across SVCB RRsets over >>> multiple domains. >>> >> >> Personally, I expect that servers will typically implement only a small >> number of protocols (at most ~4), and clients will often support more than >> one, so transferring the entire configuration in a single RRSet seems >> likely to be more efficient overall than issuing multiple queries. >> >> > One aspect that I have not seen in the spec is the SVCB 0 and I expect > this to be used to delegate to third parties that will host multiple > instances of the service. What I think my increase the size of the number > of service instances is the services associated to the DNS resolution > service. > > > For these purposes I think SVCB 0 is the same as a CNAME, but at the apex name. Delegation is already possible with CNAME; SVCB 0 just allows the use of shorter service names. > >>> >>> 9. Security Considerations >>> >>> 9.1. Adversary on the query path >>> >>> This section considers an adversary who can add or remove responses >>> to the SVCB query. >>> >>> Clients MUST authenticate the server to its name during secure >>> transport establishment. This name is the hostname used to construct >>> the original SVCB query, and cannot be influenced by the SVCB record >>> contents. >>> >>> I understand that after the SVCB >>> exchange, the DNS client sets a TLS >>> session with the DNS server. I think >>> this is only valid when TLS is >>> supported and Do53 woudl not fit in this >>> category. >>> >> >> Yes. This draft does not provide a way to describe a Do53 alternative >> endpoint. >> >> It sounds to me difficult to have a >>> requirement that says, when a https >>> server supports https the session must >>> be authenticated. >>> >> >> I'm not sure I understand. Authenticated transport is a requirement for >> HTTPS. >> > > I do not think it is possible not to authenticate either, so it might not > be necessary to require such authentication. It is a nit. > > Yes, the point of this sentence is only to identify the name used for authentication: the service name, not the TargetName. I am tempted to say >>> that the https server should not serve >>> non secure sessions. On the other hand, >>> one can also envisioned the case where >>> a given IP/FQDN is shared by DoH and >>> Do53, which makes such assumption >>> difficult. >>> Unless I am missing something, it sounds >>> to me the MUST statement is difficult to enforce. >>> >> >> This section is only meant to tell clients to perform SSL certificate >> validation in the usual way. >> >> >>> I think it is good to specify what name >>> must be present in the certificate. >>> Though what is unclear to me is why the >>> name should be the one of the query as >>> opposed as the one in the RDATA. >>> >> >> The RDATA is potentially untrusted. In the absence of DNSSEC, an >> intermediary could rewrite the RDATA to contain any name. >> > > I think the reasoning should be provided with a recommendation as it > assumed the input is provided in a trusted way and that DNSSEC is not > enabled. > > I don't think that's true. The draft only assumes that the input _might_ be provided in a trusted way, and DNSSEC _might_ not be enabled. I understand the text as saying that >>> connecting to fooexp.resolver.example, the >>> certificate should have >>> resolver.example. >>> >> >> Correct. >> >> >>> If that is correct, >>> and unless I am missing something, I >>> would be more inclined to authenticate >>> fooexp.resolver.example. >>> One case I see is an ISP delegating to a >>> DNS resolver provider - like akamai. It >>> should rather let the user authenticate >>> akamai than the ISP hostname. Other >>> scenario could ignore the hostname and >>> use a footprint or the entire >>> certificate. >>> Of course this would require DNSSEC. >>> >>> It seems such recommendation is limited >>> to the case when DNSSEC is not used and >>> when the SVCB name is provisioned in a >>> trusted manner. >>> >> >> Yes. However, the service provider does not know that the name was >> provisioned insecurely, and it does not know that the client is validating >> DNSSEC, so it has to include the service name in its certificate. Since >> all service providers will place the service name in the certificate, >> clients should check for this name, regardless of whether they validate >> DNSSEC. >> > > > > Unless I am missing something, it seems to me the responsibility of the > DNS client to perform the appropriated checks. > Yes, but the client and server need to agree on what those checks are _before_ they start communicating, so the standards need to tell them what to do. If the service provider is resolver.com, it's responsibility seems limited > to serve the request it receives. > Note that the request it receives will be on a TLS connection whose SNI indicates the original DNS service name. > The responsibility of the DNS client is to make sure there is a trusted > delegation to the provider. That the service name isp.resolver is in the > certificate is only one way to do so and put the constraints too high on > the service provider - in my opinion. I would add this as a recommendation. > The use case you are describing is equivalent to a standard HTTPS CDN (and indeed may be an HTTPS CDN when the transport is DoH). In this case, just as in HTTPS, the CDN must present a certificate that is valid for the customer's identity. It is not enough for the customer to CNAME their name to the CDN, because the CDN cannot assume that all customer zones are signed and all stub resolvers are DNSSEC-validating. (In fact, almost none are.) A typical use case may be a resolver redirecting to public resolvers. > > I think the idea of "redirection" is interesting here. SVCB is not a "redirection" mechanism. It provides alternative endpoints for the _same_ service; it does not redirect the user to a different service. As such, unlike HTTP 301, the client continues to validate the service's original identity, regardless of which endpoint it is talking to. > If an attacker is likely >>> to update the SCVB content, he might >>> potentially have provided the false >>> entry to initiate the SVCB query, in >>> which case there may not be any need to >>> update the SVCB parameters. >>> >>> I believe the primary recommendation should be >>> to use DNSSEC and then consider the very >>> specific use case where DNSSEC cannot be >>> used with a trusted SVCB entry. >>> >>> >> >> This draft's approach to authentication is inherited from SVCB, which >> similarly does not rely on DNSSEC. In both cases, I think the current >> drafts are taking the best approach. In many or most of the anticipated >> applications, DNSSEC is not widely deployed, and we do not need it in order >> to deploy SVCB securely. >> > > I do not believe that seems appropriated in the scope of DNS to explicitly > not consider DNSSEC not being used. > To be clear, nothing in this draft recommends against the use of DNSSEC. DNSSEC might even be required for some future standards that use this format, e.g. when using it in combination with DANE authentication. The application is question is the discovery of resolvers and there is no > specific reasons it does not implement DNSSEC. Though I admit it is unclear > to me why the browser industry is so reluctant to DNSSEC. > > As long as there is little deployment of validating stub resolvers, it should not be surprising that new drafts do not assume the opposite. RFC 8027 lays out some of the common reasons why stub resolvers cannot enforce DNSSEC validation. (I would add performance considerations: the latency cost of followup queries to chase the DNSSEC chain is considerably higher for client devices (e.g. phones on GSM wireless) than for recursive resolvers.) However, I do think that SVCB for DNS can have a positive impact on DNSSEC deployment via a mechanism like DEER. By enabling clients to use encrypted DNS, we can avoid the network problems that prevent stub resolvers from relying on DNSSEC. >> Although this adversary cannot alter the authentication name of the >>> server, it does have control of the port number and "dohpath" value. >>> As a result, the adversary can direct DNS queries for $HOSTNAME to >>> any port on $HOSTNAME, and any path on "https://$HOSTNAME", even if >>> $HOSTNAME is not actually a DNS server. If the DNS client uses >>> shared TLS or HTTP state, the client could be correctly authenticated >>> (e.g. using a TLS client certificate or HTTP cookie). >>> >>> This behavior creates a number of possible attacks for certain server >>> configurations. For example, if "https://$HOSTNAME/upload" accepts >>> any POST request as a file upload, the adversary could forge a SVCB >>> record containing "dohpath=/upload", causing the client to upload >>> every query, resulting in unexpected storage costs. >>> >>> As a mitigation, a client of this SVCB mapping MUST NOT provide >>> client authentication for DNS queries, except to servers that it >>> specifically knows are not vulnerable to such attacks. Also, if an >>> alternative service endpoint sends an invalid response to a DNS >>> query, the client SHOULD NOT send more queries to that endpoint. >>> >>> >>> The attack is limited to DoH and DoT is >>> not concerned. >>> >> >> Correct. >> >> This attack is targeting the https >>> server, but in general the motivation >>> for the client to authenticate the >>> server is to protect its privacy. It >>> seems this should be added or clarified. >>> >>> >> >> OK, I've added an explanation of why this is privacy-relevant and >> strengthened the recommendation: >> https://github.com/bemasc/svcb-dns/commit/e311a4e94edd67e17724e693ad2038396fba8b4f >> > > > -- > Daniel Migault > Ericsson > --0000000000007fbdd305b581e737 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 1, 2020 at 6:04 PM Daniel= Migault <mglt.= ietf@gmail.com> wrote:
Thanks for the response. Pl= ease see additional information / comment inline.=C2=A0

Yours,=C2=A0
Daniel

On Mon, Nov 30, 2020 at 2:57 PM Be= n Schwartz <bemas= c@google.com> wrote:


On Wed, Nov 25, 2020 at 5= :10 PM Daniel Migault <mglt.ietf@gmail.com> wrote:
Hi,=C2=A0

Pl= ease find my comments below for=C2=A0draft-schwartz-svcb-dns-01
=

Thanks for the detailed review.
=
Yours,=C2=A0
Daniel
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Service Binding Mapping for DNS Serv= ers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0draft-schwartz-svcb-dns-01
[...]

1.=C2=A0 Introd= uction

=C2=A0 =C2=A0The SVCB record type [SVCB] provides clients wit= h information about
=C2=A0 =C2=A0how to reach alternative endpoints for = a service, which may have
=C2=A0 =C2=A0improved performance or privacy p= roperties. =C2=A0

<mglt>
It is unclear to me if "alter= native"
means "various flavors of DNS resolvers"
or if= it assumes the previous knowledge
of one flavor of the resolver. I do n= ot
believe the latest is appropriated.

This is a general summary of SVCB.=C2=A0 When us= ing SVCB, there is a single logical "service" that can be accesse= d via different "endpoints".=C2=A0 I'm not sure what you mean= by "flavor", but SVCB assumes that the service's behavior do= es not greatly depend on which endpoint you use to access it.
<mglt>
Maybe I am usin= g unappropriated language, but I see the dns resolution service as being de= clined into different "flavors" or "(sub) services" lik= e Do53, DoH, DoT.=C2=A0 But I think my question was regarding=C2=A0the term= "alternate". It i sunclear if alternate hee means "differen= t" or if they are taking the place of something=C2=A0in which=C2=A0cas= e who they are taking the place to.=C2=A0
=C2=A0</mglt>

The word "alternative&qu= ot; here means "in addition to some default".=C2=A0 You're ri= ght that it's not strictly necessary for there to be a default, but pre= sumably a default will be present when adding SVCB to any use case that=C2= =A0already exists, because existing clients will not support SVCB.
=C2=A0

</mglt>
=C2=A0
The input of a SVCB= query is a FQDN, and
that FQDN is not necessarily related to
a Do53 = resolver for example. It could
typically an entry point used to
disco= ver all different flavors of DNS
resolvers. Assuming a previous knowledg= e
of one resolver seems to preclude some
assumption on the FQDN, whic= h seems
independent from the description of SVCB
fro DNS. =C2=A0 =C2= =A0 =C2=A0
</mglt>
Sorry, I'm still not understanding, possibly because I do = not understand the idea of a "flavor".=C2=A0 The draft assumes a = DNS server (or "service") identified by a domain name, with Do53 = service available via A and AAAA records for that name (if a Do53 service e= xists, which seems likely to be common but is not required).

<mglt>
It seems to me t= hat the draft considers as the entry point the FQDN associated to the Do53 = server, that is=C2=A0in=C2=A0your example below.=C2=A0

I agree: that's how it's descri= bed, and I expect that to be the main use case.
=C2=A0
resolver.example is the Do53 service and requesting= resolver.example/AAAA will give me the IP address I need to send the DNS r= equests to.=C2=A0

=C2=A0 $ORIGIN example.
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_dns.resolver 7200 IN SVCB 1 resolver (
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alpn=3Dh2,h3 echconfig=3D... dohpa= th=3D/dns-query{?dns} )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_dns.resolver = 7200 IN SVCB 2 resolver (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0port= =3D8530 echconfig=3D... )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_dns.resolve= r 7200 IN SVCB 3 fooexp.resolver ( port=3D5353
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0echconfig=3D... alpn=3Dfoo no-default-alpn foo-info=3D... = )

If my understanding is correct, there are tw= o questions I am wondering:

1) Why do we mandate t= hat the input of the SVCB query - in your example resolver.example - needs = to be associated to the Do53 server.

I don't think the draft contains such a mandate, but = I do think that's likely to be true in most use cases.
=C2=A0=
I do not think that should be in the sp= ecification as mandatory and and would consider this as simply good to know= .=C2=A0

I do see the following hierarchy:
DNS resolution=C2=A0
=C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
DoH= resolvers=C2=A0 DoT resolvers, Do53 resolvers
=C2=A0 =C2=A0 =C2= =A0 v=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2=A0=C2=A0
IPs,=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPs,=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IPs

In this case I would consider the=C2=A0 _dns.example, _53._dns.foo= , _853._dns.foobar .. as services.=C2=A0

In SVCB's terminology, these are all endpoi= nts of a single service, which is defined by its ability to provide access = to particular information.=C2=A0 These endpoints all represent the same ser= vice because they all provide the same DNS behavior.=C2=A0 The choice of tr= ansport is hidden behind an abstraction barrier: a DNS client does not care= which transport is used, so the transport can be selected independent of t= he query.=C2=A0 Just as the HTTP content layer doesn't care whether the= transport is HTTP/1.1, HTTP/2, or HTTP/3, the DNS content layer doesn'= t care whether the transport is DoT, DoH, etc.

A request for all DNS servers associated to the FQDN = example would be=C2=A0 _dns.example
A request for all DoT servers= associated to the FQDN foorbar would be=C2=A0 _853._dns.foobar
<= /div>
A request for all Do53 servers associated to the FQDN foo wo= uld be=C2=A0 _53._dns.foo
This is a conceivable design, but it is not the design conside= red by SVCB.=C2=A0 I prefer the SVCB approach (a single query returns all o= ptions), which seems conceptually and operationally simpler.

=
I seems to me that a request for fo= o AAA is configured to return the IP addresses of one server under _53._dns= as a feature to provide some sort of retrocompatibility with legacy Do53 r= esolvers but it seems unclear to me why this should be required.=C2=A0

It is not require= d by this draft, but it is a common case, and may be required in some use c= ases.=C2=A0 For example, authoritative DNS servers are already identified i= n NS records by a name that resolves to the IPs of the port 53 service.=C2= =A0 If SVCB-for-DNS is applied there in some fashion, backwards compatibili= ty will require that Do53=C2=A0service remain available on the IPs for that= name.

Just to make m= yself=C2=A0clear, I do see the FQDN example as representing the input for s= earching the various available services. an example is then - at least to m= e - different than the FQDN associated to the terminating Do53 server.=C2= =A0 Having them equal is "nice" if we want to provide a FQDN to a= device that may do requests of type SVCB or AAAA. Unless I am missing some= thing, it seems that legacy devices take an IP address - not an FQDN - and = so we do not need to have such compatibility with legacy devices.=C2=A0=C2= =A0

There are= a variety of client types with different compatibility requirements.=C2=A0= For example, Android phones allow the user to enter the hostname of a DNS-= over-TLS server, which the phone will resolve to an IP and connect on port = 853.=C2=A0 For backwards compatibility with that mode of deployment, port 5= 3 service is not required, but A/AAAA records (and port 853 TLS service on = those IPs) are required.

This draft does not attem= pt to lay out all the compatibility requirements for each potential use cas= e.=C2=A0 It merely describes the format used for the SVCB records, and leav= es most of the questions of how they can be deployed to other drafts (such = as DEER).

2) I am won= dering how Do53 server are represented in SVCB.

In the current draft, they are not.=C2= =A0 The only way to use Do53 is when a compatible SVCB record is not availa= ble.
=C2=A0
It seems to m= e that different Do53 DNS server may still be offered with different SvcPar= ameters and so should be listed with SVCB RRsets.

This is a possible design, but I would= prefer to avoid including Do53.=C2=A0 Do53 is not a secure or privacy-pres= erving transport, which makes it radically different from DoT, DoH, DNS ove= r QUIC, etc.=C2=A0 Just as SVCB does not support insecure HTTP, I think it = makes sense to avoid adding support for insecure DNS transport.
<= br>
When a service is identified by name, I think we should be en= suring that we are actually communicating with the named service.=C2=A0 Wit= h Do53, we have no ability to do this.=C2=A0 In some configurations, allowi= ng Do53 in SVCB would create a security vulnerability.

=
In addition, I would favor Do53 is expli= citly mention so that went it is not deployed, the DNS client can actually = knows this explicitly.=C2=A0=C2=A0

I don't think this is necessary.=C2=A0 The draft = already says:

=C2=A0 =C2=A0A client that attempts = a connection using an encrypted DNS transport
=C2=A0 =C2=A0from a SVCB r= ecord SHOULD NOT fall back to unencrypted DNS if
=C2=A0 =C2=A0connection= fails.


Therefore, the existence of a Do53 service is typically irrelevant t= o SVCB-enabled clients when SVCB records are present: they will not use it,= whether or not it exists.

</mglt>

The service is=
=C2=A0 =C2=A0identified by a "scheme" indicating the service = type, a hostname, and
=C2=A0 =C2=A0optionally other information such as = a port number.=C2=A0 A DNS server is
=C2=A0 =C2=A0often identified only = by its IP address (e.g. in DHCP), but in some
=C2=A0 =C2=A0contexts it c= an also be identified by a hostname (e.g. =C2=A0"NS" records,
= =C2=A0 =C2=A0manual resolver configuration).

<mglt>
I like = the paragraph, but I believe it
might help the reader to add that DNSservers can be authoritative or resolver
which are quite common term. I= am
wondering however, if there are any
reasons for not mentioning th= em.

</mglt>

<= /div>
This is a deliberate omission: this draft is concerned only with = DNS as a protocol, not with the types of queries and responses that are enc= oded.=C2=A0 In principle, this SVCB mapping can be applied independently of= whether the server is authoritative for any names, or supports recursion.<= /div>
<mglt>
Ok so that is an = editorial choice. I am wondering though, if that would be a nosense=C2=A0to= have a SvcParameter saying whether the end point is a resolver, authoritat= ive, forwarder - either here or somewhere else.
</mglt>=C2=A0
=

I think that is a possibility, but I= don't see an immediate need for it, so I haven't defined such a Sv= cParamKey.=C2=A0 In every existing use case, the client already knows wheth= er it is going to set the "recursion desired" bit in its queries.= =C2=A0 If we find a use case that requires such an indication, we can exten= d the mapping at that time.
=C2=A0
=C2=A0 =C2=A0Names are formed using Port-Prefix Naming = ([SVCB] Section 2.3).=C2=A0 For
=C2=A0 =C2=A0example, a DNS server with = the name "dns1.= example.com", listening
=C2=A0 =C2=A0(unusually) on non-default= port number 5353, would be represented as
=C2=A0 =C2=A0"_5353._dns.dns1.example.co= m.".

<mglt>
While this seems conform to the SVCBspec ;-) I would have envisioned the
port number prefix as designating= the
service rather that actual port on which
the service is run. Typ= ically in Do53
would be designated as _53._dns and if
that service is= run on port 5353 I would
expected the number being provide by the
po= rt SvcParameter.

The port SvcParam is also supported, but its meaning is different.=C2=A0 = The port prefix identifies the service.=C2=A0 The port SvcParam provides th= e location of the alternative endpoint.
= <mglt>
This seems to be my understanding. , but then "= _5353._dns.dns1.e= xample.com." seems to me misleading=C2=A0as 5353 represents while = the text mentions the server is listening to an unusual=C2=A0port. My expec= tation was that a DNS server was listening on 5353 instead of 53. From my u= nderstanding of the text I would have expected to have 5353 in the SvcParam= eter.=C2=A0
I think more text is needed here to disambiguate the = signification of the port. Currently what we designate as the port does not= seem to be the port. I would expect some clarification on where the port i= s defined.=C2=A0

OK, I= 9;ve attempted to clarify that we are speaking here about the port number t= hat identifies the service, as opposed to the port number used to connect t= o the alternative endpoint:=C2=A0http= s://github.com/bemasc/svcb-dns/commit/fb867ece57236028b8e78496429ef50f3100f= 1cb
=C2=A0
</mglt>=C2= =A0

One specific reason for d= oing so is that
the unconventional port cannot be
guessed without pre= vious knowledge.

If the client has not been specifically informed that the service's i= dentity contains an unconventional port, it will assume the default port (5= 3), and query for SVCB records at _dns.$SERVER_NAME (no port prefix).=C2=A0= Each SVCB record returned may contain a port SvcParamKey indicating where = to find that alternative service endpoint.
<mglt>
This requires so two entries _dns.${server} and _= 5353._dns.${server} - probably CNAMed.
=

The second entry would only exist if the operator has b= een advertising ${server}:5353 as a DNS service.=C2=A0 If this service is e= quivalent to the service at ${server}:53, then the operator could simply pu= blish a CNAME as you describe.=C2=A0 However, if the two ports operate diff= erently (e.g. with different behaviors or policies), then they would need s= eparate sets of alternative endpoints.
=C2=A0
I think the notation is mixing service and implementati= on of the service, and I am wondering if there are any reasons we need to d= o that here in this spec.=C2=A0
I view this as clearly separating the identity of the service = from its implementation.=C2=A0 The service is identified by a hostname and = a port number (encoded in the QNAME), and its implementation is located by = a hostname and a port number (the TargetName, port=3D...).=C2=A0 These host= names and port numbers can be the same or different; they are independent.<= /div>

Similarly, it seems to me = that the convention to have port 53 as a default port is a convention that = is specified in this document and that we could define it otherwise. If so,= given that the service can be DoT, DoH, DoQ. I am wondering why couldn'= ;t we define _dns as the service abstraction of DNS that could be declined = in DoT, DoH Do53.... without precluding a default port.=C2=A0=C2=A0

I'm not sure I underst= and this, but the draft is indeed designed so that the vast majority of ope= rators will never need to use a port prefix name or a port SvcParam.=C2=A0 = An explicit port prefix is only needed when the DNS service is identified b= y a non-default port number, and an explicit port SvcParam is only needed w= hen operating an alternative endpoint on a non-default port number.

I also believe that the port need= s to explicitly mention how the port value is handled in _port._dns

I don't think I unders= tand this question.
=C2=A0
<= /mglt>=C2=A0

I believe tha= t some specific convention
should considers that _dns may designate
t= he DNS service including all flavors.

As above, I don't understand what is meant by a = "flavor".
<mglt>
flavor meant to me DoT, DoQ, DoH, Do53...
</mglt>=C2=A0<= /div>
=C2=A0
=C2=A0 =C2=A0This key is us= ed to indicate the target port for connection.=C2=A0 If
=C2=A0 =C2=A0omi= tted, the client SHALL use the default port for each transport
=C2=A0 = =C2=A0protocol: 853 for DNS over TLS and 443 for DNS over HTTPS.

<= ;mglt>
I have the impression some text is needed to define how the tr= ansport is determined.
I favor that port is being specified in
this f= ield as opposed to in the prefix.
I also believe that the port numbershould not be defined at two distinct
places.

These two port numbers have separate mea= nings: the prefix is an "input" identifying the service, and the = SvcParam is an "output" that locates the endpoint.

=
<mglt>
I agree, what I = was trying to say is that the default port is defined from the transport, b= ut the text does not indicate how transport is derived.

OK, I've swapped the "alpn&qu= ot; and "port" sections so that the reader learns how transports = are selected before encountering that concept in the "port" secti= on (https://github.com/bemasc/svcb-dn= s/commit/02c0c474bedab28f892d535a40a095fc3367ea52).
=C2= =A0
I suppose that a reference to the al= pn section could be added as well as an order in which the parameters needs= to be looked at.
</mglt>=C2=A0

...=C2=A0
4.2. =C2=A0alpn and no-default-alpn

=C2=A0 =C2=A0= These keys indicate the set of supported protocols.=C2=A0 The default
= =C2=A0 =C2=A0protocol is "dot", indicating support for DNS over T= LS [DOT].

=C2=A0 =C2=A0If the protocol set contains any HTTP version= s (e.g. "h2", "h3"),
=C2=A0 =C2=A0then the record in= dicates support for DNS over HTTPS [DOH], and the
=C2=A0 =C2=A0"doh= path" key MUST be present (Section 5.1).=C2=A0 All keys specified for<= br>=C2=A0 =C2=A0use with the HTTPS record are also permissible, and apply t= o the
=C2=A0 =C2=A0resulting HTTP connection.

<mglt>
I b= elieve the text may specify the
absence of alpn means DNS over UDP.

If the "alpn"= key is absent, the default is "dot".
=C2=A0
I am
unsure whether no-default-alpn means
that alpn key is omitted= or not, but if
that is the case, it does not seem
necessary to intro= duce its designation.

The default ALPN is "dot", so "no-default-alpn" = means "DNS over TLS is not supported".=C2=A0 If the "alpn&qu= ot; key is then omitted, the record is useless/null: it indicates no suppor= ted protocols at the alternative endpoint, so no client will ever attempt t= o make use of that record.
=C2=A0
<= div><mglt>
I think some text could=C2=A0be added to specify= the meaning of no-default-alpn in the context of this spec.

I'd rather not duplicate the = explanation of these keys, but I've added a cross-reference to the orig= inal source:=C2=A0https://github.com/= bemasc/svcb-dns/commit/4c7509333b7d1279c6f59b1fd80531712e1010a0
=C2=A0
I am wondering in light of co= mments provided earlier, if one could not consider alpn mandatory and when = omitted meaning Do53. This would remove the need to define no-default and i= nclude Do53 as a potential service.=C2=A0
</mglt>

I think that would be possib= le, if we want to support insecure transports.
=C2=A0=C2=A0
=
Instead it might be clear enou= gh to
mention the alpn default value considers
DNS over UDP.

This draft does not cur= rently offer any way to describe a DNS over UDP alternative endpoint.
=
<mglt>
I think I start seeing= this, but I am still not convinced this is appropriated to consider Do53 a= s different from other services.=C2=A0
</mglt>=C2=A0

It also worth mentioning that a= lpn needs
to be parsed before port and potential
dohpath.
</mgl= t>

I expect = that a client would parse a record completely before attempting to make use= of it, so I'm not concerned with this dependency.
<mglt>
Parsing was maybe inappropriate, but = I would=C2=A0say start looking at alpn before looking at port.
&l= t;/mglt>=C2=A0

I don&#= 39;t think there's a clear ordering requirement there.=C2=A0 A complian= t client must inspect both keys, and could do so in either order.
=C2=A0
4.3.=C2=A0 Other = applicable SvcParamKeys

=C2=A0 =C2=A0These SvcParamKeys apply to the= "dns" scheme without modification:

=C2=A0 =C2=A0* =C2=A0e= chconfig

=C2=A0 =C2=A0* =C2=A0ipv4hint

=C2=A0 =C2=A0* =C2=A0i= pv6hint

<mglt>
not sure we need this section as the
docu= ment is limited on the DNS
transport.

Yes, this is perhaps redundant.=C2=A0 We could in= stead adjust the wording in the SVCB draft to indicate that these keys are = assumed to be broadly applicable.=C2=A0 However, I don't think it hurts= to remind the reader of other keys that they can use in this context.

I am however wondering if we should
distinguish = between authoritative and
resolver. =C2=A0

This draft is not intended to be specific to= one server role or the other.=C2=A0 This is noted in Section 6.
=
<mglt>
I am wondering if ther is any room for
= searching specifically doh server by
requesting:

_443._dns.resolv= er 7200 IN SVCB 1 resolver (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0al= pn=3Dh2,h3 echconfig=3D... dohpath=3D/dns-query{?dns} )

If that is n= ot the case, it seems we
should clarify this.
The same case occurs wi= th DoT, Do53.

The advantage would be that it enables
to narrow do= wn the search and prevents
the search of non supported transports.

This is an interesti= ng idea, but the SVCB framework does not support this approach.=C2=A0 With = SVCB, the client sends a request that=C2=A0describes a logical service, and= receives an RRSet of alternative endpoints covering all the service's = supported protocols.
<mglt>
<= div>I understand that _443._dns does not represent DoH for example. but ins= tead a service=C2=A0DNS can could (eventually) be DoT.=C2=A0 =C2=A0In other= words, with standard ports _443._dns does not exist.
I am wonder= ing if this a choice we make - and that could be otherwise - or if there ar= e a higher philosophy that makes us take this path - from svcb-https. If so= , and for clarification, I am wondering if the definition of DoH as a servi= ce would require the definition of _doh for example. I do not necessarily t= hinks here this is a good idea.

I think we are trying to build a machine that takes three inputs -- = (1) a service identity, (2) a set of alternative endpoints, and (3) the cli= ent's capabilities -- and arranges a successful connection.
<= br>
1. The DNS service identity consists of a hostname and (very = rarely) a port number.
2. Each alternative endpoint consists of a= hostname, a port number (often default), various transport layers (DoT, Do= H, HTTP/2, HTTP/3, etc.), and potentially other parameters (e.g. echconfig)=
3. The client's capabilities include the set of supported tr= ansports, the set of supported protocols within those transports, and possi= bly other relevant capabilities (e.g. ECH)

In SVCB= , the client sends (1) in the QNAME, gets back (2), and applies (3) locally= to identify an optimal connection.

In your propos= al, the client would send (1) and also part of (3) in the QNAME, get back a= subset of (2), and then apply any remaining filtering locally.=C2=A0 That = would work too, but I think it's more complicated.=C2=A0 It also create= s tricky possibilities for skew: operators would need to be careful when ch= anging their records, because changes are no longer atomic.

<= /div>
One thing that remains unclear to me is the re= lation between URL scheme and service. Currently the port indicate sthe pro= tocol (DoT, DoH,=C2=A0 ) which makes it difficult to have DoT on port 6777.= I am wondering how this matters.=C2=A0=C2=A0
<mglt>=C2=A0<= /div>

Yes, in my view you would= need a QNAME that contains "_dns", "_dot", the hostnam= e, and the identifying port number (if non-default port number identities a= re supported).

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
The downside is that it requires some
synchronization between SVCB= RRsets and
when multiple supports are supported by
one client multip= le queries may be
performed. It also may require to define
some prefe= rence across SVCB RRsets over
multiple domains.

Personally, I expect that servers will = typically implement only a small number of protocols (at most ~4), and clie= nts will often support more than one, so transferring the entire configurat= ion in a single RRSet seems likely to be more efficient overall than issuin= g multiple queries.

<m= glt>
One aspect that I have not seen in the spec is the SVCB 0= and I expect this to be used to delegate to third parties that will host m= ultiple instances of the service. What I think my increase the size of the = number of service instances is the services associated to the DNS resolutio= n service.=C2=A0

</mglt>=C2=A0

For these purposes I think SVCB 0 is t= he same as a CNAME, but at the apex name.=C2=A0 Delegation is already possi= ble with CNAME; SVCB 0 just allows the use of shorter service names.
<= div>=C2=A0
&l= t;/mglt>

9.=C2=A0 Security Considerations

9.1.=C2=A0 Adver= sary on the query path

=C2=A0 =C2=A0This section considers an advers= ary who can add or remove responses
=C2=A0 =C2=A0to the SVCB query.
<= br>=C2=A0 =C2=A0Clients MUST authenticate the server to its name during sec= ure
=C2=A0 =C2=A0transport establishment.=C2=A0 This name is the hostnam= e used to construct
=C2=A0 =C2=A0the original SVCB query, and cannot be = influenced by the SVCB record
=C2=A0 =C2=A0contents. =C2=A0
<mglt&= gt;
I understand that after the SVCB
exchange, the DNS client sets a = TLS
session with the DNS server. I think
this is only valid when TLS = is
supported and Do53 woudl not fit in this
category.
=

Yes.=C2=A0 This draft does not= provide a way to describe a Do53 alternative endpoint.

It sounds to me difficult to have a
requirement that says, when = a https
server supports https the session must
be authenticated.

I'm not sure I unde= rstand.=C2=A0 Authenticated transport is a requirement for HTTPS.
<mglt>
I do not think it is possi= ble not to authenticate either, so it might not be necessary to require suc= h authentication. It is a nit.=C2=A0
</mglt>=C2=A0

Yes, the point of this sentence i= s only to identify the name used for authentication: the service name, not = the TargetName.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I am tempted to say
that the https server should not serve
non= secure sessions. On the other hand,
one can also envisioned the case wh= ere
a given IP/FQDN is shared by DoH and
Do53, which makes such assum= ption
difficult.
Unless I am missing something, it sounds
to me th= e MUST statement is difficult to enforce.

This section is only meant to tell clients to pe= rform SSL certificate validation in the usual way.
=C2=A0
=
I think it is good to specify what name
must be present in the cert= ificate.
Though what is unclear to me is why the
name should be the o= ne of the query as
opposed as the one in the RDATA.

The RDATA is potentially untrusted.= =C2=A0 In the=C2=A0absence of DNSSEC, an intermediary could rewrite the RDA= TA to contain any name.
<mglt>
I think the reasoning should be provided with a recommendation as it= assumed the input is provided in a trusted way and that DNSSEC is not enab= led.=C2=A0 =C2=A0
</mglt>=C2=A0

I don't think that's true.=C2=A0 The draft o= nly assumes that the input _might_ be provided in a trusted way, and DNSSEC= _might_ not be enabled.

=
I understand the text as saying that
connecting to fooexp= .resolver.example, the
certificate should have
resolver.example.

Correct.
=C2= =A0
If that is correct,
and unless I am missing something, = I
would be more inclined to authenticate
fooexp.resolver.example.
= One case I see is an ISP delegating to a
DNS resolver provider - like ak= amai. It
should rather let the user authenticate
akamai than the ISP = hostname. Other
scenario could ignore the hostname and
use a footprin= t or the entire
certificate.
Of course this would require DNSSEC.
=
It seems such recommendation is limited
to the case when DNSSEC is n= ot used and
when the SVCB name is provisioned in a
trusted manner.

Yes.=C2=A0 Howeve= r, the service provider does not know that the name was provisioned insecur= ely, and it does not know that the client is validating DNSSEC, so it has t= o include the service name in its certificate.=C2=A0 Since all service prov= iders will place the service name in the certificate, clients should check = for this name, regardless of whether they validate DNSSEC.

<mglt>

Unl= ess I am missing something, it seems to me the responsibility of the DNS cl= ient to perform the appropriated checks.

Yes, but the client and server need to agree on what those = checks are _before_ they start communicating, so the standards need to tell= them what to do.

If the servi= ce provider is resolver.c= om,=C2=A0it's responsibility seems limited to serve the request it = receives.=C2=A0

Note that= the request it receives will be on a TLS connection whose SNI indicates th= e original DNS service name.
=C2=A0
= The responsibility of the DNS client is to make sure there is a trusted del= egation to the provider. That the service name isp.resolver is in the certi= ficate is only one way to do so and put the constraints too high on the ser= vice provider - in my opinion. I would add this as a recommendation.=C2=A0<= /div>

The use case you are desc= ribing is equivalent to a standard HTTPS CDN (and indeed may be an HTTPS CD= N when the transport is DoH).=C2=A0 In this case, just as in HTTPS, the CDN= must present a certificate that is valid for the customer's identity.= =C2=A0 It is not enough for the customer to CNAME their name to the CDN, be= cause the CDN cannot assume that all customer zones are signed and all stub= resolvers are DNSSEC-validating.=C2=A0 (In fact, almost none are.)

A typical use case may be a resolver r= edirecting to public resolvers.=C2=A0
</mglt>=C2=A0

I think the idea of "re= direction" is interesting here.=C2=A0 SVCB is not a "redirection&= quot; mechanism.=C2=A0 It provides alternative endpoints for the _same_ ser= vice; it does not redirect the user to a different service.=C2=A0 As such, = unlike HTTP 301, the client continues to validate the service's origina= l identity, regardless of which endpoint it is talking to.
=C2=A0= =C2=A0
If an attacke= r is likely
to update the SCVB content, he might
potentially have pro= vided the false
entry to initiate the SVCB query, in
which case there= may not be any need to
update the SVCB parameters.

I believe the= primary recommendation should be
to use DNSSEC and then consider the ve= ry
specific use case where DNSSEC cannot be
used with a trusted SVCB = entry. =C2=A0
</mglt>

This draft's approach to authentication is inherited fr= om SVCB, which similarly does not rely on DNSSEC.=C2=A0 In both cases, I th= ink the current drafts are taking the best approach.=C2=A0 In many or most = of the anticipated applications, DNSSEC is not widely deployed, and we do n= ot need it in order to deploy SVCB securely.
=
<mglt>
I do not believe that seems appropriated in the= scope of DNS to explicitly not consider DNSSEC not being used.
=

To be clear, nothing in this draft r= ecommends against the use of DNSSEC.=C2=A0 DNSSEC might even be required fo= r some future standards that use this format, e.g. when using it in combina= tion with DANE authentication.

= The application is question is the discovery of resolvers and there is no s= pecific reasons it does not implement DNSSEC. Though I admit it is unclear = to me why the browser industry is so reluctant to DNSSEC.=C2=A0=C2=A0
=
</mglt>=C2=A0

<= div>As long as there is little deployment of validating stub resolvers, it = should not be surprising that new drafts do not assume the opposite.=C2=A0 = RFC 8027 lays out some of the common reasons why stub resolvers cannot enfo= rce DNSSEC validation.=C2=A0 (I would add performance considerations: the l= atency cost of followup queries to chase the DNSSEC chain is considerably h= igher for client devices (e.g. phones on GSM wireless) than for recursive r= esolvers.)

However, I do think that SVCB for D= NS can have a positive impact on DNSSEC deployment via a mechanism like DEE= R.=C2=A0 By enabling clients to use encrypted DNS, we can avoid the network= problems that prevent stub resolvers from relying on DNSSEC.
<= div class=3D"gmail_quote">

=C2=A0 =C2=A0Although this adversary cannot alter the authentication nam= e of the
=C2=A0 =C2=A0server, it does have control of the port number an= d "dohpath" value.
=C2=A0 =C2=A0As a result, the adversary can= direct DNS queries for $HOSTNAME to
=C2=A0 =C2=A0any port on $HOSTNAME,= and any path on "https://$HOSTNAME", even if
=C2=A0 =C2=A0$HO= STNAME is not actually a DNS server.=C2=A0 If the DNS client uses
=C2=A0= =C2=A0shared TLS or HTTP state, the client could be correctly authenticate= d
=C2=A0 =C2=A0(e.g. using a TLS client certificate or HTTP cookie).
=
=C2=A0 =C2=A0This behavior creates a number of possible attacks for cer= tain server
=C2=A0 =C2=A0configurations.=C2=A0 For example, if "htt= ps://$HOSTNAME/upload" accepts
=C2=A0 =C2=A0any POST request as a f= ile upload, the adversary could forge a SVCB
=C2=A0 =C2=A0record contain= ing "dohpath=3D/upload", causing the client to upload
=C2=A0 = =C2=A0every query, resulting in unexpected storage costs.

=C2=A0 =C2= =A0As a mitigation, a client of this SVCB mapping MUST NOT provide
=C2= =A0 =C2=A0client authentication for DNS queries, except to servers that it<= br>=C2=A0 =C2=A0specifically knows are not vulnerable to such attacks.=C2= =A0 Also, if an
=C2=A0 =C2=A0alternative service endpoint sends an inval= id response to a DNS
=C2=A0 =C2=A0query, the client SHOULD NOT send more= queries to that endpoint.

<mglt>
The attack is limited to = DoH and DoT is
not concerned.

Correct.=C2=A0

This attack is = targeting the https
server, but in general the motivation
for the cli= ent to authenticate the
server is to protect its privacy. It
seems th= is should be added or clarified.
</mglt>

OK, I've added an explanation of why thi= s is privacy-relevant and strengthened the recommendation:=C2=A0https://github.com/bemasc/svcb-dns/commit/e311a4= e94edd67e17724e693ad2038396fba8b4f


--
Daniel Migault
Ericsson
--0000000000007fbdd305b581e737-- --00000000000089fb7c05b581e77c Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPmAYJKoZIhvcNAQcCoIIPiTCCD4UCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggzyMIIEtjCCA56gAwIBAgIQeAMYYHb81ngUVR0WyMTzqzANBgkqhkiG9w0BAQsFADBMMSAwHgYD VQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UE AxMKR2xvYmFsU2lnbjAeFw0yMDA3MjgwMDAwMDBaFw0yOTAzMTgwMDAwMDBaMFQxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFz IFIzIFNNSU1FIENBIDIwMjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvLe9xPU9W dpiHLAvX7kFnaFZPuJLey7LYaMO8P/xSngB9IN73mVc7YiLov12Fekdtn5kL8PjmDBEvTYmWsuQS 6VBo3vdlqqXZ0M9eMkjcKqijrmDRleudEoPDzTumwQ18VB/3I+vbN039HIaRQ5x+NHGiPHVfk6Rx c6KAbYceyeqqfuJEcq23vhTdium/Bf5hHqYUhuJwnBQ+dAUcFndUKMJrth6lHeoifkbw2bv81zxJ I9cvIy516+oUekqiSFGfzAqByv41OrgLV4fLGCDH3yRh1tj7EtV3l2TngqtrDLUs5R+sWIItPa/4 AJXB1Q3nGNl2tNjVpcSn0uJ7aFPbAgMBAAGjggGKMIIBhjAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFHzM CmjXouseLHIb0c1dlW+N+/JjMB8GA1UdIwQYMBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MHsGCCsG AQUFBwEBBG8wbTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AyLmdsb2JhbHNpZ24uY29tL3Jvb3Ry MzA7BggrBgEFBQcwAoYvaHR0cDovL3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvcm9vdC1y My5jcnQwNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIz LmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0BAQsFAAOCAQEANyYcO+9JZYyqQt41 TMwvFWAw3vLoLOQIfIn48/yea/ekOcParTb0mbhsvVSZ6sGn+txYAZb33wIb1f4wK4xQ7+RUYBfI TuTPL7olF9hDpojC2F6Eu8nuEf1XD9qNI8zFd4kfjg4rb+AME0L81WaCL/WhP2kDCnRU4jm6TryB CHhZqtxkIvXGPGHjwJJazJBnX5NayIce4fGuUEJ7HkuCthVZ3Rws0UyHSAXesT/0tXATND4mNr1X El6adiSQy619ybVERnRi5aDe1PTwE+qNiotEEaeujz1a/+yYaaTY+k+qJcVxi7tbyQ0hi0UB3myM A/z2HmGEwO8hx7hDjKmKbDCCA18wggJHoAMCAQICCwQAAAAAASFYUwiiMA0GCSqGSIb3DQEBCwUA MEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIzMRMwEQYDVQQKEwpHbG9iYWxTaWdu MRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAwMFoXDTI5MDMxODEwMDAwMFowTDEg MB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24xEzAR BgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMJXaQeQZ4 Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG4VKrDIFHcGzdZNHr9SyjD4I9DCuu l9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnLJlkNc96wyOkmDoMVxu9bi9IEYMpJ pij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDhBjPogiuuU6Y6FnOM3UEOIDrAtKeh 6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjRAjFhGV64l++td7dkmnq/X8ET75ti +w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0bvDANBgkqhkiG9w0BAQsFAAOCAQEA S0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAtrqQK0/Xx8Q+Kv3NnSoPHRHt44K9u bG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6DuM81IcPJaP7O2sJTqsyQiunwXUaM ld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCekTBtzc3b0F5nCH3oO4y0IrQocLP88 q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMfOjsl0oZAzjsshnjJYS8Uuu7bVW/f hO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBNEwggO5oAMCAQICEAE/JGAv3XK3SRaKvGds QSwwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gQXRsYXMgUjMgU01JTUUgQ0EgMjAyMDAeFw0yMDA5MDgy MzQzNTNaFw0yMTAzMDcyMzQzNTNaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFzY0Bnb29nbGUuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7rjWsiqQSnXGFTvs/2JDygQFtWsgF+Ce W2I/wmwCuWH2eNUBYslyudWmJsUMi7IbeSsKHrvBI2P7k6sk5p6o3uFlomiFaDMqXcn76t5GNGym CmHm5KBWxc3LfyvR4C2/wg9oUwbL2xxXc6QQpWWE4ONn9NMHwNC396Ih5u7tcrH5eF49HbVarP5i TindWAOzz++JA3VC/1lIkqWvOt2BcBtxQDUnYp8sr8UnMF/6UqtCd0aHJnKkvYi4o8Qo5Qf3YgiJ DzADzBTf54o3NAI3hiIVKPvz1l0g78IcR29Bt9jUrE33qGzGB6HoY7Z8quhA/ngW2XjuLkIY1ZKX AwTXBQIDAQABo4IBzzCCAcswHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5jb20wDgYDVR0PAQH/ BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQUu687mSaB85ui VgNNFSUhtTljkxEwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYmaHR0cHM6 Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wCQYDVR0TBAIwADCBmgYIKwYBBQUHAQEE gY0wgYowPgYIKwYBBQUHMAGGMmh0dHA6Ly9vY3NwLmdsb2JhbHNpZ24uY29tL2NhL2dzYXRsYXNy M3NtaW1lY2EyMDIwMEgGCCsGAQUFBzAChjxodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2Nh Y2VydC9nc2F0bGFzcjNzbWltZWNhMjAyMC5jcnQwHwYDVR0jBBgwFoAUfMwKaNei6x4schvRzV2V b4378mMwRgYDVR0fBD8wPTA7oDmgN4Y1aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9jYS9nc2F0 bGFzcjNzbWltZWNhMjAyMC5jcmwwDQYJKoZIhvcNAQELBQADggEBAG9R1/y5PatVOc8xLrAmGgNO /Q4+lbJuHNwX3aIpOkM72Ot4r6r5/IFOSx1pMpmzvrECyy5YQzUGkHV4atuNq5YPPNMGa+XlaKSg oU2dA6RCD40dtwmrPxrKiGAfHPNvfmRvgnx9qxBKFPbKF/Tn8BwKSZCSvx33TnQRfqLUTcgrAarQ dF9Oc45moJrn4nVF0VTTPI6LVminvjg3tLgF2bny1N6CitQnb1t67vpYjeNpcXNIGQzEDaYI3WnK rVeZMcLSY+Z2dQH8HvVsA95vFCTywgiWKq5KxFqz/GdB6JhDWcIJIKCJVUyqD/Bjx47+e4Ye/FuD NDSYc+613Ozl3TkxggJqMIICZgIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIEF0bGFzIFIzIFNNSU1FIENBIDIwMjACEAE/ JGAv3XK3SRaKvGdsQSwwDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIMNQjDuqoCXR s/f83tFO+dFUjAsYRHx6bTzF7detKQXHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTIwMTIwMjIxMjcwM1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJ YIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcN AQEHMAsGCWCGSAFlAwQCATANBgkqhkiG9w0BAQEFAASCAQDZ0/yukrL0z9NsNTERvBIa0hmou59s PP5DKPX6JyKh1AI7drZGxjxoHo0WPFQds8n6kt7oDgtj+T+KaMN2x7OF0j9DTC+/oSvceEZQ/0WC pWCfufOrN2Q2wppGFsjpXXGGe8PwBTr6qqGg5a6dYXGGuO6cZxsKaoRWnJ6BLorSSW7NQIAaikOG tNqzTQTPUhDQVjUDCHRbkgTIhS5g57nQRoA2/8dN82TfxQIcEBzTNTFv7W2/VWQ1ldsAroYsjvaw hvKKVFAimikSTdC6cGVFVSDQEUdOTU+JOUNJVL0lGu9z59FcvyzcwmgX0QqlwZxqAIBHCVn+tPqZ vtn7JSNG --00000000000089fb7c05b581e77c-- From nobody Fri Dec 4 10:22:53 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E23F3A0A83 for ; Fri, 4 Dec 2020 10:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTDzCG1Mvdou for ; Fri, 4 Dec 2020 10:22:47 -0800 (PST) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACA43A0A7E for ; Fri, 4 Dec 2020 10:22:46 -0800 (PST) Received: by mail-ua1-x92b.google.com with SMTP id x13so2158431uar.4 for ; Fri, 04 Dec 2020 10:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QNRSz94CCI7wMEn0u2PSDVezdHp4cr6ALUQoKIk4tro=; b=I/k6NoDh15JS+b5PWhf+6MoEyf6ir1SkbsBRcAO7oQHJQEEY6fU63dKtqnVfPtYTQq ftgQ+lF0/uQFieOKIiK+d+qumNsVPq9AaqeJIszCJayjLYbgNSNCNGquBfwe4B8bUJ4M RAka1l9kbcXA085iRlpSn4YaysQrG3YOGjFZryz33YKM293fHzLpT3T2QBYphdPGJCLd JCTcy+G80fqsMxD+e2lfKUOFoY/otU2ZrLwxNhd0hzn2H1TZlDOsIbZuK+TkDM9T0UPI VEEsCR3mLEn34eGpdKWssy7DwDvwmRBzmj6mwJshLwey+PcZmU33ywy8+CUyrdY+1f3A 55Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QNRSz94CCI7wMEn0u2PSDVezdHp4cr6ALUQoKIk4tro=; b=pzH8kctUnSvq/+sBymCSpcFIcllwOsyA9x1Kv6qcwc8AzxRBq8d0kz0PGVz3TMSpaP WqsoRETZMG/OjzKek+Sq3210+mHsM0AhLkNhLEvofLzV8SQx6raLc/S0qFmeAzN5xaFm lnWjOkyp2JgEgHwuBAmruYBMy7bZLo1vtEPllGg8PDhAY4FI7ztkJlnwATBpSxY5aT5g kgl5j2UQVvQ2Q2+6K3ouX2bgCwpLI/efoxCqkwwFKIpC6/h8UKOdvFVeI4fXCAi8RUj3 +GC1eBy2ss2dwyegJZcbZFf8GAfnjgmoP5m94Dvr1arrnlMTujShiKyig/LBGzwp2mSX D3Hw== X-Gm-Message-State: AOAM530l6WYWnDkT+NNlFZyeNfFNg/8OV/h8eLPCMInpOmXtbxExKnGt fHr0fWR5Azef75bgpeicwIn3PEO1H4UdI9vrftzgzzgi X-Google-Smtp-Source: ABdhPJx+dMqmd0Q/rm1P6n3vRTUhFFAyHZVPJUm0KYWKFs7Px9EFH1JTAzHUyZthrHRXjczxDeCHtRhRCFHC+YqLWVg= X-Received: by 2002:ab0:6285:: with SMTP id z5mr4739028uao.0.1607106165815; Fri, 04 Dec 2020 10:22:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Fri, 4 Dec 2020 13:22:34 -0500 Message-ID: To: Ben Schwartz Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000213f8e05b5a7908b" Archived-At: Subject: Re: [Add] draft-schwartz-svcb-dns-01 X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 18:22:52 -0000 --000000000000213f8e05b5a7908b Content-Type: text/plain; charset="UTF-8" Hi Ben, Thanks you very much for the responses and clarifications. I also agree that some points raised are a bit out of scope of the URI resolution as I tended to read the draft as more generic to the usage of SVCB in the context of _dns. These clarification are however useful for me and thank you for taking the time to respond. Yours, Daniel On Wed, Dec 2, 2020 at 4:27 PM Ben Schwartz wrote: > > > On Tue, Dec 1, 2020 at 6:04 PM Daniel Migault wrote: > >> Thanks for the response. Please see additional information / comment >> inline. >> >> Yours, >> Daniel >> >> On Mon, Nov 30, 2020 at 2:57 PM Ben Schwartz wrote: >> >>> >>> >>> On Wed, Nov 25, 2020 at 5:10 PM Daniel Migault >>> wrote: >>> >>>> Hi, >>>> >>>> Please find my comments below for draft-schwartz-svcb-dns-01 >>>> >>> >>> Thanks for the detailed review. >>> >>> Yours, >>>> Daniel >>>> Service Binding Mapping for DNS Servers >>>> draft-schwartz-svcb-dns-01 >>>> [...] >>>> >>>> 1. Introduction >>>> >>>> The SVCB record type [SVCB] provides clients with information about >>>> how to reach alternative endpoints for a service, which may have >>>> improved performance or privacy properties. >>>> >>>> >>>> It is unclear to me if "alternative" >>>> means "various flavors of DNS resolvers" >>>> or if it assumes the previous knowledge >>>> of one flavor of the resolver. I do not >>>> believe the latest is appropriated. >>>> >>> >>> This is a general summary of SVCB. When using SVCB, there is a single >>> logical "service" that can be accessed via different "endpoints". I'm not >>> sure what you mean by "flavor", but SVCB assumes that the service's >>> behavior does not greatly depend on which endpoint you use to access it. >>> >>> >> Maybe I am using unappropriated language, but I see the dns resolution >> service as being declined into different "flavors" or "(sub) services" like >> Do53, DoH, DoT. But I think my question was regarding the term >> "alternate". It i sunclear if alternate hee means "different" or if they >> are taking the place of something in which case who they are taking the >> place to. >> >> > > The word "alternative" here means "in addition to some default". You're > right that it's not strictly necessary for there to be a default, but > presumably a default will be present when adding SVCB to any use case > that already exists, because existing clients will not support SVCB. > > >> >> >> >> >>> The input of a SVCB query is a FQDN, and >>>> that FQDN is not necessarily related to >>>> a Do53 resolver for example. It could >>>> typically an entry point used to >>>> discover all different flavors of DNS >>>> resolvers. Assuming a previous knowledge >>>> of one resolver seems to preclude some >>>> assumption on the FQDN, which seems >>>> independent from the description of SVCB >>>> fro DNS. >>>> >>>> >>> >>> Sorry, I'm still not understanding, possibly because I do not understand >>> the idea of a "flavor". The draft assumes a DNS server (or "service") >>> identified by a domain name, with Do53 service available via A and AAAA >>> records for that name (if a Do53 service exists, which seems likely to be >>> common but is not required). >>> >> >> >> It seems to me that the draft considers as the entry point the FQDN >> associated to the Do53 server, that is in your example below. >> > > I agree: that's how it's described, and I expect that to be the main use > case. > > >> resolver.example is the Do53 service and requesting resolver.example/AAAA >> will give me the IP address I need to send the DNS requests to. >> >> $ORIGIN example. >> _dns.resolver 7200 IN SVCB 1 resolver ( >> alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} ) >> _dns.resolver 7200 IN SVCB 2 resolver ( >> port=8530 echconfig=... ) >> _dns.resolver 7200 IN SVCB 3 fooexp.resolver ( port=5353 >> echconfig=... alpn=foo no-default-alpn foo-info=... ) >> >> If my understanding is correct, there are two questions I am wondering: >> >> 1) Why do we mandate that the input of the SVCB query - in your example >> resolver.example - needs to be associated to the Do53 server. >> > > I don't think the draft contains such a mandate, but I do think that's > likely to be true in most use cases. > > >> I do not think that should be in the specification as mandatory and and >> would consider this as simply good to know. >> >> I do see the following hierarchy: >> DNS resolution >> v v v >> DoH resolvers DoT resolvers, Do53 resolvers >> v v v >> IPs, IPs, IPs >> >> In this case I would consider the _dns.example, _53._dns.foo, >> _853._dns.foobar .. as services. >> > > In SVCB's terminology, these are all endpoints of a single service, which > is defined by its ability to provide access to particular information. > These endpoints all represent the same service because they all provide the > same DNS behavior. The choice of transport is hidden behind an abstraction > barrier: a DNS client does not care which transport is used, so the > transport can be selected independent of the query. Just as the HTTP > content layer doesn't care whether the transport is HTTP/1.1, HTTP/2, or > HTTP/3, the DNS content layer doesn't care whether the transport is DoT, > DoH, etc. > > A request for all DNS servers associated to the FQDN example would be >> _dns.example >> A request for all DoT servers associated to the FQDN foorbar would be >> _853._dns.foobar >> A request for all Do53 servers associated to the FQDN foo would be >> _53._dns.foo >> > > This is a conceivable design, but it is not the design considered by > SVCB. I prefer the SVCB approach (a single query returns all options), > which seems conceptually and operationally simpler. > > I seems to me that a request for foo AAA is configured to return the IP >> addresses of one server under _53._dns as a feature to provide some sort of >> retrocompatibility with legacy Do53 resolvers but it seems unclear to me >> why this should be required. >> > > It is not required by this draft, but it is a common case, and may be > required in some use cases. For example, authoritative DNS servers are > already identified in NS records by a name that resolves to the IPs of the > port 53 service. If SVCB-for-DNS is applied there in some fashion, > backwards compatibility will require that Do53 service remain available on > the IPs for that name. > > Just to make myself clear, I do see the FQDN example as representing the >> input for searching the various available services. an example is then - at >> least to me - different than the FQDN associated to the terminating Do53 >> server. Having them equal is "nice" if we want to provide a FQDN to a >> device that may do requests of type SVCB or AAAA. Unless I am missing >> something, it seems that legacy devices take an IP address - not an FQDN - >> and so we do not need to have such compatibility with legacy devices. >> > > There are a variety of client types with different compatibility > requirements. For example, Android phones allow the user to enter the > hostname of a DNS-over-TLS server, which the phone will resolve to an IP > and connect on port 853. For backwards compatibility with that mode of > deployment, port 53 service is not required, but A/AAAA records (and port > 853 TLS service on those IPs) are required. > > This draft does not attempt to lay out all the compatibility requirements > for each potential use case. It merely describes the format used for the > SVCB records, and leaves most of the questions of how they can be deployed > to other drafts (such as DEER). > > 2) I am wondering how Do53 server are represented in SVCB. >> > > In the current draft, they are not. The only way to use Do53 is when a > compatible SVCB record is not available. > > >> It seems to me that different Do53 DNS server may still be offered with >> different SvcParameters and so should be listed with SVCB RRsets. >> > > This is a possible design, but I would prefer to avoid including Do53. > Do53 is not a secure or privacy-preserving transport, which makes it > radically different from DoT, DoH, DNS over QUIC, etc. Just as SVCB does > not support insecure HTTP, I think it makes sense to avoid adding support > for insecure DNS transport. > > When a service is identified by name, I think we should be ensuring that > we are actually communicating with the named service. With Do53, we have > no ability to do this. In some configurations, allowing Do53 in SVCB would > create a security vulnerability. > > In addition, I would favor Do53 is explicitly mention so that went it is >> not deployed, the DNS client can actually knows this explicitly. >> > > I don't think this is necessary. The draft already says: > > A client that attempts a connection using an encrypted DNS transport > from a SVCB record SHOULD NOT fall back to unencrypted DNS if > connection fails. > > (https://tools.ietf.org/html/draft-schwartz-svcb-dns-01#section-9.2) > > Therefore, the existence of a Do53 service is typically irrelevant to > SVCB-enabled clients when SVCB records are present: they will not use it, > whether or not it exists. > > >> >>> >>> The service is >>>> identified by a "scheme" indicating the service type, a hostname, and >>>> optionally other information such as a port number. A DNS server is >>>> often identified only by its IP address (e.g. in DHCP), but in some >>>> contexts it can also be identified by a hostname (e.g. "NS" records, >>>> manual resolver configuration). >>>> >>>> >>>> I like the paragraph, but I believe it >>>> might help the reader to add that DNS >>>> servers can be authoritative or resolver >>>> which are quite common term. I am >>>> wondering however, if there are any >>>> reasons for not mentioning them. >>>> >>>> >>>> >>> >>> This is a deliberate omission: this draft is concerned only with DNS as >>> a protocol, not with the types of queries and responses that are encoded. >>> In principle, this SVCB mapping can be applied independently of whether the >>> server is authoritative for any names, or supports recursion. >>> >> >> Ok so that is an editorial choice. I am wondering though, if that would >> be a nosense to have a SvcParameter saying whether the end point is a >> resolver, authoritative, forwarder - either here or somewhere else. >> > >> > > I think that is a possibility, but I don't see an immediate need for it, > so I haven't defined such a SvcParamKey. In every existing use case, the > client already knows whether it is going to set the "recursion desired" bit > in its queries. If we find a use case that requires such an indication, we > can extend the mapping at that time. > > >> Names are formed using Port-Prefix Naming ([SVCB] Section 2.3). For >>>> example, a DNS server with the name "dns1.example.com", listening >>>> (unusually) on non-default port number 5353, would be represented as >>>> "_5353._dns.dns1.example.com.". >>>> >>>> >>>> While this seems conform to the SVCB >>>> spec ;-) I would have envisioned the >>>> port number prefix as designating the >>>> service rather that actual port on which >>>> the service is run. Typically in Do53 >>>> would be designated as _53._dns and if >>>> that service is run on port 5353 I would >>>> expected the number being provide by the >>>> port SvcParameter. >>>> >>> >>> The port SvcParam is also supported, but its meaning is different. The >>> port prefix identifies the service. The port SvcParam provides the >>> location of the alternative endpoint. >>> >> >> This seems to be my understanding. , but then "_5353._ >> dns.dns1.example.com." seems to me misleading as 5353 represents while >> the text mentions the server is listening to an unusual port. My >> expectation was that a DNS server was listening on 5353 instead of 53. From >> my understanding of the text I would have expected to have 5353 in the >> SvcParameter. >> I think more text is needed here to disambiguate the signification of the >> port. Currently what we designate as the port does not seem to be the port. >> I would expect some clarification on where the port is defined. >> > > OK, I've attempted to clarify that we are speaking here about the port > number that identifies the service, as opposed to the port number used to > connect to the alternative endpoint: > https://github.com/bemasc/svcb-dns/commit/fb867ece57236028b8e78496429ef50f3100f1cb > > >> >> >>> >>> One specific reason for doing so is that >>>> the unconventional port cannot be >>>> guessed without previous knowledge. >>>> >>> >>> If the client has not been specifically informed that the service's >>> identity contains an unconventional port, it will assume the default port >>> (53), and query for SVCB records at _dns.$SERVER_NAME (no port prefix). >>> Each SVCB record returned may contain a port SvcParamKey indicating where >>> to find that alternative service endpoint. >>> >> >> This requires so two entries _dns.${server} and _5353._dns.${server} - >> probably CNAMed. >> > > The second entry would only exist if the operator has been advertising > ${server}:5353 as a DNS service. If this service is equivalent to the > service at ${server}:53, then the operator could simply publish a CNAME as > you describe. However, if the two ports operate differently (e.g. with > different behaviors or policies), then they would need separate sets of > alternative endpoints. > > >> I think the notation is mixing service and implementation of the service, >> and I am wondering if there are any reasons we need to do that here in this >> spec. >> > > I view this as clearly separating the identity of the service from its > implementation. The service is identified by a hostname and a port number > (encoded in the QNAME), and its implementation is located by a hostname and > a port number (the TargetName, port=...). These hostnames and port numbers > can be the same or different; they are independent. > > Similarly, it seems to me that the convention to have port 53 as a default >> port is a convention that is specified in this document and that we could >> define it otherwise. If so, given that the service can be DoT, DoH, DoQ. I >> am wondering why couldn't we define _dns as the service abstraction of DNS >> that could be declined in DoT, DoH Do53.... without precluding a default >> port. >> > > I'm not sure I understand this, but the draft is indeed designed so that > the vast majority of operators will never need to use a port prefix name or > a port SvcParam. An explicit port prefix is only needed when the DNS > service is identified by a non-default port number, and an explicit port > SvcParam is only needed when operating an alternative endpoint on a > non-default port number. > > I also believe that the port needs to explicitly mention how the port >> value is handled in _port._dns >> > > I don't think I understand this question. > > >> >> >>> >>> I believe that some specific convention >>>> should considers that _dns may designate >>>> the DNS service including all flavors. >>>> >>> >>> As above, I don't understand what is meant by a "flavor". >>> >> >> flavor meant to me DoT, DoQ, DoH, Do53... >> >> >>> >>> >>>> This key is used to indicate the target port for connection. If >>>> omitted, the client SHALL use the default port for each transport >>>> protocol: 853 for DNS over TLS and 443 for DNS over HTTPS. >>>> >>>> >>>> I have the impression some text is needed to define how the transport >>>> is determined. >>>> I favor that port is being specified in >>>> this field as opposed to in the prefix. >>>> I also believe that the port number >>>> should not be defined at two distinct >>>> places. >>>> >>> >>> These two port numbers have separate meanings: the prefix is an "input" >>> identifying the service, and the SvcParam is an "output" that locates the >>> endpoint. >>> >>> >> I agree, what I was trying to say is that the default port is defined >> from the transport, but the text does not indicate how transport is derived. >> > > OK, I've swapped the "alpn" and "port" sections so that the reader learns > how transports are selected before encountering that concept in the "port" > section ( > https://github.com/bemasc/svcb-dns/commit/02c0c474bedab28f892d535a40a095fc3367ea52 > ). > > >> I suppose that a reference to the alpn section could be added as well as >> an order in which the parameters needs to be looked at. >> >> > > ... > >> 4.2. alpn and no-default-alpn >>>> >>>> These keys indicate the set of supported protocols. The default >>>> protocol is "dot", indicating support for DNS over TLS [DOT]. >>>> >>>> If the protocol set contains any HTTP versions (e.g. "h2", "h3"), >>>> then the record indicates support for DNS over HTTPS [DOH], and the >>>> "dohpath" key MUST be present (Section 5.1). All keys specified for >>>> use with the HTTPS record are also permissible, and apply to the >>>> resulting HTTP connection. >>>> >>>> >>>> I believe the text may specify the >>>> absence of alpn means DNS over UDP. >>>> >>> >>> If the "alpn" key is absent, the default is "dot". >>> >>> >>>> I am >>>> unsure whether no-default-alpn means >>>> that alpn key is omitted or not, but if >>>> that is the case, it does not seem >>>> necessary to introduce its designation. >>>> >>> >>> The default ALPN is "dot", so "no-default-alpn" means "DNS over TLS is >>> not supported". If the "alpn" key is then omitted, the record is >>> useless/null: it indicates no supported protocols at the alternative >>> endpoint, so no client will ever attempt to make use of that record. >>> >>> >> >> I think some text could be added to specify the meaning of >> no-default-alpn in the context of this spec. >> > > I'd rather not duplicate the explanation of these keys, but I've added a > cross-reference to the original source: > https://github.com/bemasc/svcb-dns/commit/4c7509333b7d1279c6f59b1fd80531712e1010a0 > > >> I am wondering in light of comments provided earlier, if one could not >> consider alpn mandatory and when omitted meaning Do53. This would remove >> the need to define no-default and include Do53 as a potential service. >> >> > > I think that would be possible, if we want to support insecure transports. > > >> Instead it might be clear enough to >>>> mention the alpn default value considers >>>> DNS over UDP. >>>> >>> >>> This draft does not currently offer any way to describe a DNS over UDP >>> alternative endpoint. >>> >> >> I think I start seeing this, but I am still not convinced this is >> appropriated to consider Do53 as different from other services. >> >> >>> >>> It also worth mentioning that alpn needs >>>> to be parsed before port and potential >>>> dohpath. >>>> >>>> >>> >>> I expect that a client would parse a record completely before attempting >>> to make use of it, so I'm not concerned with this dependency. >>> >> >> Parsing was maybe inappropriate, but I would say start looking at alpn >> before looking at port. >> >> > > I don't think there's a clear ordering requirement there. A compliant > client must inspect both keys, and could do so in either order. > > >> 4.3. Other applicable SvcParamKeys >>>> >>>> These SvcParamKeys apply to the "dns" scheme without modification: >>>> >>>> * echconfig >>>> >>>> * ipv4hint >>>> >>>> * ipv6hint >>>> >>>> >>>> not sure we need this section as the >>>> document is limited on the DNS >>>> transport. >>>> >>> >>> Yes, this is perhaps redundant. We could instead adjust the wording in >>> the SVCB draft to indicate that these keys are assumed to be broadly >>> applicable. However, I don't think it hurts to remind the reader of other >>> keys that they can use in this context. >>> >>> I am however wondering if we should >>>> distinguish between authoritative and >>>> resolver. >>>> >>> >>> This draft is not intended to be specific to one server role or the >>> other. This is noted in Section 6. >>> >>> >>>> I am wondering if ther is any room for >>>> searching specifically doh server by >>>> requesting: >>>> >>>> _443._dns.resolver 7200 IN SVCB 1 resolver ( >>>> alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} ) >>>> >>>> If that is not the case, it seems we >>>> should clarify this. >>>> The same case occurs with DoT, Do53. >>>> >>>> The advantage would be that it enables >>>> to narrow down the search and prevents >>>> the search of non supported transports. >>>> >>> >>> This is an interesting idea, but the SVCB framework does not support >>> this approach. With SVCB, the client sends a request that describes a >>> logical service, and receives an RRSet of alternative endpoints covering >>> all the service's supported protocols. >>> >> >> I understand that _443._dns does not represent DoH for example. but >> instead a service DNS can could (eventually) be DoT. In other words, with >> standard ports _443._dns does not exist. >> I am wondering if this a choice we make - and that could be otherwise - >> or if there are a higher philosophy that makes us take this path - from >> svcb-https. If so, and for clarification, I am wondering if the definition >> of DoH as a service would require the definition of _doh for example. I do >> not necessarily thinks here this is a good idea. >> > > I think we are trying to build a machine that takes three inputs -- (1) a > service identity, (2) a set of alternative endpoints, and (3) the client's > capabilities -- and arranges a successful connection. > > 1. The DNS service identity consists of a hostname and (very rarely) a > port number. > 2. Each alternative endpoint consists of a hostname, a port number (often > default), various transport layers (DoT, DoH, HTTP/2, HTTP/3, etc.), and > potentially other parameters (e.g. echconfig) > 3. The client's capabilities include the set of supported transports, the > set of supported protocols within those transports, and possibly other > relevant capabilities (e.g. ECH) > > In SVCB, the client sends (1) in the QNAME, gets back (2), and applies (3) > locally to identify an optimal connection. > > In your proposal, the client would send (1) and also part of (3) in the > QNAME, get back a subset of (2), and then apply any remaining filtering > locally. That would work too, but I think it's more complicated. It also > creates tricky possibilities for skew: operators would need to be careful > when changing their records, because changes are no longer atomic. > > One thing that remains unclear to me is the relation between URL scheme >> and service. Currently the port indicate sthe protocol (DoT, DoH, ) which >> makes it difficult to have DoT on port 6777. I am wondering how this >> matters. >> >> > > Yes, in my view you would need a QNAME that contains "_dns", "_dot", the > hostname, and the identifying port number (if non-default port number > identities are supported). > > The downside is that it requires some >>>> synchronization between SVCB RRsets and >>>> when multiple supports are supported by >>>> one client multiple queries may be >>>> performed. It also may require to define >>>> some preference across SVCB RRsets over >>>> multiple domains. >>>> >>> >>> Personally, I expect that servers will typically implement only a small >>> number of protocols (at most ~4), and clients will often support more than >>> one, so transferring the entire configuration in a single RRSet seems >>> likely to be more efficient overall than issuing multiple queries. >>> >>> >> One aspect that I have not seen in the spec is the SVCB 0 and I expect >> this to be used to delegate to third parties that will host multiple >> instances of the service. What I think my increase the size of the number >> of service instances is the services associated to the DNS resolution >> service. >> >> >> > > For these purposes I think SVCB 0 is the same as a CNAME, but at the apex > name. Delegation is already possible with CNAME; SVCB 0 just allows the > use of shorter service names. > > >> >>>> >>>> 9. Security Considerations >>>> >>>> 9.1. Adversary on the query path >>>> >>>> This section considers an adversary who can add or remove responses >>>> to the SVCB query. >>>> >>>> Clients MUST authenticate the server to its name during secure >>>> transport establishment. This name is the hostname used to construct >>>> the original SVCB query, and cannot be influenced by the SVCB record >>>> contents. >>>> >>>> I understand that after the SVCB >>>> exchange, the DNS client sets a TLS >>>> session with the DNS server. I think >>>> this is only valid when TLS is >>>> supported and Do53 woudl not fit in this >>>> category. >>>> >>> >>> Yes. This draft does not provide a way to describe a Do53 alternative >>> endpoint. >>> >>> It sounds to me difficult to have a >>>> requirement that says, when a https >>>> server supports https the session must >>>> be authenticated. >>>> >>> >>> I'm not sure I understand. Authenticated transport is a requirement for >>> HTTPS. >>> >> >> I do not think it is possible not to authenticate either, so it might not >> be necessary to require such authentication. It is a nit. >> >> > > Yes, the point of this sentence is only to identify the name used for > authentication: the service name, not the TargetName. > > I am tempted to say >>>> that the https server should not serve >>>> non secure sessions. On the other hand, >>>> one can also envisioned the case where >>>> a given IP/FQDN is shared by DoH and >>>> Do53, which makes such assumption >>>> difficult. >>>> Unless I am missing something, it sounds >>>> to me the MUST statement is difficult to enforce. >>>> >>> >>> This section is only meant to tell clients to perform SSL certificate >>> validation in the usual way. >>> >>> >>>> I think it is good to specify what name >>>> must be present in the certificate. >>>> Though what is unclear to me is why the >>>> name should be the one of the query as >>>> opposed as the one in the RDATA. >>>> >>> >>> The RDATA is potentially untrusted. In the absence of DNSSEC, an >>> intermediary could rewrite the RDATA to contain any name. >>> >> >> I think the reasoning should be provided with a recommendation as it >> assumed the input is provided in a trusted way and that DNSSEC is not >> enabled. >> >> > > I don't think that's true. The draft only assumes that the input _might_ > be provided in a trusted way, and DNSSEC _might_ not be enabled. > > I understand the text as saying that >>>> connecting to fooexp.resolver.example, the >>>> certificate should have >>>> resolver.example. >>>> >>> >>> Correct. >>> >>> >>>> If that is correct, >>>> and unless I am missing something, I >>>> would be more inclined to authenticate >>>> fooexp.resolver.example. >>>> One case I see is an ISP delegating to a >>>> DNS resolver provider - like akamai. It >>>> should rather let the user authenticate >>>> akamai than the ISP hostname. Other >>>> scenario could ignore the hostname and >>>> use a footprint or the entire >>>> certificate. >>>> Of course this would require DNSSEC. >>>> >>>> It seems such recommendation is limited >>>> to the case when DNSSEC is not used and >>>> when the SVCB name is provisioned in a >>>> trusted manner. >>>> >>> >>> Yes. However, the service provider does not know that the name was >>> provisioned insecurely, and it does not know that the client is validating >>> DNSSEC, so it has to include the service name in its certificate. Since >>> all service providers will place the service name in the certificate, >>> clients should check for this name, regardless of whether they validate >>> DNSSEC. >>> >> >> >> >> Unless I am missing something, it seems to me the responsibility of the >> DNS client to perform the appropriated checks. >> > > Yes, but the client and server need to agree on what those checks are > _before_ they start communicating, so the standards need to tell them what > to do. > > If the service provider is resolver.com, it's responsibility seems >> limited to serve the request it receives. >> > > Note that the request it receives will be on a TLS connection whose SNI > indicates the original DNS service name. > > >> The responsibility of the DNS client is to make sure there is a trusted >> delegation to the provider. That the service name isp.resolver is in the >> certificate is only one way to do so and put the constraints too high on >> the service provider - in my opinion. I would add this as a recommendation. >> > > The use case you are describing is equivalent to a standard HTTPS CDN (and > indeed may be an HTTPS CDN when the transport is DoH). In this case, just > as in HTTPS, the CDN must present a certificate that is valid for the > customer's identity. It is not enough for the customer to CNAME their name > to the CDN, because the CDN cannot assume that all customer zones are > signed and all stub resolvers are DNSSEC-validating. (In fact, almost none > are.) > > A typical use case may be a resolver redirecting to public resolvers. >> >> > > I think the idea of "redirection" is interesting here. SVCB is not a > "redirection" mechanism. It provides alternative endpoints for the _same_ > service; it does not redirect the user to a different service. As such, > unlike HTTP 301, the client continues to validate the service's original > identity, regardless of which endpoint it is talking to. > > >> If an attacker is likely >>>> to update the SCVB content, he might >>>> potentially have provided the false >>>> entry to initiate the SVCB query, in >>>> which case there may not be any need to >>>> update the SVCB parameters. >>>> >>>> I believe the primary recommendation should be >>>> to use DNSSEC and then consider the very >>>> specific use case where DNSSEC cannot be >>>> used with a trusted SVCB entry. >>>> >>>> >>> >>> This draft's approach to authentication is inherited from SVCB, which >>> similarly does not rely on DNSSEC. In both cases, I think the current >>> drafts are taking the best approach. In many or most of the anticipated >>> applications, DNSSEC is not widely deployed, and we do not need it in order >>> to deploy SVCB securely. >>> >> >> I do not believe that seems appropriated in the scope of DNS to >> explicitly not consider DNSSEC not being used. >> > > To be clear, nothing in this draft recommends against the use of DNSSEC. > DNSSEC might even be required for some future standards that use this > format, e.g. when using it in combination with DANE authentication. > > The application is question is the discovery of resolvers and there is no >> specific reasons it does not implement DNSSEC. Though I admit it is unclear >> to me why the browser industry is so reluctant to DNSSEC. >> >> > > As long as there is little deployment of validating stub resolvers, it > should not be surprising that new drafts do not assume the opposite. RFC > 8027 lays out some of the common reasons why stub resolvers cannot enforce > DNSSEC validation. (I would add performance considerations: the latency > cost of followup queries to chase the DNSSEC chain is considerably higher > for client devices (e.g. phones on GSM wireless) than for recursive > resolvers.) > > However, I do think that SVCB for DNS can have a positive impact on DNSSEC > deployment via a mechanism like DEER. By enabling clients to use encrypted > DNS, we can avoid the network problems that prevent stub resolvers from > relying on DNSSEC. > > >>> Although this adversary cannot alter the authentication name of the >>>> server, it does have control of the port number and "dohpath" value. >>>> As a result, the adversary can direct DNS queries for $HOSTNAME to >>>> any port on $HOSTNAME, and any path on "https://$HOSTNAME", even if >>>> $HOSTNAME is not actually a DNS server. If the DNS client uses >>>> shared TLS or HTTP state, the client could be correctly authenticated >>>> (e.g. using a TLS client certificate or HTTP cookie). >>>> >>>> This behavior creates a number of possible attacks for certain server >>>> configurations. For example, if "https://$HOSTNAME/upload" accepts >>>> any POST request as a file upload, the adversary could forge a SVCB >>>> record containing "dohpath=/upload", causing the client to upload >>>> every query, resulting in unexpected storage costs. >>>> >>>> As a mitigation, a client of this SVCB mapping MUST NOT provide >>>> client authentication for DNS queries, except to servers that it >>>> specifically knows are not vulnerable to such attacks. Also, if an >>>> alternative service endpoint sends an invalid response to a DNS >>>> query, the client SHOULD NOT send more queries to that endpoint. >>>> >>>> >>>> The attack is limited to DoH and DoT is >>>> not concerned. >>>> >>> >>> Correct. >>> >>> This attack is targeting the https >>>> server, but in general the motivation >>>> for the client to authenticate the >>>> server is to protect its privacy. It >>>> seems this should be added or clarified. >>>> >>>> >>> >>> OK, I've added an explanation of why this is privacy-relevant and >>> strengthened the recommendation: >>> https://github.com/bemasc/svcb-dns/commit/e311a4e94edd67e17724e693ad2038396fba8b4f >>> >> >> >> -- >> Daniel Migault >> Ericsson >> > -- Daniel Migault Ericsson --000000000000213f8e05b5a7908b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Thanks yo= u very much for the responses and clarifications. I also agree that some po= ints raised are a bit out of scope of the URI resolution as I tended to rea= d the draft as more generic=C2=A0to the usage of SVCB in the context of _dn= s. These clarification are however useful for me and thank=C2=A0you for tak= ing the time to respond.=C2=A0=C2=A0

Yours,=C2=A0
Dan= iel



On Wed, Dec 2, 2020 at 4:27 PM Ben Schwartz &= lt;bemasc@google.com= > wrote:
=


=
On Tue, Dec 1, 2020 at 6:04 PM Daniel= Migault <mglt.= ietf@gmail.com> wrote:
Thanks for the response. Pl= ease see additional information / comment inline.=C2=A0

Yours,=C2=A0
Daniel

On Mon, Nov 30, 2020 at 2:57 PM Be= n Schwartz <bemas= c@google.com> wrote:


On Wed, Nov 25, 2020 at 5= :10 PM Daniel Migault <mglt.ietf@gmail.com> wrote:
Hi,=C2=A0

Pl= ease find my comments below for=C2=A0draft-schwartz-svcb-dns-01
=

Thanks for the detailed review.
=
Yours,=C2=A0
Daniel
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Service Binding Mapping for DNS Serv= ers
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0draft-schwartz-svcb-dns-01
[...]

1.=C2=A0 Introd= uction

=C2=A0 =C2=A0The SVCB record type [SVCB] provides clients wit= h information about
=C2=A0 =C2=A0how to reach alternative endpoints for = a service, which may have
=C2=A0 =C2=A0improved performance or privacy p= roperties. =C2=A0

<mglt>
It is unclear to me if "alter= native"
means "various flavors of DNS resolvers"
or if= it assumes the previous knowledge
of one flavor of the resolver. I do n= ot
believe the latest is appropriated.

This is a general summary of SVCB.=C2=A0 When us= ing SVCB, there is a single logical "service" that can be accesse= d via different "endpoints".=C2=A0 I'm not sure what you mean= by "flavor", but SVCB assumes that the service's behavior do= es not greatly depend on which endpoint you use to access it.
<mglt>
Maybe I am usin= g unappropriated language, but I see the dns resolution service as being de= clined into different "flavors" or "(sub) services" lik= e Do53, DoH, DoT.=C2=A0 But I think my question was regarding=C2=A0the term= "alternate". It i sunclear if alternate hee means "differen= t" or if they are taking the place of something=C2=A0in which=C2=A0cas= e who they are taking the place to.=C2=A0
=C2=A0</mglt>

The word "alternative&qu= ot; here means "in addition to some default".=C2=A0 You're ri= ght that it's not strictly necessary for there to be a default, but pre= sumably a default will be present when adding SVCB to any use case that=C2= =A0already exists, because existing clients will not support SVCB.
=C2=A0

</mglt>
=C2=A0
The input of a SVCB query is a FQDN, and
that F= QDN is not necessarily related to
a Do53 resolver for example. It could<= br>typically an entry point used to
discover all different flavors of DN= S
resolvers. Assuming a previous knowledge
of one resolver seems to p= reclude some
assumption on the FQDN, which seems
independent from the= description of SVCB
fro DNS. =C2=A0 =C2=A0 =C2=A0
</mglt>
<= /div>

Sorry, I'm stil= l not understanding, possibly because I do not understand the idea of a &qu= ot;flavor".=C2=A0 The draft assumes a DNS server (or "service&quo= t;) identified by a domain name, with Do53 service available via A and AAAA= records for that name (if a Do53 service exists, which seems likely to be = common but is not required).

<= div><mglt>
It seems to me that the draft considers as the e= ntry point the FQDN associated to the Do53 server, that is=C2=A0in=C2=A0you= r example below.=C2=A0

<= div>I agree: that's how it's described, and I expect that to be the= main use case.
=C2=A0
resolver= .example is the Do53 service and requesting resolver.example/AAAA will give= me the IP address I need to send the DNS requests to.=C2=A0

=
=C2=A0 $ORIGIN example.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_dn= s.resolver 7200 IN SVCB 1 resolver (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0alpn=3Dh2,h3 echconfig=3D... dohpath=3D/dns-query{?dns} )
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0_dns.resolver 7200 IN SVCB 2 resolver (
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0port=3D8530 echconfig=3D... )
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_dns.resolver 7200 IN SVCB 3 fooexp.resolver= ( port=3D5353
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0echconfig=3D... = alpn=3Dfoo no-default-alpn foo-info=3D... )

If= my understanding is correct, there are two questions I am wondering:
=

1) Why do we mandate that the input of the SVCB query -= in your example resolver.example - needs to be associated to the Do53 serv= er.

I don't thi= nk the draft contains such a mandate, but I do think that's likely to b= e true in most use cases.
=C2=A0
I do not think that should be in the specification as mandatory and and = would consider this as simply good to know.=C2=A0

=
I do see the following hierarchy:
DNS resolution=C2=A0
=
=C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 v
DoH resolvers=C2=A0 DoT resolvers, Do5= 3 resolvers
=C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v=C2=A0 =C2= =A0=C2=A0
IPs,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPs,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0IPs

In this case I would consi= der the=C2=A0 _dns.example, _53._dns.foo, _853._dns.foobar .. as services.= =C2=A0

In SVC= B's terminology, these are all endpoints of a single service, which is = defined by its ability to provide access to particular information.=C2=A0 T= hese endpoints all represent the same service because they all provide the = same DNS behavior.=C2=A0 The choice of transport is hidden behind an abstra= ction barrier: a DNS client does not care which transport is used, so the t= ransport can be selected independent of the query.=C2=A0 Just as the HTTP c= ontent layer doesn't care whether the transport is HTTP/1.1, HTTP/2, or= HTTP/3, the DNS content layer doesn't care whether the transport is Do= T, DoH, etc.

A request for= all DNS servers associated to the FQDN example would be=C2=A0 _dns.example=
A request for all DoT servers associated to the FQDN foorbar wou= ld be=C2=A0 _853._dns.foobar
A request for all Do= 53 servers associated to the FQDN foo would be=C2=A0 _53._dns.foo

This is a conceivable = design, but it is not the design considered by SVCB.=C2=A0 I prefer the SVC= B approach (a single query returns all options), which seems conceptually a= nd operationally simpler.

=
I seems to me that a request for foo AAA is configured to return the I= P addresses of one server under _53._dns as a feature to provide some sort = of retrocompatibility with legacy Do53 resolvers but it seems unclear to me= why this should be required.=C2=A0

It is not required by this draft, but it is a common= case, and may be required in some use cases.=C2=A0 For example, authoritat= ive DNS servers are already identified in NS records by a name that resolve= s to the IPs of the port 53 service.=C2=A0 If SVCB-for-DNS is applied there= in some fashion, backwards compatibility will require that Do53=C2=A0servi= ce remain available on the IPs for that name.

Just to make myself=C2=A0clear, I do see the FQD= N example as representing the input for searching the various available ser= vices. an example is then - at least to me - different than the FQDN associ= ated to the terminating Do53 server.=C2=A0 Having them equal is "nice&= quot; if we want to provide a FQDN to a device that may do requests of type= SVCB or AAAA. Unless I am missing something, it seems that legacy devices = take an IP address - not an FQDN - and so we do not need to have such compa= tibility with legacy devices.=C2=A0=C2=A0

There are a variety of client types with diffe= rent compatibility requirements.=C2=A0 For example, Android phones allow th= e user to enter the hostname of a DNS-over-TLS server, which the phone will= resolve to an IP and connect on port 853.=C2=A0 For backwards compatibilit= y with that mode of deployment, port 53 service is not required, but A/AAAA= records (and port 853 TLS service on those IPs) are required.
This draft does not attempt to lay out all the compatibility r= equirements for each potential use case.=C2=A0 It merely describes the form= at used for the SVCB records, and leaves most of the questions of how they = can be deployed to other drafts (such as DEER).

2) I am wondering how Do53 server are represente= d in SVCB.

In= the current draft, they are not.=C2=A0 The only way to use Do53 is when a = compatible SVCB record is not available.
=C2=A0
It seems to me that different Do53 DNS server may st= ill be offered with different SvcParameters and so should be listed with SV= CB RRsets.

Th= is is a possible design, but I would prefer to avoid including Do53.=C2=A0 = Do53 is not a secure or privacy-preserving transport, which makes it radica= lly different from DoT, DoH, DNS over QUIC, etc.=C2=A0 Just as SVCB does no= t support insecure HTTP, I think it makes sense to avoid adding support for= insecure DNS transport.

When a service is identif= ied by name, I think we should be ensuring that we are actually communicati= ng with the named service.=C2=A0 With Do53, we have no ability to do this.= =C2=A0 In some configurations, allowing Do53 in SVCB would create a securit= y vulnerability.

In = addition, I would favor Do53 is explicitly mention so that went it is not d= eployed, the DNS client can actually knows this explicitly.=C2=A0=C2=A0

I don't thin= k this is necessary.=C2=A0 The draft already says:

=C2=A0 =C2=A0A client that attempts a connection using an encrypted DNS tr= ansport
=C2=A0 =C2=A0from a SVCB record SHOULD NOT fall back to unencryp= ted DNS if
=C2=A0 =C2=A0connection fails.


Therefore, the existence of a D= o53 service is typically irrelevant to SVCB-enabled clients when SVCB recor= ds are present: they will not use it, whether or not it exists.
<= br>
</mglt>

The service is
=C2=A0 =C2=A0identified by a &quo= t;scheme" indicating the service type, a hostname, and
=C2=A0 =C2= =A0optionally other information such as a port number.=C2=A0 A DNS server i= s
=C2=A0 =C2=A0often identified only by its IP address (e.g. in DHCP), b= ut in some
=C2=A0 =C2=A0contexts it can also be identified by a hostname= (e.g. =C2=A0"NS" records,
=C2=A0 =C2=A0manual resolver config= uration).

<mglt>
I like the paragraph, but I believe it
= might help the reader to add that DNS
servers can be authoritative or re= solver
which are quite common term. I am
wondering however, if there = are any
reasons for not mentioning them.

</mglt>
<= /div>

This is a deliberate omis= sion: this draft is concerned only with DNS as a protocol, not with the typ= es of queries and responses that are encoded.=C2=A0 In principle, this SVCB= mapping can be applied independently of whether the server is authoritativ= e for any names, or supports recursion.
= <mglt>
Ok so that is an editorial choice. I am wondering th= ough, if that would be a nosense=C2=A0to have a SvcParameter saying whether= the end point is a resolver, authoritative, forwarder - either here or som= ewhere else.
</mglt>=C2=A0

<= div>I think that is a possibility, but I don't see an immediate need fo= r it, so I haven't defined such a SvcParamKey.=C2=A0 In every existing = use case, the client already knows whether it is going to set the "rec= ursion desired" bit in its queries.=C2=A0 If we find a use case that r= equires such an indication, we can extend the mapping at that time.
=C2=A0
=C2=A0 =C2=A0= Names are formed using Port-Prefix Naming ([SVCB] Section 2.3).=C2=A0 For=C2=A0 =C2=A0example, a DNS server with the name "dns1.example.com", listening<= br>=C2=A0 =C2=A0(unusually) on non-default port number 5353, would be repre= sented as
=C2=A0 =C2=A0"_5353._dns.dns1.example.com.".

<mglt>=
While this seems conform to the SVCB
spec ;-) I would have envisione= d the
port number prefix as designating the
service rather that actua= l port on which
the service is run. Typically in Do53
would be design= ated as _53._dns and if
that service is run on port 5353 I would
expe= cted the number being provide by the
port SvcParameter.
<= /div>

The port SvcParam is also suppo= rted, but its meaning is different.=C2=A0 The port prefix identifies the se= rvice.=C2=A0 The port SvcParam provides the location of the alternative end= point.
<mglt>
This seems= to be my understanding. , but then "_5353._dns.dns1.example.com." seems to me= misleading=C2=A0as 5353 represents while the text mentions the server is l= istening to an unusual=C2=A0port. My expectation was that a DNS server was = listening on 5353 instead of 53. From my understanding of the text I would = have expected to have 5353 in the SvcParameter.=C2=A0
I think mor= e text is needed here to disambiguate the signification of the port. Curren= tly what we designate as the port does not seem to be the port. I would exp= ect some clarification on where the port is defined.=C2=A0

OK, I've attempted to clarify that we= are speaking here about the port number that identifies the service, as op= posed to the port number used to connect to the alternative endpoint:=C2=A0= https://github.com/bemasc/svcb-dns/co= mmit/fb867ece57236028b8e78496429ef50f3100f1cb
=C2=A0
</mglt>=C2=A0
=
One specific reason for doing so is that
the unconventi= onal port cannot be
guessed without previous knowledge.
<= /div>

If the client has not been spec= ifically informed that the service's identity contains an unconventiona= l port, it will assume the default port (53), and query for SVCB records at= _dns.$SERVER_NAME (no port prefix).=C2=A0 Each SVCB record returned may co= ntain a port SvcParamKey indicating where to find that alternative service = endpoint.
<mglt>
This re= quires so two entries _dns.${server} and _5353._dns.${server} - probably CN= AMed.

The second en= try would only exist if the operator has been advertising ${server}:5353 as= a DNS service.=C2=A0 If this service is equivalent to the service at ${ser= ver}:53, then the operator could simply publish a CNAME as you describe.=C2= =A0 However, if the two ports operate differently (e.g. with different beha= viors or policies), then they would need separate sets of alternative endpo= ints.
=C2=A0
I think the n= otation is mixing service and implementation of the service, and I am wonde= ring if there are any reasons we need to do that here in this spec.=C2=A0

I view this as clear= ly separating the identity of the service from its implementation.=C2=A0 Th= e service is identified by a hostname and a port number (encoded in the QNA= ME), and its implementation is located by a hostname and a port number (the= TargetName, port=3D...).=C2=A0 These hostnames and port numbers can be the= same or different; they are independent.

Similarly, it seems to me that the convention to have port = 53 as a default port is a convention that is specified in this document and= that we could define it otherwise. If so, given that the service can be Do= T, DoH, DoQ. I am wondering why couldn't we define _dns as the service = abstraction of DNS that could be declined in DoT, DoH Do53.... without prec= luding a default port.=C2=A0=C2=A0

I'm not sure I understand this, but the draft is indeed= designed so that the vast majority of operators will never need to use a p= ort prefix name or a port SvcParam.=C2=A0 An explicit port prefix is only n= eeded when the DNS service is identified by a non-default port number, and = an explicit port SvcParam is only needed when operating an alternative endp= oint on a non-default port number.

I also believe that the port needs to explicitly mention how the p= ort value is handled in _port._dns

I don't think I understand this question.
=C2= =A0
</mglt>=C2=A0

I believe that some specific convention
sho= uld considers that _dns may designate
the DNS service including all flav= ors.

As above, = I don't understand what is meant by a "flavor".
<mglt>
flavor meant to me DoT, DoQ, D= oH, Do53...
</mglt>=C2=A0
=C2= =A0
=C2=A0 =C2=A0This key is used to indicate the target port f= or connection.=C2=A0 If
=C2=A0 =C2=A0omitted, the client SHALL use the d= efault port for each transport
=C2=A0 =C2=A0protocol: 853 for DNS over T= LS and 443 for DNS over HTTPS.

<mglt>
I have the impression= some text is needed to define how the transport is determined.
I favor = that port is being specified in
this field as opposed to in the prefix.<= br>I also believe that the port number
should not be defined at two dist= inct
places.

These two port numbers have separate meanings: the prefix is an "inpu= t" identifying the service, and the SvcParam is an "output" = that locates the endpoint.

<mglt>
I agree, what I was trying to say is that the defa= ult port is defined from the transport, but the text does not indicate how = transport is derived.

OK, I've swapped the "alpn" and "port" sections = so that the reader learns how transports are selected before encountering t= hat concept in the "port" section (https://github.com/bemasc/svcb-dns/commit/02c0c474bedab28f892d535a4= 0a095fc3367ea52).
=C2=A0
I suppose that a reference to the alpn section could be added as well as= an order in which the parameters needs to be looked at.
</mgl= t>=C2=A0

...=C2= =A0
4.2. =C2=A0alpn = and no-default-alpn

=C2=A0 =C2=A0These keys indicate the set of supp= orted protocols.=C2=A0 The default
=C2=A0 =C2=A0protocol is "dot&qu= ot;, indicating support for DNS over TLS [DOT].

=C2=A0 =C2=A0If the = protocol set contains any HTTP versions (e.g. "h2", "h3"= ;),
=C2=A0 =C2=A0then the record indicates support for DNS over HTTPS [D= OH], and the
=C2=A0 =C2=A0"dohpath" key MUST be present (Secti= on 5.1).=C2=A0 All keys specified for
=C2=A0 =C2=A0use with the HTTPS re= cord are also permissible, and apply to the
=C2=A0 =C2=A0resulting HTTP = connection.

<mglt>
I believe the text may specify the
ab= sence of alpn means DNS over UDP.
=
If the "alpn" key is absent, the default is "= dot".
=C2=A0
I am
unsure whether no-default-= alpn means
that alpn key is omitted or not, but if
that is the case, = it does not seem
necessary to introduce its designation.
=

The default ALPN is "dot&= quot;, so "no-default-alpn" means "DNS over TLS is not suppo= rted".=C2=A0 If the "alpn" key is then omitted, the record i= s useless/null: it indicates no supported protocols at the alternative endp= oint, so no client will ever attempt to make use of that record.
= =C2=A0
<mglt>
I think so= me text could=C2=A0be added to specify the meaning of no-default-alpn in th= e context of this spec.

=
I'd rather not duplicate the explanation of these keys, but I'= ve added a cross-reference to the original source:=C2=A0https://github.com/bemasc/svcb-dns/commit/4c7509333b7d12= 79c6f59b1fd80531712e1010a0
=C2=A0
I am wondering in light of comments provided earlier, if one could n= ot consider alpn mandatory and when omitted meaning Do53. This would remove= the need to define no-default and include Do53 as a potential service.=C2= =A0
</mglt>

I think that would be possible, if we want to support insecure tra= nsports.
=C2=A0=C2=A0
<= div>
Instead it might be clear enough to
mention the alpn default va= lue considers
DNS over UDP.

This draft does not currently offer any way to describe a D= NS over UDP alternative endpoint.
<mg= lt>
I think I start seeing this, but I am still not convinced = this is appropriated to consider Do53 as different from other services.=C2= =A0
</mglt>=C2=A0

<= div>
It also worth mentioning that alpn needs
to be parsed before po= rt and potential
dohpath.
</mglt>

I expect that a client would parse a record = completely before attempting to make use of it, so I'm not concerned wi= th this dependency.
<mglt>
Parsing was maybe inappropriate, but I would=C2=A0say start looking at a= lpn before looking at port.
</mglt>=C2=A0
=

I don't think there's a clear orde= ring requirement there.=C2=A0 A compliant client must inspect both keys, an= d could do so in either order.
=C2=A0
4.3.=C2=A0 Other applicable SvcParamKeys

=C2= =A0 =C2=A0These SvcParamKeys apply to the "dns" scheme without mo= dification:

=C2=A0 =C2=A0* =C2=A0echconfig

=C2=A0 =C2=A0* =C2= =A0ipv4hint

=C2=A0 =C2=A0* =C2=A0ipv6hint

<mglt>
not= sure we need this section as the
document is limited on the DNS
tran= sport.

Yes, thi= s is perhaps redundant.=C2=A0 We could instead adjust the wording in the SV= CB draft to indicate that these keys are assumed to be broadly applicable.= =C2=A0 However, I don't think it hurts to remind the reader of other ke= ys that they can use in this context.

I am howev= er wondering if we should
distinguish between authoritative and
resol= ver. =C2=A0

Thi= s draft is not intended to be specific to one server role or the other.=C2= =A0 This is noted in Section 6.

<mglt>
= I am wondering if ther is any room for
searching specifically doh server= by
requesting:

_443._dns.resolver 7200 IN SVCB 1 resolver (
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alpn=3Dh2,h3 echconfig=3D... dohpa= th=3D/dns-query{?dns} )

If that is not the case, it seems we
shou= ld clarify this.
The same case occurs with DoT, Do53.

The advanta= ge would be that it enables
to narrow down the search and prevents
th= e search of non supported transports.

This is an interesting idea, but the SVCB framework = does not support this approach.=C2=A0 With SVCB, the client sends a request= that=C2=A0describes a logical service, and receives an RRSet of alternativ= e endpoints covering all the service's supported protocols.
=
<mglt>
I understand that _443._dns = does not represent DoH for example. but instead a service=C2=A0DNS can coul= d (eventually) be DoT.=C2=A0 =C2=A0In other words, with standard ports _443= ._dns does not exist.
I am wondering if this a choice we make - a= nd that could be otherwise - or if there are a higher philosophy that makes= us take this path - from svcb-https. If so, and for clarification, I am wo= ndering if the definition of DoH as a service would require the definition = of _doh for example. I do not necessarily thinks here this is a good idea.<= /div>

I think we are trying to = build a machine that takes three inputs -- (1) a service identity, (2) a se= t of alternative endpoints, and (3) the client's capabilities -- and ar= ranges a successful connection.

1. The DNS service= identity consists of a hostname and (very rarely) a port number.
2. Each alternative endpoint consists of a hostname, a port number (often = default), various transport layers (DoT, DoH, HTTP/2, HTTP/3, etc.), and po= tentially other parameters (e.g. echconfig)
3. The client's c= apabilities include the set of supported transports, the set of supported p= rotocols within those transports, and possibly other relevant capabilities = (e.g. ECH)

In SVCB, the client sends (1) in the QN= AME, gets back (2), and applies (3) locally to identify an optimal connecti= on.

In your proposal, the client would send (1) an= d also part of (3) in the QNAME, get back a subset of (2), and then apply a= ny remaining filtering locally.=C2=A0 That would work too, but I think it&#= 39;s more complicated.=C2=A0 It also creates tricky possibilities for skew:= operators would need to be careful when changing their records, because ch= anges are no longer atomic.

One= thing that remains unclear to me is the relation between URL scheme and se= rvice. Currently the port indicate sthe protocol (DoT, DoH,=C2=A0 ) which m= akes it difficult to have DoT on port 6777. I am wondering how this matters= .=C2=A0=C2=A0
<mglt>=C2=A0

Yes, in my view you would need a QNAME that contains &quo= t;_dns", "_dot", the hostname, and the identifying port numb= er (if non-default port number identities are supported).

The downside is that it req= uires some
synchronization between SVCB RRsets and
when multiple supp= orts are supported by
one client multiple queries may be
performed. I= t also may require to define
some preference across SVCB RRsets over
= multiple domains.

Personally, I expect that servers will typically implement only a small = number of protocols (at most ~4), and clients will often support more than = one, so transferring the entire configuration in a single RRSet seems likel= y to be more efficient overall than issuing multiple queries.
<mglt>
One aspect that= I have not seen in the spec is the SVCB 0 and I expect this to be used to = delegate to third parties that will host multiple instances of the service.= What I think my increase the size of the number of service instances is th= e services associated to the DNS resolution service.=C2=A0

</mglt>=C2=A0

<= div>For these purposes I think SVCB 0 is the same as a CNAME, but at the ap= ex name.=C2=A0 Delegation is already possible with CNAME; SVCB 0 just allow= s the use of shorter service names.
=C2=A0
</mglt>

9.=C2=A0 Securi= ty Considerations

9.1.=C2=A0 Adversary on the query path

=C2= =A0 =C2=A0This section considers an adversary who can add or remove respons= es
=C2=A0 =C2=A0to the SVCB query.

=C2=A0 =C2=A0Clients MUST auth= enticate the server to its name during secure
=C2=A0 =C2=A0transport est= ablishment.=C2=A0 This name is the hostname used to construct
=C2=A0 =C2= =A0the original SVCB query, and cannot be influenced by the SVCB record
= =C2=A0 =C2=A0contents. =C2=A0
<mglt>
I understand that after th= e SVCB
exchange, the DNS client sets a TLS
session with the DNS serve= r. I think
this is only valid when TLS is
supported and Do53 woudl no= t fit in this
category.
Yes.=C2=A0 This draft does not provide a way to describe a Do53= alternative endpoint.

It sounds to me difficult= to have a
requirement that says, when a https
server supports https = the session must
be authenticated.
<= div>
I'm not sure I understand.=C2=A0 Authenticated trans= port is a requirement for HTTPS.
<mgl= t>
I do not think it is possible not to authenticate either, s= o it might not be necessary to require such authentication. It is a nit.=C2= =A0
</mglt>=C2=A0

Yes, the point of this sentence is only to identify the name used = for authentication: the service name, not the TargetName.

I am tempted to say
tha= t the https server should not serve
non secure sessions. On the other ha= nd,
one can also envisioned the case where
a given IP/FQDN is shared = by DoH and
Do53, which makes such assumption
difficult.
Unless I a= m missing something, it sounds
to me the MUST statement is difficult to = enforce.

This s= ection is only meant to tell clients to perform SSL certificate validation = in the usual way.
=C2=A0
I think it is good to specif= y what name
must be present in the certificate.
Though what is unclea= r to me is why the
name should be the one of the query as
opposed as = the one in the RDATA.

The RDATA is potentially untrusted.=C2=A0 In the=C2=A0absence of DNS= SEC, an intermediary could rewrite the RDATA to contain any name.
<mglt>
I think the reasoning shou= ld be provided with a recommendation as it assumed the input is provided in= a trusted way and that DNSSEC is not enabled.=C2=A0 =C2=A0
</= mglt>=C2=A0

I don'= t think that's true.=C2=A0 The draft only assumes that the input _might= _ be provided in a trusted way, and DNSSEC _might_ not be enabled.

I understand the t= ext as saying that
connecting to fooexp.resolver.example, the
certifi= cate should have
resolver.example.
<= div>
Correct.
=C2=A0
If that is correc= t,
and unless I am missing something, I
would be more inclined to aut= henticate
fooexp.resolver.example.
One case I see is an ISP delegatin= g to a
DNS resolver provider - like akamai. It
should rather let the = user authenticate
akamai than the ISP hostname. Other
scenario could = ignore the hostname and
use a footprint or the entire
certificate.Of course this would require DNSSEC.

It seems such recommendation i= s limited
to the case when DNSSEC is not used and
when the SVCB name = is provisioned in a
trusted manner.

Yes.=C2=A0 However, the service provider does not k= now that the name was provisioned insecurely, and it does not know that the= client is validating DNSSEC, so it has to include the service name in its = certificate.=C2=A0 Since all service providers will place the service name = in the certificate, clients should check for this name, regardless of wheth= er they validate DNSSEC.

= <mglt>

Unless I am missing something, it see= ms to me the responsibility of the DNS client to perform the appropriated c= hecks.

Yes, but the clien= t and server need to agree on what those checks are _before_ they start com= municating, so the standards need to tell them what to do.

If the service provider is resolver.com,=C2=A0it's responsibili= ty seems limited to serve the request it receives.=C2=A0
<= /blockquote>

Note that the request it receives will be o= n a TLS connection whose SNI indicates the original DNS service name.
=
=C2=A0
The responsibility of the DNS clie= nt is to make sure there is a trusted delegation to the provider. That the = service name isp.resolver is in the certificate is only one way to do so an= d put the constraints too high on the service provider - in my opinion. I w= ould add this as a recommendation.=C2=A0

The use case you are describing is equivalent to a standard= HTTPS CDN (and indeed may be an HTTPS CDN when the transport is DoH).=C2= =A0 In this case, just as in HTTPS, the CDN must present a certificate that= is valid for the customer's identity.=C2=A0 It is not enough for the c= ustomer to CNAME their name to the CDN, because the CDN cannot assume that = all customer zones are signed and all stub resolvers are DNSSEC-validating.= =C2=A0 (In fact, almost none are.)

<= div>A typical use case may be a resolver redirecting to public resolvers.= =C2=A0
</mglt>=C2=A0

I think the idea of "redirection" is interesting = here.=C2=A0 SVCB is not a "redirection" mechanism.=C2=A0 It provi= des alternative endpoints for the _same_ service; it does not redirect the = user to a different service.=C2=A0 As such, unlike HTTP 301, the client con= tinues to validate the service's original identity, regardless of which= endpoint it is talking to.
=C2=A0=C2=A0
If an attacker is likely
to update the SCV= B content, he might
potentially have provided the false
entry to init= iate the SVCB query, in
which case there may not be any need to
updat= e the SVCB parameters.

I believe the primary recommendation should b= e
to use DNSSEC and then consider the very
specific use case where DN= SSEC cannot be
used with a trusted SVCB entry. =C2=A0
</mglt>

This draft's= approach to authentication is inherited from SVCB, which similarly does no= t rely on DNSSEC.=C2=A0 In both cases, I think the current drafts are takin= g the best approach.=C2=A0 In many or most of the anticipated applications,= DNSSEC is not widely deployed, and we do not need it in order to deploy SV= CB securely.
<mglt>
I do= not believe that seems appropriated in the scope of DNS to explicitly not = consider DNSSEC not being used.

To be clear, nothing in this draft recommends against the use of DNS= SEC.=C2=A0 DNSSEC might even be required for some future standards that use= this format, e.g. when using it in combination with DANE authentication.

The application is question is t= he discovery of resolvers and there is no specific reasons it does not impl= ement DNSSEC. Though I admit it is unclear to me why the browser industry i= s so reluctant to DNSSEC.=C2=A0=C2=A0
</mglt>=C2=A0

As long as there is little d= eployment of validating stub resolvers, it should not be surprising that ne= w drafts do not assume the opposite.=C2=A0 RFC 8027 lays out some of the co= mmon reasons why stub resolvers cannot enforce DNSSEC validation.=C2=A0 (I = would add performance considerations: the latency cost of followup queries = to chase the DNSSEC chain is considerably higher for client devices (e.g. p= hones on GSM wireless) than for recursive resolvers.)

However, I do think that SVCB for DNS can have a positive impact on= DNSSEC deployment via a mechanism like DEER.=C2=A0 By enabling clients to = use encrypted DNS, we can avoid the network problems that prevent stub reso= lvers from relying on DNSSEC.

<= /div>

=C2=A0 =C2=A0Although this ad= versary cannot alter the authentication name of the
=C2=A0 =C2=A0server,= it does have control of the port number and "dohpath" value.
= =C2=A0 =C2=A0As a result, the adversary can direct DNS queries for $HOSTNAM= E to
=C2=A0 =C2=A0any port on $HOSTNAME, and any path on "https://$= HOSTNAME", even if
=C2=A0 =C2=A0$HOSTNAME is not actually a DNS ser= ver.=C2=A0 If the DNS client uses
=C2=A0 =C2=A0shared TLS or HTTP state,= the client could be correctly authenticated
=C2=A0 =C2=A0(e.g. using a = TLS client certificate or HTTP cookie).

=C2=A0 =C2=A0This behavior c= reates a number of possible attacks for certain server
=C2=A0 =C2=A0conf= igurations.=C2=A0 For example, if "https://$HOSTNAME/upload" acce= pts
=C2=A0 =C2=A0any POST request as a file upload, the adversary could = forge a SVCB
=C2=A0 =C2=A0record containing "dohpath=3D/upload"= ;, causing the client to upload
=C2=A0 =C2=A0every query, resulting in u= nexpected storage costs.

=C2=A0 =C2=A0As a mitigation, a client of t= his SVCB mapping MUST NOT provide
=C2=A0 =C2=A0client authentication for= DNS queries, except to servers that it
=C2=A0 =C2=A0specifically knows = are not vulnerable to such attacks.=C2=A0 Also, if an
=C2=A0 =C2=A0alter= native service endpoint sends an invalid response to a DNS
=C2=A0 =C2=A0= query, the client SHOULD NOT send more queries to that endpoint.

<= ;mglt>
The attack is limited to DoH and DoT is
not concerned.
<= /div>

Correct.=C2=A0

This attack is targeting the https
server, but i= n general the motivation
for the client to authenticate the
server is= to protect its privacy. It
seems this should be added or clarified.
= </mglt>

OK, I= 've added an explanation of why this is privacy-relevant and strengthen= ed the recommendation:=C2=A0https://g= ithub.com/bemasc/svcb-dns/commit/e311a4e94edd67e17724e693ad2038396fba8b4f


--
Daniel Migault
Ericsson


--
Daniel Migault
Ericsson
--000000000000213f8e05b5a7908b-- From nobody Mon Dec 7 10:45:16 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875393A00F7 for ; Mon, 7 Dec 2020 10:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_qtrV9UZcv0 for ; Mon, 7 Dec 2020 10:45:14 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458D23A00D9 for ; Mon, 7 Dec 2020 10:45:14 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id z188so13485108qke.9 for ; Mon, 07 Dec 2020 10:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ahs3I0sS3iKYOVU0Q0jp1gkAj+SjBGxdlspsrnxdINs=; b=GDB7qJuPv4aZaoc4pV2/0M72td+w0Py767qWlcSTq/XDND3nRzX4GLmxtRgOBFKOQZ BHBCaVsX8rZWtMl6Byuqw1hIhuisPHqvhSiCBP45pzU1iwE2Enu0BWIzZ/IWaID9zSpE X+7EtFqLaLQRNZZXkSeMa4sE+0JK6+eZF7YSFM/0fv/CnP9jCU5l16Tj63+upB/bwfr0 JdigimrtSXyXNpATlSDK6XSClYOiY9zElLJf1YaVWsIwHTOpzjArOW6sVTjvxnZifsh0 x61LEi5Wr8Lgu7XXAERX8XmsnIv9a75PelYiC9BBPlabewnpB5DIwOLJX/z/BndE7pRP AOTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ahs3I0sS3iKYOVU0Q0jp1gkAj+SjBGxdlspsrnxdINs=; b=s3H3toYmMvKfttbQ9ogdlscwDJCoDflDBKQzs9wtNqr4BFaRv/dfoJvae9Udsaa0iU 1Q+kSgWhCgXvTJZki/Ojt0TfxYH2PjvNVFQWKr/Ccy75hYAODCi/ZVOKF11rnNFq0ovP MtlD4qma55v68CrDWCuvB8AInFKJSD49ycLRxRwChFeJ7g0QN+Dcon6l7XppkKtfhksg 6H7XbzcDgTwAh8Wo6x2S1+foMZb0IJvfXwTYxvHywCUHXFGXNlPScVcWlCxchf8oBWh+ 9pE3To7ktc6HP+8z+fdsxz9y8XOMue6c3GYTdeKhUKei+lDI6gWylC1/YwSnZdIfdnCs 0f2A== X-Gm-Message-State: AOAM533MLYvMjRxhHB3rJqiovu8bxet6OT7MwyG4zXknZENDMtnEBoat w9/WiVC9EuGbwmhguPIPYGc0qwqaY+CY5itgYy43tionKMc= X-Google-Smtp-Source: ABdhPJy0s+Skvvb/OYLJ4M94gzGdzNyUG+zZAk0BTZ1WbKVy5Gz0CaZv/quekjzf7FshaYsgz5jTTl098fHbF2cLaU0= X-Received: by 2002:a05:620a:4e5:: with SMTP id b5mr24939956qkh.255.1607366713289; Mon, 07 Dec 2020 10:45:13 -0800 (PST) MIME-Version: 1.0 From: Chris Box Date: Mon, 7 Dec 2020 18:45:02 +0000 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000f8417a05b5e439d3" Archived-At: Subject: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 18:45:16 -0000 --000000000000f8417a05b5e439d3 Content-Type: text/plain; charset="UTF-8" Hi everyone During 109's discussion of the concept of equivalence, many valid points were raised. I've attempted to take these and incorporate them into a new definition, and came up with the wording below. *Given an initial resolver A, equivalence is the claim that one or more other resolvers B, C, etc are:(1) Operated by the same entity as A,(2) Have authentication and security properties that are no worse than A,(3) Have access to the same pool of names as A, and(4) Possess the same data privacy and filtering characteristics as A.* This is not a final definition by any means, but it is at least closer to the spirit I heard. Would this definition work for you, or with some tweaks? Chris P.S. Thanks to Andrew Campling for his help in summarising the output of 109. --000000000000f8417a05b5e439d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone

During 109's= discussion of the concept of equivalence, many valid points were raised. I= 've attempted to take these and incorporate them into a new definition,= and came up with the wording below.

Given an initial resolver A, equivalence is the= claim that one or more other resolvers B, C, etc are:
(1) Operated by t= he same entity as A,
(2) Have authentication and security properties tha= t are no worse than A,
(3) Have access to the same pool of names as A, a= nd
(4) Possess the same data privacy and filtering characteristics as A.=

This is not a final definition by any means, = but it is at least closer to the spirit I heard.

W= ould this definition work for you, or with some tweaks?

<= /div>
Chris


P.S. Thanks to Andr= ew Campling for his help in summarising the output of 109.
--000000000000f8417a05b5e439d3-- From nobody Mon Dec 7 11:44:43 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2A53A07E6 for ; Mon, 7 Dec 2020 11:44:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv3KDLq6MSx0 for ; Mon, 7 Dec 2020 11:44:40 -0800 (PST) Received: from ppa2.lax.icann.org (ppa2.lax.icann.org [192.0.33.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A084F3A07D7 for ; Mon, 7 Dec 2020 11:44:40 -0800 (PST) Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa2.lax.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 0B7Jidvm030045 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 7 Dec 2020 19:44:39 GMT Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Mon, 7 Dec 2020 11:44:38 -0800 Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0721.004; Mon, 7 Dec 2020 11:44:38 -0800 From: Paul Hoffman To: Chris Box CC: ADD Mailing list Thread-Topic: [Ext] [Add] Definition of equivalence Thread-Index: AQHWzMkgeIcQ7wLHjUuj81/Tr5C4wqnsj1UA Date: Mon, 7 Dec 2020 19:44:38 +0000 Message-ID: <40C39C4D-68C7-4C8E-8841-0F1D5A637BE0@icann.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_7F5B9E9C-6B48-4CE1-A1CA-F3D0F471FC89"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-07_16:2020-12-04, 2020-12-07 signatures=0 Archived-At: Subject: Re: [Add] [Ext] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 19:44:42 -0000 --Apple-Mail=_7F5B9E9C-6B48-4CE1-A1CA-F3D0F471FC89 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 7, 2020, at 10:45 AM, Chris Box wrote: > Given an initial resolver A, equivalence is the claim that one or more = other resolvers B, C, etc are: > (1) Operated by the same entity as A, > (2) Have authentication and security properties that are no worse than = A, > (3) Have access to the same pool of names as A, and > (4) Possess the same data privacy and filtering characteristics as A. >=20 > This is not a final definition by any means, but it is at least closer = to the spirit I heard. >=20 > Would this definition work for you, or with some tweaks? One easy tweak would be to say before the list that all four = requirements need to be met simultaneously. The third requirement sounds odd. Would "Resolves all names the same was = as A does" be better? --Paul Hoffman= --Apple-Mail=_7F5B9E9C-6B48-4CE1-A1CA-F3D0F471FC89 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBrYw ggayMIIFmqADAgECAhMwAAAV3RBqFEZex8dMAAMAABXdMA0GCSqGSIb3DQEBCwUAMF8xEzARBgoJ kiaJk/IsZAEZFgNvcmcxFTATBgoJkiaJk/IsZAEZFgVpY2FubjESMBAGCgmSJomT8ixkARkWAmRz MR0wGwYDVQQDExRhZDEtbGF4LmRzLmljYW5uLm9yZzAeFw0yMDA5MTkxODA3MTlaFw0yMjA5MTkx ODA3MTlaMIGUMRMwEQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQBGRYFaWNhbm4xEjAQ BgoJkiaJk/IsZAEZFgJkczEUMBIGA1UECxMLSUNBTk4tVXNlcnMxFTATBgNVBAMTDFBhdWwgSG9m Zm1hbjElMCMGCSqGSIb3DQEJARYWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMyCemeYYZjhFjqol6d0KFelzUOUxRgoLxxuCY67ssb2elDgD8Vu 0O5fqMb5GwKWGZknC9uG3l3Of8pnfMlHpeFpLz9abvV/esea+JDxt+RgZLZRvJtZ/lVV86BZnjAO kKtLboRpfXTAobOllRTMcDaRksynf2FiF8VPB9vIsAxNT6/p8P3X84zAkBUX9BI1p9Pf/+ksRkau c40q/N7AuAVYAQlOwnN2QG+64T6ofP6kr3DanHuYg2C/5G3RXX58azNgSYnopJ0AiFY9e4M7iVxm Ll5wgmBGtVoLdjFe9HnCk5EdqKk5CE1ll7akYuvMNUqK1ingA5IjAvRZc9hD818CAwEAAaOCAy8w ggMrMB0GA1UdDgQWBBSh5qyXEQo8kO1LLYUKzpRiMxIHMzAfBgNVHSMEGDAWgBTpKerCBbuXyks/ cnl6+luCS7lqhDCB2QYDVR0fBIHRMIHOMIHLoIHIoIHFhoHCbGRhcDovLy9DTj1hZDEtbGF4LmRz LmljYW5uLm9yZygxKSxDTj1hZDEtbGF4LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWRzLERDPWljYW5uLERDPW9yZz9jZXJ0 aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p bnQwgcoGCCsGAQUFBwEBBIG9MIG6MIG3BggrBgEFBQcwAoaBqmxkYXA6Ly8vQ049YWQxLWxheC5k cy5pY2Fubi5vcmcsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZHMsREM9aWNhbm4sREM9b3JnP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA4GA1UdDwEB/wQEAwIFoDA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiBurJNhMjIaoOtkz+HlPRag/mIbk6H68s/hoOYWgIBZAIB BzApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwNQYJKwYBBAGCNxUK BCgwJjAMBgorBgEEAYI3CgMEMAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMEkGA1UdEQRCMECgJgYK KwYBBAGCNxQCA6AYDBZwYXVsLmhvZmZtYW5AaWNhbm4ub3JngRZwYXVsLmhvZmZtYW5AaWNhbm4u b3JnMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUr DgMCBzAKBggqhkiG9w0DBzANBgkqhkiG9w0BAQsFAAOCAQEATidKimzbAoiiUW1wn7PWGyvBra29 qfQFUkoiN910zUtEigII3eYlf6lgokLPem1VGMAbRDJaDZNDy/1piuJFxtH2qLqqM1KL0jhLD62I 1JlpoUSSVCs0I0c+WoMafG1+TxDHvKOJ+88uR5EE61qoeHBe5pCIeQYzPyEbcJRIqavNj6DKg5Nm AwkwZwCSPGwb7WlKwxnf3X+Zx2emG+AB6k+q+jZA3obglwR5NFov1CeOuW5qQNzB9FIzbZGDjNsJ SwY0ygGnYItvhxb+if9I4NnuZGy41dwwDql40ZGmJg1yUV8niDpUxFUdAdXdeCoVoTPAK7ZDUS8y bo/Iyo/aEzGCAyAwggMcAgEBMHYwXzETMBEGCgmSJomT8ixkARkWA29yZzEVMBMGCgmSJomT8ixk ARkWBWljYW5uMRIwEAYKCZImiZPyLGQBGRYCZHMxHTAbBgNVBAMTFGFkMS1sYXguZHMuaWNhbm4u b3JnAhMwAAAV3RBqFEZex8dMAAMAABXdMA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDEyMDcxOTQ0MzhaMC8GCSqGSIb3DQEJBDEi BCAdg17gC7cVOuW/eFF9Pim4lHKWIcioqRKIM+7vHLdQlzCBhQYJKwYBBAGCNxAEMXgwdjBfMRMw EQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQBGRYFaWNhbm4xEjAQBgoJkiaJk/IsZAEZ FgJkczEdMBsGA1UEAxMUYWQxLWxheC5kcy5pY2Fubi5vcmcCEzAAABXdEGoURl7Hx0wAAwAAFd0w gYcGCyqGSIb3DQEJEAILMXigdjBfMRMwEQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQB GRYFaWNhbm4xEjAQBgoJkiaJk/IsZAEZFgJkczEdMBsGA1UEAxMUYWQxLWxheC5kcy5pY2Fubi5v cmcCEzAAABXdEGoURl7Hx0wAAwAAFd0wDQYJKoZIhvcNAQEBBQAEggEAxF+CEfRTclrjiZAGQw+v 4vNDBkwmv8LX9sTOLyUfRzEHX06RSYCAEMvEFwB4doob9ffv3fZmknQpWanTHaq0hby4AWRDXMD0 0jm6pcsk9Xpg2wBBVlKAwtVgCRVy/cYmiAomliSJ1g/HS1P5Rww73ebRQSW4S5zsTJpuV7VGgE70 ylrl6Z8hUd8xodiSEiyU2f9Bz54tPo08p8oIgLtvpkgLUMGbRzyz649mzqczxBfFlj3B5az1vafp 2NHYTKd6RBeeCpp7zaoMv16+DfkXXh36D4ZLGSKE4wsjAvdhRisDsNfwi1yVknb+BjTkXWMqP2EF 4zyagOVFROwa6BiWVgAAAAAAAA== --Apple-Mail=_7F5B9E9C-6B48-4CE1-A1CA-F3D0F471FC89-- From nobody Mon Dec 7 12:00:36 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8163A09AD for ; Mon, 7 Dec 2020 12:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGiquxVmn4Rz for ; Mon, 7 Dec 2020 12:00:25 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0F43A0AF6 for ; Mon, 7 Dec 2020 12:00:20 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id e7so6156044ljg.10 for ; Mon, 07 Dec 2020 12:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BrKp5QZBrFLEemlH2e3sXwdsiYTPLu+XykhKeVJHdS4=; b=mneoDwGsnzulgWruU5ThMOT0/IiuE1u6PSrBJp94Yi/zIAyOMrDPbQbrSLtQtMHqBa q1NnVlJp/225G9p/3HE/eVwu6y8O2kxw2QUH2W1cgBOd5MP1h6KAFH83+4USgOIHk7yt Pl6UrnfTMhatO6I1+9/MwGWmwc0gCMB/MPoEXNhU4hr9qKTegtAPss34gE4IwQeCObjy TaXHZ54ZQkNELueWd2zOJK+zT67ovS//UZpNeabvXTHHh2iCGP1bdTQQJ64FdtHK65ha INgtCsl68UXdZasGMbBNnTx1l/kf7CU0eLp/aP5t9+Ln5I6iV54i2KgngmuGSX+LAivh CA1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BrKp5QZBrFLEemlH2e3sXwdsiYTPLu+XykhKeVJHdS4=; b=RzRgN2zx9+IiRaqwtpTPHH+FZAIgqRl3MfTBV9qDzhZl9VeQ24yARJvbu2vXZVkS3Y 8x5zq0kBPMpN0I5jEXQfKj2srM5nllP2BlUpmmB20/0+NcYT5k0DWwwZ6303dnQvgaG8 A0WkwTmZF+gjhF4NXu3+EUyzLxv6O2MYH/UemDTDdEfFsXe7rAwKTSnh6Zj1Ld9SfAWx rR0hx5jzBrPs1fVoqF6HszMb13LJG4yNKbh3/p2NYpPiIbBaag7KtwtIc4EVdw3jpQuX oNk13bvmnHrCHfgfD1BPxrX4N/k8tMVV4UZ84k9N5NWDxaMepfkFkdn4SifkvHxzGUVD A9fw== X-Gm-Message-State: AOAM5311+tpM+vw/c1nrwIPvVwscF1ethfXJvmLPfg9q/0MX8KkqN1MY W5JkBc2ycsTEkhyWfPpN1KwOOnWQSW1Tq/KnrT3bXw== X-Google-Smtp-Source: ABdhPJzhSNwZ0Mt2b0Cf1Wa82BSo9SbQ2qDNsIUUpbAinsZXppiI7jjcfzCsQBDtYuYbUn3JBhofcNkFczXQ1LXG5rw= X-Received: by 2002:a05:651c:315:: with SMTP id a21mr8695974ljp.229.1607371218995; Mon, 07 Dec 2020 12:00:18 -0800 (PST) MIME-Version: 1.0 References: <40C39C4D-68C7-4C8E-8841-0F1D5A637BE0@icann.org> In-Reply-To: <40C39C4D-68C7-4C8E-8841-0F1D5A637BE0@icann.org> From: Eric Orth Date: Mon, 7 Dec 2020 15:00:06 -0500 Message-ID: To: Paul Hoffman Cc: Chris Box , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000008839f505b5e54645" Archived-At: Subject: Re: [Add] [Ext] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 20:00:34 -0000 --0000000000008839f505b5e54645 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 2:44 PM Paul Hoffman wrote: > On Dec 7, 2020, at 10:45 AM, Chris Box wrote: > > Given an initial resolver A, equivalence is the claim that one or more > other resolvers B, C, etc are: > > (1) Operated by the same entity as A, > > (2) Have authentication and security properties that are no worse than A, > > (3) Have access to the same pool of names as A, and > > (4) Possess the same data privacy and filtering characteristics as A. > > > > This is not a final definition by any means, but it is at least closer > to the spirit I heard. > > > > Would this definition work for you, or with some tweaks? > > One easy tweak would be to say before the list that all four requirements > need to be met simultaneously. > > The third requirement sounds odd. Would "Resolves all names the same was > as A does" be better? > I think the discussion points Chris was trying to capture there was that a lot of people discussed that giving the exact same results was a non-requirement. E.g. that caching differences and such were fine. So "resolves all names the same" might be too strong in that respect. I think the important part was that an equivalent server would be able to answer for any special/internal names that server A knows about (and that an equivalent server wouldn't respond for any filtered names that A is also filtering, but that is covered by (4)). > > --Paul Hoffman-- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000008839f505b5e54645 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Dec 7, 2020 at 2:44 PM Paul H= offman <paul.hoffman@icann.org= > wrote:
= On Dec 7, 2020, at 10:45 AM, Chris Box <chris.box.ietf@gmail.com> wrote:
> Given an initial resolver A, equivalence is the claim that one or more= other resolvers B, C, etc are:
> (1) Operated by the same entity as A,
> (2) Have authentication and security properties that are no worse than= A,
> (3) Have access to the same pool of names as A, and
> (4) Possess the same data privacy and filtering characteristics as A.<= br> >
> This is not a final definition by any means, but it is at least closer= to the spirit I heard.
>
> Would this definition work for you, or with some tweaks?

One easy tweak would be to say before the list that all four requirements n= eed to be met simultaneously.

The third requirement sounds odd. Would "Resolves all names the same w= as as A does" be better?

I think t= he discussion points Chris was trying to capture there was that a lot of pe= ople discussed that giving the exact same results was a non-requirement.=C2= =A0 E.g. that caching differences and such were fine.=C2=A0 So "resolv= es all names the same" might be too strong in that respect.=C2=A0 I th= ink the important part was that an equivalent server would be able to answe= r for any special/internal names that server A knows about (and that an equ= ivalent server wouldn't respond for any filtered names that A is also f= iltering, but that is covered by (4)).
=C2=A0

--Paul Hoffman--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000008839f505b5e54645-- From nobody Mon Dec 7 12:36:24 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379CF3A097C for ; Mon, 7 Dec 2020 12:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30Yq83Y_o9AM for ; Mon, 7 Dec 2020 12:36:22 -0800 (PST) Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C633A09AD for ; Mon, 7 Dec 2020 12:36:21 -0800 (PST) Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa5.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 0B7KaF7K007132 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 7 Dec 2020 20:36:15 GMT Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Mon, 7 Dec 2020 12:36:14 -0800 Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0721.004; Mon, 7 Dec 2020 12:36:14 -0800 From: Paul Hoffman To: Eric Orth CC: Chris Box , ADD Mailing list Thread-Topic: [Add] [Ext] Definition of equivalence Thread-Index: AQHWzNOaLzxNueozV0+JcLYHcryEvansnamA Date: Mon, 7 Dec 2020 20:36:14 +0000 Message-ID: References: <40C39C4D-68C7-4C8E-8841-0F1D5A637BE0@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.0.32.234] x-source-routing-agent: Processed Content-Type: multipart/signed; boundary="Apple-Mail=_AFB13AFA-3462-41D4-8422-6504E21FF72C"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-07_16:2020-12-04, 2020-12-07 signatures=0 Archived-At: Subject: Re: [Add] [Ext] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 20:36:23 -0000 --Apple-Mail=_AFB13AFA-3462-41D4-8422-6504E21FF72C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 7, 2020, at 12:00 PM, Eric Orth wrote: >> The third requirement sounds odd. Would "Resolves all names the same = was as A does" be better? >=20 > I think the discussion points Chris was trying to capture there was = that a lot of people discussed that giving the exact same results was a = non-requirement. E.g. that caching differences and such were fine. Fully agree on "caching difference". Not sure what the list of "and = such" contains. > So "resolves all names the same" might be too strong in that respect. = =20 Fair point. > I think the important part was that an equivalent server would be able = to answer for any special/internal names that server A knows about Yes, that was the salient point I was trying to make in my proposed = wording. > (and that an equivalent server wouldn't respond for any filtered names = that A is also filtering, but that is covered by (4)). Agree. New proposal: Resolves all names the same was as A does. --Paul Hoffman= --Apple-Mail=_AFB13AFA-3462-41D4-8422-6504E21FF72C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBrYw ggayMIIFmqADAgECAhMwAAAV3RBqFEZex8dMAAMAABXdMA0GCSqGSIb3DQEBCwUAMF8xEzARBgoJ kiaJk/IsZAEZFgNvcmcxFTATBgoJkiaJk/IsZAEZFgVpY2FubjESMBAGCgmSJomT8ixkARkWAmRz MR0wGwYDVQQDExRhZDEtbGF4LmRzLmljYW5uLm9yZzAeFw0yMDA5MTkxODA3MTlaFw0yMjA5MTkx ODA3MTlaMIGUMRMwEQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQBGRYFaWNhbm4xEjAQ BgoJkiaJk/IsZAEZFgJkczEUMBIGA1UECxMLSUNBTk4tVXNlcnMxFTATBgNVBAMTDFBhdWwgSG9m Zm1hbjElMCMGCSqGSIb3DQEJARYWcGF1bC5ob2ZmbWFuQGljYW5uLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMyCemeYYZjhFjqol6d0KFelzUOUxRgoLxxuCY67ssb2elDgD8Vu 0O5fqMb5GwKWGZknC9uG3l3Of8pnfMlHpeFpLz9abvV/esea+JDxt+RgZLZRvJtZ/lVV86BZnjAO kKtLboRpfXTAobOllRTMcDaRksynf2FiF8VPB9vIsAxNT6/p8P3X84zAkBUX9BI1p9Pf/+ksRkau c40q/N7AuAVYAQlOwnN2QG+64T6ofP6kr3DanHuYg2C/5G3RXX58azNgSYnopJ0AiFY9e4M7iVxm Ll5wgmBGtVoLdjFe9HnCk5EdqKk5CE1ll7akYuvMNUqK1ingA5IjAvRZc9hD818CAwEAAaOCAy8w ggMrMB0GA1UdDgQWBBSh5qyXEQo8kO1LLYUKzpRiMxIHMzAfBgNVHSMEGDAWgBTpKerCBbuXyks/ cnl6+luCS7lqhDCB2QYDVR0fBIHRMIHOMIHLoIHIoIHFhoHCbGRhcDovLy9DTj1hZDEtbGF4LmRz LmljYW5uLm9yZygxKSxDTj1hZDEtbGF4LENOPUNEUCxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNl cyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPWRzLERDPWljYW5uLERDPW9yZz9jZXJ0 aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9p bnQwgcoGCCsGAQUFBwEBBIG9MIG6MIG3BggrBgEFBQcwAoaBqmxkYXA6Ly8vQ049YWQxLWxheC5k cy5pY2Fubi5vcmcsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZHMsREM9aWNhbm4sREM9b3JnP2NBQ2VydGlmaWNhdGU/YmFz ZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA4GA1UdDwEB/wQEAwIFoDA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiBurJNhMjIaoOtkz+HlPRag/mIbk6H68s/hoOYWgIBZAIB BzApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwNQYJKwYBBAGCNxUK BCgwJjAMBgorBgEEAYI3CgMEMAoGCCsGAQUFBwMEMAoGCCsGAQUFBwMCMEkGA1UdEQRCMECgJgYK KwYBBAGCNxQCA6AYDBZwYXVsLmhvZmZtYW5AaWNhbm4ub3JngRZwYXVsLmhvZmZtYW5AaWNhbm4u b3JnMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQMEAgIAgDAHBgUr DgMCBzAKBggqhkiG9w0DBzANBgkqhkiG9w0BAQsFAAOCAQEATidKimzbAoiiUW1wn7PWGyvBra29 qfQFUkoiN910zUtEigII3eYlf6lgokLPem1VGMAbRDJaDZNDy/1piuJFxtH2qLqqM1KL0jhLD62I 1JlpoUSSVCs0I0c+WoMafG1+TxDHvKOJ+88uR5EE61qoeHBe5pCIeQYzPyEbcJRIqavNj6DKg5Nm AwkwZwCSPGwb7WlKwxnf3X+Zx2emG+AB6k+q+jZA3obglwR5NFov1CeOuW5qQNzB9FIzbZGDjNsJ SwY0ygGnYItvhxb+if9I4NnuZGy41dwwDql40ZGmJg1yUV8niDpUxFUdAdXdeCoVoTPAK7ZDUS8y bo/Iyo/aEzGCAyAwggMcAgEBMHYwXzETMBEGCgmSJomT8ixkARkWA29yZzEVMBMGCgmSJomT8ixk ARkWBWljYW5uMRIwEAYKCZImiZPyLGQBGRYCZHMxHTAbBgNVBAMTFGFkMS1sYXguZHMuaWNhbm4u b3JnAhMwAAAV3RBqFEZex8dMAAMAABXdMA0GCWCGSAFlAwQCAQUAoIIBezAYBgkqhkiG9w0BCQMx CwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDEyMDcyMDM2MTNaMC8GCSqGSIb3DQEJBDEi BCCBAz+P5JXQ+ATSwKX/aFrrAteZbYxKPl0cooXjabFwvTCBhQYJKwYBBAGCNxAEMXgwdjBfMRMw EQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQBGRYFaWNhbm4xEjAQBgoJkiaJk/IsZAEZ FgJkczEdMBsGA1UEAxMUYWQxLWxheC5kcy5pY2Fubi5vcmcCEzAAABXdEGoURl7Hx0wAAwAAFd0w gYcGCyqGSIb3DQEJEAILMXigdjBfMRMwEQYKCZImiZPyLGQBGRYDb3JnMRUwEwYKCZImiZPyLGQB GRYFaWNhbm4xEjAQBgoJkiaJk/IsZAEZFgJkczEdMBsGA1UEAxMUYWQxLWxheC5kcy5pY2Fubi5v cmcCEzAAABXdEGoURl7Hx0wAAwAAFd0wDQYJKoZIhvcNAQEBBQAEggEAAlB/ejAkIUJvZY3Zigys R8PusKL6UZKqvIs9IkAw8ICuPtwPp8AwOUOq2fnHiWX5tE4t9AOSRtPe+06Pl7owUBKQm8G2bxkT 6Ks9t737OIoFJWfFudKExlpDD68LgAu1y2cnBgGfpSeoCKunzU2ecioy38EVokfzexlofF0eQeRE /DxwE+g7Jk7X8naB2CYjpYhcddXIyeSvh/vBzhP0rWzBhiY4X+KSLQ5lSlkSFKyp8xM05DlDFhZb xbRwdr5H1lf9Kri87dDfT84cAqIfbn8rK5GELaNJkWhxcKQiqG+oIx6TYe/8TIIEeoHkCl5FWIur tD9T5wk77y0BR3ce3wAAAAAAAA== --Apple-Mail=_AFB13AFA-3462-41D4-8422-6504E21FF72C-- From nobody Mon Dec 7 14:38:31 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008203A0B23 for ; Mon, 7 Dec 2020 14:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke94stYD6vr7 for ; Mon, 7 Dec 2020 14:38:28 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400120.outbound.protection.outlook.com [40.107.140.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161163A09D6 for ; Mon, 7 Dec 2020 14:38:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iYfz5WxWGZPoAj6jg0hAalwZ26C8Xd1Zqn7JTwMgEBa5XFtiDy79YqJIfinzHNfsLuY6rJJjVIrYjtCgYmWrQT+rXJ03aTIb3BGGt9r+Q5s6P3PGZfG7ZIXjsGF+ysThyqispqS3n3gFUCwSQ7dHPEq/Oc/z8Z0YDmACz8qSItZkhxcXQlKxTJcbE8tTIex8z3mM2qqfsxp8E7W5jNVCGvIbXRKkIcmHEhgZq13dsGyqrZydICPgRiiWii9BmVP9TMK82oQ7ZkP1OWTtkjg8jMH1sWjaYa7uqvEX+ewBY++AlrBFyImMnKXJllYwFXYhNxo2Vi8hNXJLw56cl3bMtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6wGyAP6iVGqnxzu2IEyDbk5i9ulYkSwfjO3cg9JbjHM=; b=mUessH/q+O0zTfvbDQAWicNI1VCu1jFDaY5nm5/Uk3g564DZdLFAigPHzHrLuQH+gCYLu/LBJiSyfNGLu2d+E9Yu9M3aocLTf0MjtME80CsC5pP6tsFqXKNjJUOn9P59asBqgxPM96l8Si01j0Vhstz/5Ya8hTo/m9DQYZF/j3DednDa/ZCbMfTETg2mposHXJGVw775Ve/aI3BYDFJmnalE4OvJh3EvvQR9rqxYuHeAuX473AYe6WbIow/IwbPqLUmLBu7+P5X0wF3Mnzn5OzjT6V2vz0GF0+O/XI7a6rKaPuP4PZFBp/GUqkQv76qZEClHmsntlbLmxJKH8nacjg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6wGyAP6iVGqnxzu2IEyDbk5i9ulYkSwfjO3cg9JbjHM=; b=s3qiSCo1SjR4/XrYIVztwIKOmSzvz7LdaDRcCRPxT92VLV3taNN9BE7aS59G18BeoaT5F/IWaLxa+LVSlx+966XGMpy2/MmEavM81rjd7pdfQg3umGsH5LKzn3CG4kq96/e/30ZFTdpGBB8XJO98zaiJ5K4FCYHcuUZTpMKt7+A= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) by OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17; Mon, 7 Dec 2020 22:38:25 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::cd30:9f1d:e76d:e8a8]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::cd30:9f1d:e76d:e8a8%6]) with mapi id 15.20.3632.017; Mon, 7 Dec 2020 22:38:25 +0000 To: Chris Box , ADD Mailing list References: From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <21eb713a-59bc-a50e-9b8d-093087a3a888@it.aoyama.ac.jp> Date: Tue, 8 Dec 2020 07:38:23 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [114.182.253.12] X-ClientProxiedBy: TYAPR01CA0041.jpnprd01.prod.outlook.com (2603:1096:404:28::29) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (114.182.253.12) by TYAPR01CA0041.jpnprd01.prod.outlook.com (2603:1096:404:28::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.17 via Frontend Transport; Mon, 7 Dec 2020 22:38:25 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 41887e91-9aa8-4ae4-d096-08d89b00cf69 X-MS-TrafficTypeDiagnostic: OSBPR01MB2566: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FKhtIkbe+r2/QRG/9oRJkFejkYb2s8v8mvATge/2tFn4wpk6X0teE9C0IiSprwneYr8iYWpmGwyPywIZSAyRDD5u/cfoEZX4AvXT9nzmc1aKUFehNiP89JPAnPPoMFlMYhYLQk0L2GWoAOOzBiBVqDv+GzH0MaGTf/NRtCVOi3VllZumE9nzpia8PnDDhDH/Nbz0ZOtwzmSg7vuUVAL+ns3aaw0W5xuAZo4VpXbmjRFrrzMKKsiIvaQmE/6GZEnFjDJi8u0OxUnyzOPFVYfG2RPqnBIKl6sfaZZF/++r7+sh2GCcSPV7PqtMphvTi4Q7pMh95foLgqaH/Tld0FrzlAtsxaJrSNGdOT03e+BTGwsQiHhAsIktB2vBw9Vf3Z4Eane1dSLilHfMYGzzBCiVVJSDA2EyZGFf6siTzWKkitg= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39840400004)(366004)(396003)(136003)(376002)(8676002)(36916002)(52116002)(83380400001)(186003)(26005)(31686004)(956004)(53546011)(2906002)(66556008)(5660300002)(8936002)(16576012)(478600001)(16526019)(786003)(2616005)(110136005)(66946007)(31696002)(66476007)(86362001)(316002)(6486002)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?SC8wUW0vVGgvMEVsSWRHY3VyZHh6dXBlQi9jcldoWFpHa3ZzaWgwTVVCVm1k?= =?utf-8?B?d2VCUzVoMFVUUy83WTk2TzRJMjFMZDJ3YUdXMkZuSitXZHpPRlZlMDU0aHVw?= =?utf-8?B?YWxvR3VzY1ovckM2TE5BeS9jUVVKcHpOUkVKYk1mVGoxWDNBVHZ2dENQcG1L?= =?utf-8?B?Z2xRUUlXWGE0cVFtOEtJUmt5d25yeVRLV0wxMzMvcGdIaElQN2M4SS95VHVS?= =?utf-8?B?TVJnRnRSeUxOY3dUdUxrTEh2Kzl6SWdUcXA3Z3V5M2VLWXRxb1RiY1ZkOEEz?= =?utf-8?B?TE1vWWtuVE1ubnZScnl0UlZaUTA2bHlLSTF3T3RWU25kUGxFY0FaK3RTa0ZN?= =?utf-8?B?OUFmRTNKM3J2d0pmQkJUSDk5QlFCUStFV3B1azcwVTM0LytLcVBpSTRKRElm?= =?utf-8?B?cWs3ZVdLR01KV1YyRHUxcUdYUUxob0lEa2tibVorUVFtUExwY05IOHJPa05w?= =?utf-8?B?US8rUVpJblgzOENvOTN3dk5obFFxNTNWVmJtZ3EybjlZRURRclFnWHk2M2oy?= =?utf-8?B?WDlPV04rU2dSSFplK1BoVmI5dFhFczFYVG05RjVyZ2VDeWkyeHY1WVBGK3dj?= =?utf-8?B?bDFJOVNYWnp5OThlMFFJNnF5WWJaVVFWUHMyZ1FFeHVpZ1drRE9SWWY1K2NR?= =?utf-8?B?bXJMMW1RbURmd1Fvczl0NWdpMXZGeUdVZXcwVXZkMlYwN2JOdS9JaGw0NU9E?= =?utf-8?B?cFR3Vlc5M2w1anB2cEhQV1QyajBCUEV3eDVxUDNMMnduenJzT3VCUTR6bmcx?= =?utf-8?B?SzBFSUo0Vk45eEVJeHMyREhPZnZ2RXNVUmNGek85QWthTm53R2JjYThFS3g1?= =?utf-8?B?aXNpaHl3ZFFiMEE4UEJsWFhYNGh5LzJNMG9NNUhyR0U5Q0FHWkF2M3NYMlBD?= =?utf-8?B?Uk1ERXJsY01sOS96MmlYdGhLUkFObmt2SSs4M2VXcDlpUXZZZzZIcDYwVThE?= =?utf-8?B?YUNDMmxCNTRneUwyZE1aamlhbnJubXNYbm1PNWsyaytzd2Vtd2ZLZEZScTBH?= =?utf-8?B?VUt3RVFaV0Y5bnBCeDIramkwNXhjeTdGbFlvTUcwN1Mrb0dPcFBRcTRneEVB?= =?utf-8?B?MmZLRWpNRzRHR3BqRnczc2IrKzlkSGdyVWdZMWcrRXM4NzU2U094TXF1Vk9o?= =?utf-8?B?NWhYcEFvaTQ5OGFZRVVkcmxDbFd6cTEzWDJjLzBZS2Y4WVpvekR3a0dBbzFn?= =?utf-8?B?eEIrZ0J5YmdyeE95MmVjZXlZVDlhcnhJS3FpMXhSSWRyWWx0cmlxblpzc2Nn?= =?utf-8?B?a09vNHh4a3VEZkZOOTJCT2NxVXVxbzdhOGZGYWkyYnY3QWZxSkNsTlJMZTRB?= =?utf-8?Q?B8RXKg7n5YCvsWxLA3sEOnrH+gXhYALYWu?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 41887e91-9aa8-4ae4-d096-08d89b00cf69 X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB2566.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2020 22:38:25.7047 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: RHtDpoWs5dik0dsb5uOFNtaFIyIyrzVm1kmi24VMfnsEhCFG7CLLxcrZk8hnoGuZ2LfvL3lsxdPRUfWtWHV/yQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB2566 Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:38:30 -0000 Hello everybody, Just one point below that caught my eye. On 08/12/2020 03:45, Chris Box wrote: > Hi everyone > > During 109's discussion of the concept of equivalence, many valid points > were raised. I've attempted to take these and incorporate them into a new > definition, and came up with the wording below. > *Given an initial resolver A, equivalence is the claim that one or more > other resolvers B, C, etc are:(1) Operated by the same entity as A,(2) Have > authentication and security properties that are no worse than A, "equivalence" in most people's mind (and in Mathematics) is a symmetric relation. I.e. If A is equivalent to B, then people may easily think B is also equivalent to A. However, the "no worse than" in (2) is contrary to this symmetry. The right thing to do may not be to change (2) (because that's what's important for your application), but to use another word that equivalence. At the least give a very clear health warning, e.g. as follows: "Please note that this definition of equivalence is not symmetric, i.e. if resolver A is equivalent to resolver B, this does not imply that resolver B is equivalent to resolver A." Regards, Martin. >(3) Have > access to the same pool of names as A, and(4) Possess the same data privacy > and filtering characteristics as A.* > > This is not a final definition by any means, but it is at least closer to > the spirit I heard. > > Would this definition work for you, or with some tweaks? > > Chris > > > P.S. Thanks to Andrew Campling for his help in summarising the output of > 109. > From nobody Mon Dec 7 14:59:16 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5EE3A0C23 for ; Mon, 7 Dec 2020 14:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n73Zq8jOPRe5 for ; Mon, 7 Dec 2020 14:59:13 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100074.outbound.protection.outlook.com [40.107.10.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924753A0C22 for ; Mon, 7 Dec 2020 14:59:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SiO6wG/K9ki6HtI3IBVvv4d05g+DsakaAArddv90+aEFLSq+K4aymBbXV1BKffge0sON0xg4P+Z0qWENLWyF6199kaNQ3J2cQtx2cAk8NjLXtBn2HuNcoiE1AZuLywaqPtUGMAfA5GleqpdgPeDY0wzB8FmZCMixCFsVn3fR6F9i34TVyNrNQSt/mo0j9YqSj6aPrbgNQluhMeHM3PeYzcZzqnyyTPDoKZGLx8AjN3rKyJwQNjjzHaWjUnLe4irq+TuzUAMoJ2hwjy3GRB+uWSyWkLAIqSTDum1R+wphhczw1x4YjW2aoR8CzSlUVd3gPHEIBgXjUVNefX7f307fIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tDcYdcRBFHGVKoy6SdARHWBoFQEacLzjC11qEsHjgY8=; b=bqZHTndixG1i9fjmr53jT2EhZfFQ/ocjJXq/iG9JKlbW/OqPS/negRBJSj4ESVjSDz5OynfgC6IzerJO1hndgrajO39Ptmr+hQht8iGGzS6iYiAOhXk5PE6OMU/3Fr9iAdfhUi8eL0+XOlZGfOVsig6eIjTgNAZlNumTSFcMIbAtEh2OaKJK8WZZFpaiW9lYKfAd5g82e0M487ZlSBabuPduazVdJ2xti+q9qZQ9JyCwiCLm9IWgGUwk8oAt27/yKfKcdPPGv7b7tO3JD80hbOE41l0+BvJH6BXxkOpvE82BAu7NmeAB5+qfwblf6jojxAWSc+Lp+7WBF4kIkOgXDQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tDcYdcRBFHGVKoy6SdARHWBoFQEacLzjC11qEsHjgY8=; b=GQZf6XbbGXZa+eQNwlFvaDufduCJDDQpMDah/KHpa4UeZWwrD19DZoRXwTpjR+fXs+5Yj512OGSWHEDp4iFdU6TdKPld3pMtdVX9ar2KA5bI3iWuRPJWj1JpRnubt19k7GK1W1+BCcUUOJ/cajZcY7+OHgRjbiH1JFsdgrIdIWY= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) by LNXP265MB0188.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:10::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Mon, 7 Dec 2020 22:59:07 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::4074:aae:262:a640]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::4074:aae:262:a640%7]) with mapi id 15.20.3632.021; Mon, 7 Dec 2020 22:59:07 +0000 From: Andrew Campling To: Paul Hoffman , Chris Box CC: ADD Mailing list Thread-Topic: [Add] [Ext] Definition of equivalence Thread-Index: AQHWzNPofS9lrnIQ6UqmxzaqL2R4ransPXsw Date: Mon, 7 Dec 2020 22:58:53 +0000 Message-ID: References: <40C39C4D-68C7-4C8E-8841-0F1D5A637BE0@icann.org> In-Reply-To: <40C39C4D-68C7-4C8E-8841-0F1D5A637BE0@icann.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: icann.org; dkim=none (message not signed) header.d=none;icann.org; dmarc=none action=none header.from=419.consulting; x-originating-ip: [81.141.78.193] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3687b381-377c-45d7-b742-08d89b03b3ec x-ms-traffictypediagnostic: LNXP265MB0188: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xMqLV0nBvJWn9o+vjjikK/yfsR98blkbHY1RscvxfDNuP6Zzkr0srC1iTK+Zn2VawTnPk9aLqehXgBVwlLp+Joj0RU9hRo7d+Ej49Jn8jwn0FrDyBm7oA07eA+RuVT4ZkaqdsoeFNWALQTkFvxn0+MzJEm9y6Ry4gn/Es8kRuZ7Op0mIaKIrQ6eQAU/3yGHHOJajJs5kw+G7kfgXa1cm9pQOSLGcl0693c3CYa3QfVHfUoQ/WkGNSQH4sbMHq4kkEtArHfkdsoiPv6xstDYHWI4ZJcEJbkzpadDdBfavpvrnDor1rPdWx/7JitV69MScORhdn4OiB8UEjJHMzb6+M8OKD2UW5azreaCG05gvNptwgunlF4HWXZFr93zO9hAP x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(136003)(346002)(376002)(8936002)(52536014)(71200400001)(8676002)(66446008)(110136005)(55016002)(26005)(66476007)(76116006)(2906002)(53546011)(66946007)(66556008)(4326008)(33656002)(6506007)(86362001)(7696005)(186003)(508600001)(6666004)(83380400001)(64756008)(44832011)(5660300002)(9686003)(46492008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?46Rd8J9pjxyCoVmqtjqAIgIc7Oju+IEtuJxo9Pf4dC0z/WN/FBjY/sSwoY8E?= =?us-ascii?Q?q4YSNvJrMSmFbuD6nLflfR+AagNlx/fuZeYzBiX82hE+tn4G9PTCUV9F72z4?= =?us-ascii?Q?AOePNz0U8kweT4bBs+nXsdkCHIbB+PNa2dFXks0pYJ3twv+rAXby+r5li3O0?= =?us-ascii?Q?KrZdxirwnJ4gZHo0wxm/2EFWTRUmX1lphXKiXFicla/pSmOnaT588y2hNWJe?= =?us-ascii?Q?/6SFZMzDc8BjgBrRTGEknBqeFM0mt9NXEaFS2gILanVeMRjDT9c071NWKS7Z?= =?us-ascii?Q?NlSavFXMgx7EuZIZf8T1eThliGcxw76w+rXRYpMqgzM50hbFqriXIloEeUS+?= =?us-ascii?Q?/oytb/zEXPr4E6yXUaUxDZJprI3iGTpV1buRU9vlFkQW61M9nql9d78DTvSe?= =?us-ascii?Q?RdrWrCVB12hjU921N3kchrkkpa/e6c6K334vRkioAqBYin5zn6kQrQBdKpdF?= =?us-ascii?Q?L1D+o/viIkACDSx5c66Y9cmFpCcoOLw+SoFXXBvDQ3hxkQEIUEa93CSqWO1f?= =?us-ascii?Q?8eayCfDmJRxq8U4veX1rhhT1/TNzpWCPAWolN+W+nSV8XQoVT1+9G/Qbubv/?= =?us-ascii?Q?L48O5M5/JnP4nWdyr54iPwmVv52LPT9qtj0aHhgg2Pl7YP3COECVyJGUTcVX?= =?us-ascii?Q?KvGLVsbFe/h2nsFbXJhg++DNWEhTssqS3UbwpbhBsHyvLrjdgJRiAakhoqK4?= =?us-ascii?Q?ubT/iLTvR5yIEIuMin8aY49MY5LGSlJ1kpl1zQzJG6ZzhNgxybuILy7eLdGJ?= =?us-ascii?Q?aLbkz4MiDUIsoWc2LrwAfXmre20WGUgyFd0qaP4lbFlpV3cO3iVt8h59Fd3u?= =?us-ascii?Q?SH7RZGa70gxcnqyOhBMZOAKZSU4hmdKpU6E0O+onJLn+74Vk83Nv8mLZNMYP?= =?us-ascii?Q?8To+ghJq8JhkH7iGTZjtNcnrv60NzsvA7IQ5XFAlNKsQ0ZxY0LAWzGZW/Zzu?= =?us-ascii?Q?8oT1PRaO9pmcYDKfRPM8q7sCo6MDLCzRIZ3yOOVzGmY=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3687b381-377c-45d7-b742-08d89b03b3ec X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2020 22:58:53.0192 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tJzOAWa7hS/I8YSjdWGwB7IaLPTyXsY6I6u9L+d26s1EfqsqWxUXcYgmN4mkBIUcZxjXDipvU8sPC2uaYsMcrnbYBc+zFpCE172zEOUc1LA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LNXP265MB0188 Archived-At: Subject: Re: [Add] [Ext] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 22:59:15 -0000 On Dec 7, 2020, at 19:45, Paul Hoffman wrote: > The third requirement sounds odd. Would "Resolves all names the same was = as A does" be better? That looks another way of saying they should give the same answers (apologi= es if I've misunderstood). Ted Hardie addressed this during the IETF 109 W= G discussion as follows: =20 "If someone tries to test whether this is still equivalent. Unless they're = serving out of same cache, they can get different answers just because of t= he rest of the system changing over time, in a way that is not a function o= f the resolver." Andrew=20 -----Original Message----- From: Paul Hoffman =20 Sent: 07 December 2020 19:45 To: Chris Box Cc: ADD Mailing list Subject: Re: [Add] [Ext] Definition of equivalence On Dec 7, 2020, at 10:45 AM, Chris Box wrote: > Given an initial resolver A, equivalence is the claim that one or more ot= her resolvers B, C, etc are: > (1) Operated by the same entity as A, > (2) Have authentication and security properties that are no worse than A, > (3) Have access to the same pool of names as A, and > (4) Possess the same data privacy and filtering characteristics as A. >=20 > This is not a final definition by any means, but it is at least closer to= the spirit I heard. >=20 > Would this definition work for you, or with some tweaks? One easy tweak would be to say before the list that all four requirements n= eed to be met simultaneously. The third requirement sounds odd. Would "Resolves all names the same was as= A does" be better? --Paul Hoffman From nobody Mon Dec 7 15:12:38 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9083A0C45 for ; Mon, 7 Dec 2020 15:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=EVVKTweP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d4Z/6R2h Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPPuzwW9QfOm for ; Mon, 7 Dec 2020 15:12:34 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36383A0C0D for ; Mon, 7 Dec 2020 15:12:34 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D8B8D5C0226 for ; Mon, 7 Dec 2020 18:12:33 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Mon, 07 Dec 2020 18:12:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=SHY7skm3Bsi//3+nsjFvm55c8wrXbEo OyF2BhvYB+vI=; b=EVVKTwePBUzb4ZfsGjog7vY14Tq68x6Wn+m5cuixRv7vc7R 9K5KgJKPebIo9MjKfjWZnHxnzIFIowb4EG9bHhv7m0fVAOMpy49INIXfztpmuToa tP309IZJSuwc9d6ST5X4uUUzYQ81CBysBju9cABzRZQZTfd1abd79/jU6zPwzezg GPTyuzkstP/NhtcG/MUZJbIJGmbf9fLmlmw4Z51B/863wzVt1ySlAZXrh6+uMVIb J+CW/mrpBGu43EsM1mHLqm/I5Yf8UxI2d9TvgFitwefGxPVXP0mO2rUeObN1N0lx iAbdPqjgShXEod85wfM3oPQZBxUteSVl6DmlTeg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=SHY7sk m3Bsi//3+nsjFvm55c8wrXbEoOyF2BhvYB+vI=; b=d4Z/6R2hW0bAoop77GATyR O6B5wi7D2xT0LLGbEzVEXbxG0j78Nx6gwUUpxykFUxGjz9fv1vbjL1ZYPQh8qoZm NbzlwEyi9INFVwLhzWCYgP/XezUCXJsIAe6d/wPgB2I5TrY5myedxP9AcXvZuCbF hO/Ln7j9dkilHPP7lB4C07B+LxVV7cf3SMZ+0KOE0ECaUpvgRsmMXtYKKHsCXHv7 9s3kR+6ext+4+2Yduv57ITlr26jVjyR32rxJOgjwEIfDrDsVLUfv+dh2GFWTQf2A 5ymXsWfmdhFI9VgmFWfY1MHmnghIABAyhbz/zA7Mjag9AUc8W2kgF25KqJpJGuSA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejhedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefhiedttdeviefhjeejgf evfeeuudfggfekveekheeugeegleevkeevkedthfeuieenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5FEA720126; Mon, 7 Dec 2020 18:12:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> In-Reply-To: References: Date: Tue, 08 Dec 2020 10:12:15 +1100 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 23:12:37 -0000 The message I got from the discussion was that equivalence was not what we were looking for. Why is it not enough to say that an pointer is enough? The entity providing the pointer can apply its own policies in determining what to point to (which might include the below), the entity following the pointer can do the same (again, including the below), and we might strongly recommend certain properties so as to create an expectation that the properties hold, but that's not equivalence. >From my perspective, I would like to see a recommendation that the pointer only be given if the alternative resolver provides cryptographic protection for queries and responses (equivalent to DoT/DoH), has access to the same set of names, and has equivalent or better privacy treatment for queries. That's 2-4 from your list, not 1. The same entity thing is not a good idea. I understand that people might want to enact that policy, but there are enough networks pointing to external providers that removing the option would be unwise. I also understand that some networks or jurisdictions or clients might insist on this rule, but I don't quite understand how they guarantee that if it was important. On Tue, Dec 8, 2020, at 05:45, Chris Box wrote: > Hi everyone > > During 109's discussion of the concept of equivalence, many valid > points were raised. I've attempted to take these and incorporate them > into a new definition, and came up with the wording below. > > *Given an initial resolver A, _equivalence_ is the claim that one or > more other resolvers B, C, etc are: > (1) Operated by the same entity as A, > (2) Have authentication and security properties that are no worse than > A, > (3) Have access to the same pool of names as A, and > (4) Possess the same data privacy and filtering characteristics as A.* > > This is not a final definition by any means, but it is at least closer > to the spirit I heard. > > Would this definition work for you, or with some tweaks? > > Chris > > > P.S. Thanks to Andrew Campling for his help in summarising the output of 109. > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > From nobody Mon Dec 7 15:46:21 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CA13A0C82 for ; Mon, 7 Dec 2020 15:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7SdrIngZ3nL for ; Mon, 7 Dec 2020 15:46:17 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216953A0CB4 for ; Mon, 7 Dec 2020 15:46:16 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id q25so2475268otn.10 for ; Mon, 07 Dec 2020 15:46:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zmm1YSGfFzh9k8n1B7DLmb1L48YEEPxrKoYnmSL3FVM=; b=Uk+3gy4nCmYXb9Xo3DZF2GvjNhW3eTmRoA5uMzIboAS02Vr/vt1pYv7xWNgbj//bBX rhjo5OXuHEWpxqTYTkbKdd1Ewt8k7nSB0H11wa+FrUKn20WTuk3sCpNsnlaP7lei+Ptf vPIbSCduxYj7uYcv8vc/yHNnAq712RdCAIjOguZ+313Hs5m5Wte80MZsFqfQ5KVWNnOs pVFShMahN30g2SQWRp9Nf800O9ClnuwhJGuANkPLML2w1kjQLlMXoieZbdCRAMz7iuzj 6lfOZ2AKKasnn+kzVYxxCvuPGPqT1X43z4IVmx7dR3FZCZkvYcPJ7W6sBwtqzYv0dSWK 13dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zmm1YSGfFzh9k8n1B7DLmb1L48YEEPxrKoYnmSL3FVM=; b=IAgAFv51KgbFnIgMt2kzLdCzgMW64KY5LHxoQfb+xe8gMGQpbpWRIhYhHg9bZfwu3b RcDy9YEe53r9eDZJvvs99BQgZJyvstuKCsGpzUUL/b7ekb/f8vuYJ3XjgxTE6VcbStmS feFN4ZyHcwArgUEU7wVgTmmP0YKs4yQIPAJriIf9cbWA62xtIpPZcMMx3aDmFK33Ki/5 idxWD2optPuZg11Y5hoW+xvhrUPKVNYpNOD8u9sXQGQvMa4l1pdEK2NPoUSS2XEW72SI 73T+kdCCAEBfKSanUJ5mDAP9JHzeX0jDbnZHehhdERkSYIHTNY6p+KnpMwDHlPYMaBe6 fydg== X-Gm-Message-State: AOAM532nOAw8jBdr2rNHH5SU3jLKAz3VFbrzcYgErobZhrcX2rfVgu5h tvUIASmJU9gji35XQ6x/ENaqyPR0p06wuxXKltY= X-Google-Smtp-Source: ABdhPJyzELn6K8VjnDtGdULh87j3WXoVIdTTULFfSBVlYPFRxz70nXlj8AxMNKL0G6CEAsJlHdRDRbOJtziNR6HBMxY= X-Received: by 2002:a9d:6208:: with SMTP id g8mr5061740otj.165.1607384776160; Mon, 07 Dec 2020 15:46:16 -0800 (PST) MIME-Version: 1.0 References: <40C39C4D-68C7-4C8E-8841-0F1D5A637BE0@icann.org> In-Reply-To: From: Ted Hardie Date: Mon, 7 Dec 2020 15:45:50 -0800 Message-ID: To: Andrew Campling Cc: Paul Hoffman , Chris Box , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000099babd05b5e86e47" Archived-At: Subject: Re: [Add] [Ext] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 23:46:19 -0000 --00000000000099babd05b5e86e47 Content-Type: text/plain; charset="UTF-8" Howdy, On Mon, Dec 7, 2020 at 2:59 PM Andrew Campling wrote: > On Dec 7, 2020, at 19:45, Paul Hoffman wrote: > > > The third requirement sounds odd. Would "Resolves all names the same was > as A does" be better? > > That looks another way of saying they should give the same answers > (apologies if I've misunderstood). Ted Hardie addressed this during the > IETF 109 WG discussion as follows: > > "If someone tries to test whether this is still equivalent. Unless they're > serving out of same cache, they can get different answers just because of > the rest of the system changing over time, in a way that is not a function > of the resolver." > > > I found Paul's formulation a bit hard to parse. I think the informal way of saying this is that when a query comes to A, a pointer to B means that A thinks B will be able to answer the same queries in the same way. That is, it has the same pool of names (so, in the case of split DNS, it knows the "insider" names), would apply the same filters, has equivalent or better transports from a data integrity/confidentiality perspective, and would behave the same way to the query stream (monetize it, post it on twitter, mock it in a low tone via speaker on 34th Street). I don't think I care that B is operated by the same entity. If 8.8.8.8 signs an agreement with 42.42.42.42 so that SK Telecom provides the same DNS service as 8.8.8.8, they could give me a forward pointer to 42.42.42.42 and I get to decide to follow that or not based on how much I believe Google (since they make the assertion). In the moment, I have no way of checking whether the forward pointer service is operated by the same people. Since some anycast services have instances that *aren't run by the same organizations* now, this is already an ambiguity of DNS resolution, and I don't think requiring it here is useful. Either you believe the people giving you the pointer or you don't. But that's likely based on local config, not in-the-moment confirmation. Ted > Andrew > > -----Original Message----- > From: Paul Hoffman > Sent: 07 December 2020 19:45 > To: Chris Box > Cc: ADD Mailing list > Subject: Re: [Add] [Ext] Definition of equivalence > > On Dec 7, 2020, at 10:45 AM, Chris Box wrote: > > Given an initial resolver A, equivalence is the claim that one or more > other resolvers B, C, etc are: > > (1) Operated by the same entity as A, > > (2) Have authentication and security properties that are no worse than A, > > (3) Have access to the same pool of names as A, and > > (4) Possess the same data privacy and filtering characteristics as A. > > > > This is not a final definition by any means, but it is at least closer > to the spirit I heard. > > > > Would this definition work for you, or with some tweaks? > > One easy tweak would be to say before the list that all four requirements > need to be met simultaneously. > > The third requirement sounds odd. Would "Resolves all names the same was > as A does" be better? > > --Paul Hoffman > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000099babd05b5e86e47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Mon, Dec 7, 2020 at 2:59 PM Andrew Campling <andrew.ca= mpling@419.consulting> wrote:
On Dec 7, 2020, at 19:45, Paul = Hoffman <pau= l.hoffman@icann.org> wrote:

> The third requirement sounds odd. Would "Resolves all names the s= ame was as A does" be better?

That looks another way of saying they should give the same answers (apologi= es if I've misunderstood).=C2=A0 Ted Hardie addressed this during the I= ETF 109 WG discussion as follows:

"If someone tries to test whether this is still equivalent. Unless the= y're serving out of same cache, they can get different answers just bec= ause of the rest of the system changing over time, in a way that is not a f= unction of the resolver."



I found Paul's formulation a bit h= ard to parse.=C2=A0

I think the informal way = of saying this is that when a query comes to A, a pointer to B means that A= thinks B will be able to answer the same queries in the same way.=C2=A0 Th= at is, it has the same pool of names (so, in the case of split DNS, it know= s the "insider" names), would apply the same filters, has equival= ent or better transports from a data integrity/confidentiality perspective,= and would behave the same way to the query stream (monetize it, post it on= twitter, mock it in a low tone via speaker on 34th Street).

=
I don't think I care that B is operated by the same entity.= =C2=A0 If 8.8.8.8 signs an agreement with 42.42.42.42 so that SK Telecom pr= ovides the same DNS service as 8.8.8.8, they could give me a forward pointe= r to 42.42.42.42 and I get to decide to follow that or not based on how muc= h I believe Google (since they make the assertion).

In the moment, I have no way of checking whether the forward pointer serv= ice is operated by the same people.=C2=A0 Since some anycast services have = instances that *aren't run by the same organizations* now, this is alre= ady an ambiguity of DNS resolution, and I don't think requiring it here= is useful.=C2=A0 Either you believe the people giving you the pointer or y= ou don't.=C2=A0 But that's likely based on local config, not in-the= -moment confirmation.

Ted

= =C2=A0
Andrew

-----Original Message-----
From: Paul Hoffman <paul.hoffman@icann.org>
Sent: 07 December 2020 19:45
To: Chris Box <chris.box.ietf@gmail.com>
Cc: ADD Mailing list <= add@ietf.org>
Subject: Re: [Add] [Ext] Definition of equivalence

On Dec 7, 2020, at 10:45 AM, Chris Box <chris.box.ietf@gmail.com> wrote:
> Given an initial resolver A, equivalence is the claim that one or more= other resolvers B, C, etc are:
> (1) Operated by the same entity as A,
> (2) Have authentication and security properties that are no worse than= A,
> (3) Have access to the same pool of names as A, and
> (4) Possess the same data privacy and filtering characteristics as A.<= br> >
> This is not a final definition by any means, but it is at least closer= to the spirit I heard.
>
> Would this definition work for you, or with some tweaks?

One easy tweak would be to say before the list that all four requirements n= eed to be met simultaneously.

The third requirement sounds odd. Would "Resolves all names the same w= as as A does" be better?

--Paul Hoffman

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000099babd05b5e86e47-- From nobody Mon Dec 7 20:43:33 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F59C3A0E1D for ; Mon, 7 Dec 2020 20:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhGI8X7M7WTA for ; Mon, 7 Dec 2020 20:43:29 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EF823A0E19 for ; Mon, 7 Dec 2020 20:43:29 -0800 (PST) Received: by family.redbarn.org (Postfix, from userid 716) id EC59EC3F03; Tue, 8 Dec 2020 04:43:26 +0000 (UTC) Date: Tue, 8 Dec 2020 04:43:26 +0000 From: Paul Vixie To: Martin Thomson Cc: add@ietf.org Message-ID: <20201208044326.2kzcb6fg6egl2cxz@family.redbarn.org> References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 04:43:31 -0000 On Tue, Dec 08, 2020 at 10:12:15AM +1100, Martin Thomson wrote: > ... > > The same entity thing is not a good idea. I understand that people might > want to enact that policy, but there are enough networks pointing to external > providers that removing the option would be unwise. i read it as the DHCP-assigned server and the prospective-other server being operated by the same entity, not that the client's attached network and the prospective-other server being operated by the same entity. > I also understand that some networks or jurisdictions or clients might > insist on this rule, but I don't quite understand how they guarantee that if > it was important. "guaranty" is a nonsequitur here. what we have to do is describe equivalence for the purpose of defining polite behaviour. the description will not cause politeness; if a user or device or app is going to do as it pleases, either ignoring or never hearing the equivalence principle at issue here, then the issue is the impoliteness not the non-guaranty. RFC 8484 says that "this protocol is designed to prevent on-path interference in DNS operations", by which we can see that the inability to guaranty the use of a same-entity name server is intentional, that it's an explicit goal of the DoH protocol. the lengths some networks or jurisdictions will go to in order to meet the guaranty anyway are not yet plumbed. but i surely do want it to be true that the definition of politeness is available and objective, so that when i find a user or an app or a device which isn't behaving politely i can remove it aggressively, without worry. -- Paul Vixie From nobody Mon Dec 7 20:46:10 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F2C3A0CD0 for ; Mon, 7 Dec 2020 20:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5lys8YQ5-iC6 for ; Mon, 7 Dec 2020 20:46:01 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05073A0E12 for ; Mon, 7 Dec 2020 20:46:01 -0800 (PST) Received: by family.redbarn.org (Postfix, from userid 716) id B25F6C3F03; Tue, 8 Dec 2020 04:46:01 +0000 (UTC) Date: Tue, 8 Dec 2020 04:46:01 +0000 From: Paul Vixie To: Ted Hardie Cc: Andrew Campling , Chris Box , Paul Hoffman , ADD Mailing list Message-ID: <20201208044601.6gzjqrfwqbsrshod@family.redbarn.org> References: <40C39C4D-68C7-4C8E-8841-0F1D5A637BE0@icann.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Add] [Ext] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 04:46:08 -0000 On Mon, Dec 07, 2020 at 03:45:50PM -0800, Ted Hardie wrote: > ... > > I don't think I care that B is operated by the same entity. ... i think that i, variously, do care. as a user, i want to know. as a network operator, i want to say. -- Paul Vixie From nobody Mon Dec 7 21:09:31 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F813A0E3C for ; Mon, 7 Dec 2020 21:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=lgS3QvLd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=T5Jr7ENS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ga15NchnkY8 for ; Mon, 7 Dec 2020 21:09:28 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F0603A0E28 for ; Mon, 7 Dec 2020 21:09:28 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A4B6AC6F; Tue, 8 Dec 2020 00:09:27 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 08 Dec 2020 00:09:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=99vBQGTze/ExaihiPaOaCgLGRyOG KWp2jbhWkGdE4Ow=; b=lgS3QvLdYbFA0+qDhcroBC5m/ksZ4Wu7ojTv0xddhFNU ZTGUVwfEL+TfgkyI375zViMaSa1ynbyPtre9kaysWUk5vb2VDQYoYSkcXEpGIofv ytnSThg7+/r7L5y7IDsSbf4+s6rIT9TrmqgURofw89KnEDwyIRKq66A8m3kCmZ8r f0aLNcYaKC5+nj4/yFTzE5yHm0SDiZXVuOr/BWLJJcImV0pV0v8B/8XN/epJsjFI s8KZb7DCLTKj1IL4LUgXiXYbJEYJj5ZkJwxoxeo1lThKbiPQI7x5TRjfmUaZsty6 GGSsLIIOpR3j3UQ9/rbQuDrlvWg1S3NrROFPa++LNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=99vBQG Tze/ExaihiPaOaCgLGRyOGKWp2jbhWkGdE4Ow=; b=T5Jr7ENSO9uh+X21Gli0oh m4TpGu4fVsCsDRO2WWVUG5GqgFVer2JVo5aSqz+Qykx3otstzNfDZnb3LqNSis2i Kw9ZyiLu+XrwrNs8QzERDtbePkekP00+QD3C8buJL2qbkB2MJu+aLtMBmf1gCQoG K7t/NbvTsGBr9Iir0xp5QUFN1mVNlcnXXMbaigHskeYsx6vFct+7vHYtXJezNpzb sa/wZcU5sQ/4itLgasOL1q2Y2ilds/Ap/s62LKIxxhCKdWDhAkeZalHNj/mKb65E Akoi4BGlW8Z+njiH5ApZrti/I4brIgIaIDMFRDuccVPxTFAXAVynVhEAAmPRyeQQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejhedgjeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepkeetueeikedtkeelfeekvefhkeffvedvvefgkefgleeugfdvjeej geffieegtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E1098201BD; Tue, 8 Dec 2020 00:09:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <5bfe6cf6-4788-4952-88ad-ce8f44f61dcb@www.fastmail.com> In-Reply-To: <20201208044326.2kzcb6fg6egl2cxz@family.redbarn.org> References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <20201208044326.2kzcb6fg6egl2cxz@family.redbarn.org> Date: Tue, 08 Dec 2020 16:09:06 +1100 From: "Martin Thomson" To: "Paul Vixie" Cc: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 05:09:30 -0000 Hi Paul, Your point about politeness is noted. On Tue, Dec 8, 2020, at 15:43, Paul Vixie wrote: > i read it as the DHCP-assigned server and the prospective-other server being > operated by the same entity, not that the client's attached network and the > prospective-other server being operated by the same entity. What value do you attribute to having any level of expectation to having the same operator for the referenced resolvers? I understand that an entity that provides such a reference might wish to limit to whom they point, and they might value things other than the criteria the IETF lists as important. That's something they can decide on their own here in deciding what resolver to reference. What value does a client gain from being able to assume that the operations are the same? Given that you can't provide any sort of surety for the client - the reason I mentioned guarantees - it seems that any utility the client gains would have to be esoteric. Thanks, Martin From nobody Mon Dec 7 23:32:59 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43DD3A0A3E for ; Mon, 7 Dec 2020 23:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbZI52SFTCDd for ; Mon, 7 Dec 2020 23:32:55 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB5003A090D for ; Mon, 7 Dec 2020 23:32:53 -0800 (PST) Received: from [IPv6:2001:559:8000:c9:81fa:5df:f39a:7a2c] (unknown [IPv6:2001:559:8000:c9:81fa:5df:f39a:7a2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id E3D7AC3F02; Tue, 8 Dec 2020 07:32:51 +0000 (UTC) To: Martin Thomson Cc: add@ietf.org References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <20201208044326.2kzcb6fg6egl2cxz@family.redbarn.org> <5bfe6cf6-4788-4952-88ad-ce8f44f61dcb@www.fastmail.com> From: Paul Vixie Message-ID: <1ad5bc89-0ffe-6ccb-00d6-22b4d6b106bd@redbarn.org> Date: Mon, 7 Dec 2020 23:32:50 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.40 MIME-Version: 1.0 In-Reply-To: <5bfe6cf6-4788-4952-88ad-ce8f44f61dcb@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 07:32:58 -0000 Martin Thomson wrote on 2020-12-07 21:09: > Hi Paul, > > Your point about politeness is noted. > > On Tue, Dec 8, 2020, at 15:43, Paul Vixie wrote: >> i read it as the DHCP-assigned server and the prospective-other server being >> operated by the same entity, not that the client's attached network and the >> prospective-other server being operated by the same entity. > > What value do you attribute to having any level of expectation to having the same operator for the referenced resolvers? ... the two pictures now in my head may not be exhaustive, but i'll describe them. first, if the specification of the "pointer" code point now being discussed here is "same entity" then clients i develop or operate might be more open to following that pointer. whereas if the recursion function is about to be delegated to another entity i may prefer to fail and suggest that a VPN be used, or some similar local-policy. second, this discussion point puts some stress on the concept of equivalence as a constant, which may with further illumination be released by making equivalence into a variable. if the "pointer" code point was accompanied by a TLV string in which same-entity was a boolean or in which entity was the DNS owner name of an RP, that could also inform my own, or my implementation's, local-policy. > What value does a client gain from being able to assume that the operations are the same? Given that you can't provide any sort of surety for the client - the reason I mentioned guarantees - it seems that any utility the client gains would have to be esoteric. the trust was already assumed, because the pointer was coming from the local network operator in some way. if we're willing to follow that pointer, then we're willing to trust what's a specified constant about it, or we're willing to trust a specified variable that describes it. the security philosophy this fits into is al capone and his taxes. my first hint as a network operator that i have a bad actor among my users, apps, or devices could well be that netflow shows noncompliance with a specified norm of DNS behaviour. so it's valuable, not as a guaranty, but as a warning. vixie -- Sent from Postbox From nobody Tue Dec 8 06:20:00 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D50E3A0EC6 for ; Tue, 8 Dec 2020 06:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EZsmHwcRajf for ; Tue, 8 Dec 2020 06:19:57 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110075.outbound.protection.outlook.com [40.107.11.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C3F3A0EC3 for ; Tue, 8 Dec 2020 06:19:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j/g62UWRiG4f5yVfdkGlhQ+vl8U1plwx/bfFmzkyWmsKmIso2gspR1hdM74WX7LIOVZu0c5+nhppJADJt/QyHmwJiXLdHp0bB/XM6qoalfL9tR5hJ7Ts7GcO3ukvicD63XbfWpkGz2SDGXPwoal10kmHPPGxWPkB67d7uKVgwrl2NOCjmdF1TPJozgcTAYtONX31iR2fElBe2SLURs2mNXLsn5eumxoOr02yKV9XcZB3+s3HawrrjAYq6kTljd5fjZFpg5jm8Zx5yFo8+ErmbqAVyeg6B1PxUO2ug2vPDjfiKaIf9wTFxmu+9H22QejZE79rxFqPoGACu6yVnCV1ug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v0c9mYsuBzfSAH0OY9DtFWSqdTuDNZDySyS9CTdGwuc=; b=aWGcOSF6OmjcjWNNUVhgLNhtnpK6a4lwGMDLdqvZ1tAIXgj/3XcFqGPbd0DNCZXJGnzmXGULW/e5IrQ9ImsDCmdsyKe8HBRGz9wVv1eEGgCEADBN4A7oX43VuglZvY/LR4t4tJD3X8zAcK/sPZpZgRUtKoddZyzHzYEAmHambQORx2KBMUc1oOLBfed4B94vliXIqJE7rCTOaHz0nThX97gipngi1hwCf7ZYH6+a0ZZuds8cTNMhHclQkdrXzKgqEVQzwPSxVNbknr6LbUF8TJWQWgcyT0WeLoU/NMdUvGQjLGRBnHNbV9+XvQ0yIRZr5Nici+2iueRI3hNuZfxOBA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v0c9mYsuBzfSAH0OY9DtFWSqdTuDNZDySyS9CTdGwuc=; b=YkHoq+uYOND1IOWV/ZcOqdTQ2YXPBO5kK3gh4eNjJvgVV1qiCrDjtbnAFTUSmnQsSRoeouA6SfIPaOI4BhFG2TWMJAtFyFPmWXIXlIiEd215Av9VGE6dOuKOdt0qwB47M12/Zae/gJ86ysMgVTe1PExjDne9i37iyoFUXpoJABM= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) by LO2P265MB3279.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:177::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21; Tue, 8 Dec 2020 14:19:54 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::4074:aae:262:a640]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::4074:aae:262:a640%7]) with mapi id 15.20.3632.021; Tue, 8 Dec 2020 14:19:54 +0000 From: Andrew Campling To: Martin Thomson , "add@ietf.org" Thread-Topic: [Add] Definition of equivalence Thread-Index: AQHWzSBbRFga19yem06bKyWyBOMxxantPLfw Date: Tue, 8 Dec 2020 14:19:54 +0000 Message-ID: References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> In-Reply-To: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: lowentropy.net; dkim=none (message not signed) header.d=none;lowentropy.net; dmarc=none action=none header.from=419.consulting; x-originating-ip: [81.141.78.193] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d9df24c1-a7c5-4243-13a7-08d89b8455b4 x-ms-traffictypediagnostic: LO2P265MB3279: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eF9/2vz3tDQJzFUOAJWTsyURVOa2VnNmZhzrMXYQ9t5MZ0toX1zXT0cdyL078SdNyGsZtp6TMfMZfzN43nFqeF2McsIuJXIQigjoiX/RfHnJgMyY9mKKKc/GMLMWsAFtJSWvPeA692kXGKpTiJ96nUHPfhSKbfeB/neLMt3eWlxJ28nf3fhzaWS6q8kMuGCYvkE76UP6E3zwjCIIk3f4UwHp3BUKGsykDjZ0ORuX3fCB5WMYmbYnax76E5J7q0BMthDpfD7RVemMIHcbBLh99fLtUBeKrLizLBZUYcmm+vNJDFXGodDWaNtNWkDaq9laLvkc6pdv1FrCNlXtLcq/iKJgJbuz7gt0fSLnn5eJDGExS3LQYPTYPJ2e8GKRdTV3 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(366004)(136003)(376002)(55016002)(52536014)(186003)(66446008)(6506007)(66946007)(33656002)(66556008)(83380400001)(5660300002)(44832011)(71200400001)(110136005)(66476007)(64756008)(76116006)(508600001)(8676002)(2906002)(86362001)(26005)(9686003)(8936002)(7696005)(46492008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?hKMFSkn1qjH3kCYdQd+mxSRsz/XFj/VmbRYUvGqdLhqlVtoJU41IjLVg1Ikn?= =?us-ascii?Q?v6jjk0/i1VDMtNJJ5Acp58xi7fPtoytI2pkTfAy27wBqI9BDbxPYfuwKfFiZ?= =?us-ascii?Q?xDaQUmIOZh0jJ5fqSIK1ezKL0oOYHuWxuFMRwxBt/OBxraGuvcK5oc8vOnlx?= =?us-ascii?Q?mtydzEFt+A9dL5VtNuOate2v/2KwntBkpgcZMXPMNXvCLynXebRA8Fe1tMEd?= =?us-ascii?Q?eCSqTIwq7BLl3cAB13CaX0JiAacFPidua8yclzLgHbwpUE/Ac0LkM77tXmlx?= =?us-ascii?Q?PhSEd2zWknY2pYXB1sRoswAjgPpZVgg6AvD78ewjc6rY42bN3RcPYrguI6TN?= =?us-ascii?Q?4JNYLDGF4TOETPO2Vn3Goi+sALJOZ+T521njB6XTbObFZGZ5QqrjpLCYl4oy?= =?us-ascii?Q?5GkTVUSGETdjwhdX9F5gKEmcLwPe+RNrxZ1FGSVIO4ckmSb07EjaHnF9raLB?= =?us-ascii?Q?Y+N44VJLZVlvOgLed9id/lNIxdbypo/xbEAL3lO+5OCRKvZHVdI8P7nGrGxz?= =?us-ascii?Q?Jl0GCdSrFW9WONawFO+32T0eXYQ1fnFnxBxkbbpYqNTP9Yl5Pnd1VWFraD7j?= =?us-ascii?Q?mYRUkbkZ+oIisczJutkZIBZs05ny/7YmCAUM3YvqhNvAzNJp6Wl8BviGBqpB?= =?us-ascii?Q?tVVlRzvrgajh6xF6Dhm1FKB6WwSajLyq824Oy+cJStWbHETdlH9C9pNCTuYh?= =?us-ascii?Q?J7MNmWhSf/TsB6D15BkKmwpEHP9SSmSuvSvvdngSX3qWjZQtPt/EnrWLr9+O?= =?us-ascii?Q?oAIrx4eRzMq+jY6+eDi53isd0KoMmGsb2eI/YjnvvgF67Ce/JfvYlnUDUg+a?= =?us-ascii?Q?0cAn+8GHx44/3kJ3FZIsdoFtfmE+7i6/+QkGEcJ2uTPRuLWP5z4d26P5BHCC?= =?us-ascii?Q?MYLvtUG4jd6lGF/XTP4ceRqAyIZFc84jxnVH7yig6kUIZJ5K3MmQiHGoNVbH?= =?us-ascii?Q?7BVYdVHE2P6d5SztP/yU6nxMzd/cYrYZDZXibb1EJXQ=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d9df24c1-a7c5-4243-13a7-08d89b8455b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2020 14:19:54.8128 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DwYySOhfpjOEa3HvdppYtJ/5VW+1RzmgyIAV83Auq05KMEAvq2T1vT+0fNAcpnwbJnrDiUJXPvj0DvB0vhTzklq60dqTbYb74XWFjB8Cnuo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB3279 Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 14:19:59 -0000 On Tue, Dec 8, 2020, at 23:12, Martin Thomson wrote: > The message I got from the discussion was that equivalence was not what w= e were looking for. Why is it not enough to say that an pointer is enough?= The entity providing the pointer can apply its own policies in determinin= g what to point to (which might include the below), the entity following th= e pointer can do the same (again, including the below), and we might strong= ly recommend certain properties so as to create an expectation that the pro= perties hold, but that's not equivalence. > >From my perspective, I would like to see a recommendation that the point= er only be given if the alternative resolver provides cryptographic protect= ion for queries and responses (equivalent to DoT/DoH), has access to the sa= me set of names, and has equivalent or better privacy treatment for queries= . That's 2-4 from your list, not 1. > The same entity thing is not a good idea. I understand that people might= want to enact that policy, but there are enough networks pointing to exter= nal providers that removing the option would be unwise. I also understand = that some networks or jurisdictions or clients might insist on this rule, b= ut I don't quite understand how they guarantee that if it was important. I think that there are two similar but separate categories here, one for "e= quivalent" resolvers with a definition based on that provided in the earlie= r post from Chris Box, and potentially a second one for "designated" resolv= ers. The main distinction of the second category is that it drops the requ= irement for it being from the same entity, could instead detail to a range = of resolvers operated by multiple entities. Whether there is a need for bo= th categories in a user requirements document needs further thought. =20 Note though that the inclusion of different entities could, in my view, be = significant from the perspective of GDPR etc as a client could be directing= personal data to a new data processor. Those in countries or states witho= ut meaningful data privacy legislation may, of course, choose not to worry = about such considerations.=20 Andrew From nobody Tue Dec 8 09:34:15 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9783A1065 for ; Tue, 8 Dec 2020 09:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaetOiyLrXfg for ; Tue, 8 Dec 2020 09:34:11 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378353A105A for ; Tue, 8 Dec 2020 09:34:11 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id f11so8921507ljn.2 for ; Tue, 08 Dec 2020 09:34:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=P0dRvsjdVrHtVN374FgiqJgL70GL2x20I2VQzqiwZAo=; b=RHAOa/5g/vjzKbpjPBRLHRV724GX+DhgRGniXci7KJFhcCF7rk5ZYZwZgQSHwfQusN id6nmxO/PTLd8bXEa+hvY4+Lp6TEo52B/FbfCvW7xpkTxS4KH6B13uPjOeAGlNn+JDKS s7O2UYyNFYKh5zWm5NIqcpKf39CgT8YXxGhNJBOyMzIz0d5GxUJvpCIvpz/EZCODJ5sn UVtgcokpGHyNEOHXLuJxH4AOe3kXKheR2sjYxJUI2RkSDJz2w2wcEv45fA11NpdZVnfL 1M7fDphvxR5xA9AdCqFRvr9I3whqzC9yyP6oglc7DsNMZhtRHydP5nEZdX8QeZkhD63j du8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=P0dRvsjdVrHtVN374FgiqJgL70GL2x20I2VQzqiwZAo=; b=jUKU4898pnfeeDEaITfRE22KmIIk4sEBqeN8O1a52277DDyWhr9KW4hyGYtOd7R6CQ Ak4QQkEUtE1DQlzaVMstzhQAbvjdQcKBR5OAmXYbOrTfjztwg8KZPsjxnjmTqtuguVMp IrNdh883EUFMNbAGFymEXtMDmyqNTJ0AHmSGj7OPU4XPmrvgnYMM+a+7q+OFVbF1zhHq WYJj1KChBqNNxA01qDNd5dkxh/YDqMQxtYvtZ09ASb697gAhaiNx5TBd63Fjf664k3by BiWQg6HxXeVl5a8JofdHmXAyOcaVQGs1lb0jVXBADIKXcbBR3S2ACIsUhOwLYYx10Cwl tv7Q== X-Gm-Message-State: AOAM530EIPrVYh3VNrImsrs+hAt2M0citFy2FvkJfHywas4b3LKoy88B o8tzi+HzkAzOGf/izO/iFeTdeoGmrMSeBlJdxJzNIwtF/SM= X-Google-Smtp-Source: ABdhPJwiaPd2StYqYh38WqOQ/29ZoiqRr5+CskQt3WOev3oqdxcm4J/AhCEuxp5LN9zehMNN/NXFMKh9J53LrS63NEQ= X-Received: by 2002:a05:651c:1a4:: with SMTP id c4mr12115995ljn.243.1607448847164; Tue, 08 Dec 2020 09:34:07 -0800 (PST) MIME-Version: 1.0 References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> In-Reply-To: From: Eric Orth Date: Tue, 8 Dec 2020 12:33:55 -0500 Message-ID: To: Andrew Campling , "add@ietf.org" Content-Type: multipart/alternative; boundary="00000000000088033d05b5f7596c" Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 17:34:13 -0000 --00000000000088033d05b5f7596c Content-Type: text/plain; charset="UTF-8" I would be supportive of splitting off the same-entity part as a separately defined (but still important) concept. So essentially requirement (1) from above becomes one concept (call it "same-party") and (2,3,4) alone becomes another (call it "similar-behavior"). I think making it two defined concepts works well because it would be reasonable for some parties to have policies regarding one but not the other. And, as was discussed a couple times at 109, some parties that care about both concepts might still have separate enforcement/validation concerns for the two concepts. E.g., many clients want some sort of verifiable evidence of the "same-party" concept but once that has been proven are more generally willing to trust the provider to maintain the "similar-behavior" concept as long as it's defined and specified as the intended behavior. On Tue, Dec 8, 2020 at 9:20 AM Andrew Campling wrote: > On Tue, Dec 8, 2020, at 23:12, Martin Thomson wrote: > > > The message I got from the discussion was that equivalence was not what > we were looking for. Why is it not enough to say that an pointer is > enough? The entity providing the pointer can apply its own policies in > determining what to point to (which might include the below), the entity > following the pointer can do the same (again, including the below), and we > might strongly recommend certain properties so as to create an expectation > that the properties hold, but that's not equivalence. > > > >From my perspective, I would like to see a recommendation that the > pointer only be given if the alternative resolver provides cryptographic > protection for queries and responses (equivalent to DoT/DoH), has access to > the same set of names, and has equivalent or better privacy treatment for > queries. That's 2-4 from your list, not 1. > > > The same entity thing is not a good idea. I understand that people > might want to enact that policy, but there are enough networks pointing to > external providers that removing the option would be unwise. I also > understand that some networks or jurisdictions or clients might insist on > this rule, but I don't quite understand how they guarantee that if it was > important. > > I think that there are two similar but separate categories here, one for > "equivalent" resolvers with a definition based on that provided in the > earlier post from Chris Box, and potentially a second one for "designated" > resolvers. The main distinction of the second category is that it drops > the requirement for it being from the same entity, could instead detail to > a range of resolvers operated by multiple entities. Whether there is a > need for both categories in a user requirements document needs further > thought. > > Note though that the inclusion of different entities could, in my view, be > significant from the perspective of GDPR etc as a client could be directing > personal data to a new data processor. Those in countries or states > without meaningful data privacy legislation may, of course, choose not to > worry about such considerations. > > Andrew > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000088033d05b5f7596c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would be supportive of splitting off the same-entity par= t as a separately defined (but still important) concept.=C2=A0 So essential= ly requirement (1) from above becomes one concept (call it "same-party= ") and (2,3,4) alone becomes another (call it "similar-behavior&q= uot;).

I think making it two defined concepts works well= because it would be reasonable for some parties to have policies regarding= one but not the other.

And, as was discussed a co= uple times at 109, some parties that care about both concepts might still h= ave separate enforcement/validation concerns for the two concepts.=C2=A0 E.= g., many clients want some sort of verifiable evidence of the "same-pa= rty" concept but once that has been proven are more generally willing = to trust the provider to maintain the "similar-behavior" concept = as long as it's defined and specified as the intended behavior.

On= Tue, Dec 8, 2020 at 9:20 AM Andrew Campling <andrew.campling@419.consul= ting> wrote:
= On Tue, Dec 8, 2020, at 23:12, Martin Thomson <mt@lowentropy.net> wrote:

> The message I got from the discussion was that equivalence was not wha= t we were looking for.=C2=A0 Why is it not enough to say that an pointer is= enough?=C2=A0 The entity providing the pointer can apply its own policies = in determining what to point to (which might include the below), the entity= following the pointer can do the same (again, including the below), and we= might strongly recommend certain properties so as to create an expectation= that the properties hold, but that's not equivalence.

> >From my perspective, I would like to see a recommendation that the= pointer only be given if the alternative resolver provides cryptographic p= rotection for queries and responses (equivalent to DoT/DoH), has access to = the same set of names, and has equivalent or better privacy treatment for q= ueries.=C2=A0 That's 2-4 from your list, not 1.

> The same entity thing is not a good idea.=C2=A0 I understand that peop= le might want to enact that policy, but there are enough networks pointing = to external providers that removing the option would be unwise.=C2=A0 I als= o understand that some networks or jurisdictions or clients might insist on= this rule, but I don't quite understand how they guarantee that if it = was important.

I think that there are two similar but separate categories here, one for &q= uot;equivalent" resolvers with a definition based on that provided in = the earlier post from Chris Box, and potentially a second one for "des= ignated" resolvers.=C2=A0 The main distinction of the second category = is that it drops the requirement for it being from the same entity, could i= nstead detail to a range of resolvers operated by multiple entities.=C2=A0 = Whether there is a need for both categories in a user requirements document= needs further thought.=C2=A0 =C2=A0

Note though that the inclusion of different entities could, in my view, be = significant from the perspective of GDPR etc as a client could be directing= personal data to a new data processor.=C2=A0 Those in countries or states = without meaningful data privacy legislation may, of course, choose not to w= orry about such considerations.

Andrew

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000088033d05b5f7596c-- From nobody Tue Dec 8 09:51:53 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7D73A106E for ; Tue, 8 Dec 2020 09:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmkilpS_fMBy for ; Tue, 8 Dec 2020 09:51:49 -0800 (PST) Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FD53A1015 for ; Tue, 8 Dec 2020 09:51:48 -0800 (PST) Received: by mail-oo1-xc2b.google.com with SMTP id s1so970973oon.2 for ; Tue, 08 Dec 2020 09:51:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QekJm49L3TiD43H9NT4qC3g0hTuxYi//1mylC02w/U0=; b=pxJ+sTbizgMcsV/QX4xfQwk4Th36gA8e9P16Jz3Jx/QJ0bkTOeIm8RGbrLzmYOpiuc dzP5+zZloes+IO90EaE6FZYe6dY3SM7vpS27IUhB2WDeNgaON6UUU/CwLbcQHgFdZZy2 HJrXAV4BpEoguqkcdJ9YLBNsoWi71eriLuIaCXlKefJPJoAbWQm7Z9xa0f90WdvzmEpQ jrfRactbyDp/5Zd2/I5dw1u8k4Z9P5pTq2KJjx729GW9CuE9Y6QsZhGseC3cgH6e5Qo6 Vx0We2pIIoQqI6Kf74TkS1oSNk8eN43pQ1k96Oimn1CJFDputYHbZYwKZeBeyG/oPwE4 9kSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QekJm49L3TiD43H9NT4qC3g0hTuxYi//1mylC02w/U0=; b=DwqAwd+RufAt9jGRmRRQsEfEgsfD90Um6SIdKTJZAhuOESDUg0uza2eVDl1PHBdRFC Yznhve6h/RmqNEPT3JABrGpSi5nZN0mAFROE00VygFnooY80PTM465Yx5PoEoIUklni2 K/8XXcmKNEUeYxnu/NLmK+ZUv+MJATvuzVPaFljn5pKQLIJP++E5iz48A1USTyHYC+oC ErnW2d9yL/2jffJA9MX+LhjNLUhqeIgtTVS7nIfBzfaUUhoy9S+l05JMqPi4E7sWTprn Eq2zvaM+LZSdxev12eJzf6wsZ6DAzNnkNcENjoErMgt2g9Khx74cBSYwcH5KZNwAT3Lb Ix+Q== X-Gm-Message-State: AOAM532ekyhazMbuwPq4jiBF7vCDXuKHHj+VXD7fPbGGi/9Da+zPi8aV sJ+LjD1tRFC4gXpLISYMz0Qz9HkXvTxfeJEHZ0o/eOcC X-Google-Smtp-Source: ABdhPJxYA+kXtJMT6Hjq/FowNToQHMN2bN8T4meFw70zNW/TSVY/3bZkT2BxxY3zKF1fZPfmVapsuE9YrO0xt14dZlA= X-Received: by 2002:a4a:6b4d:: with SMTP id h13mr17351343oof.67.1607449908227; Tue, 08 Dec 2020 09:51:48 -0800 (PST) MIME-Version: 1.0 References: <40C39C4D-68C7-4C8E-8841-0F1D5A637BE0@icann.org> <20201208044601.6gzjqrfwqbsrshod@family.redbarn.org> In-Reply-To: <20201208044601.6gzjqrfwqbsrshod@family.redbarn.org> From: Ted Hardie Date: Tue, 8 Dec 2020 09:51:22 -0800 Message-ID: To: Paul Vixie Cc: Andrew Campling , Chris Box , Paul Hoffman , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000c634bd05b5f79856" Archived-At: Subject: Re: [Add] [Ext] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 17:51:52 -0000 --000000000000c634bd05b5f79856 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 7, 2020 at 8:46 PM Paul Vixie wrote: > On Mon, Dec 07, 2020 at 03:45:50PM -0800, Ted Hardie wrote: > > ... > > > > I don't think I care that B is operated by the same entity. ... > > i think that i, variously, do care. > > as a user, i want to know. > > as a network operator, i want to say. > > There clearly are also networking operators who want to point away to different entities. So if the pointer has to be able to distinguish between those two claims, I'm fine. But I will reiterate that this is not possible for the end system to confirm at query time. Org X can say "those people are me" when they have outsourced to Provider Y, and the arguments about whether that was a reasonable claim will not be bits on the wire. regards, Ted > -- > Paul Vixie > --000000000000c634bd05b5f79856 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 7, 2020 at 8:46 PM Paul Vixie= <paul@redbarn.org> wrote:
On Mon, Dec 07, 2020 at 03:45:50PM -0800, Ted Hardie wrote:
> ...
>
> I don't think I care that B is operated by the same entity.=C2=A0 = ...

i think that i, variously, do care.

as a user, i want to know.

as a network operator, i want to say.


There clearly are also networking oper= ators who want to point away to different entities.=C2=A0 So if the pointer= has to be able to distinguish between those two claims, I'm fine.=C2= =A0 But I will reiterate that this is not possible for the end system to co= nfirm at query time.=C2=A0 Org X can say "those people are me" wh= en they have outsourced to Provider Y, and the arguments about whether that= was a reasonable claim will not be bits on the wire.

<= div>regards,

Ted


=
=C2=A0
--
Paul Vixie
--000000000000c634bd05b5f79856-- From nobody Tue Dec 8 17:13:39 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC423A08BD for ; Tue, 8 Dec 2020 17:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=HSiQeA2O; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aa/v+rgF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMBb0VSn5pFA for ; Tue, 8 Dec 2020 17:13:36 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A9B3A08B1 for ; Tue, 8 Dec 2020 17:13:36 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 94BCE5C0132 for ; Tue, 8 Dec 2020 20:13:34 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 08 Dec 2020 20:13:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=qbTlzI6eoU538Zk2dSs5Bpp45V/A0JK ogzmrh/OI3hU=; b=HSiQeA2Oz0D7NVsnqrtg61Niirt7EeEUOzfxFjfA0krf03S 3yg7jSDj3BD4W0dJ/aO95Qxx7v3q726WJ6gJ0UUjGgrtgBP/8k+H8AZeLQdB0quY bS8lZoI5WhRJvRnfzkfXduMz9dmGYWTlmFiH5mg9/qDHpgoqsGbl+fzfs/lgNZvZ 2zhvmC3fHT4UkT89EF488+TY5HWi9lePGpTBAMSmZ6s8P++9cqhgbZ8vjjlotqd+ ejZm1kCbiGpYbyV9VZXI2vh8a9Cne/aR1/gc9KVf2NYGi4gvYBY7uV2pZm1TqZl8 d2prSoFmXpGS7MJ0O0yEpCDzjetRjyGqbG8es7w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=qbTlzI 6eoU538Zk2dSs5Bpp45V/A0JKogzmrh/OI3hU=; b=aa/v+rgFaocFL8bWlGeJI5 zxiEzuLxPjhWqGTk+YvueDCea3G5mEz0MO46l/TWgHX0MoVxbCy7uDNEmFd7eHYj DkwiAENEDKx1t1QKl5k8iVWu7qHPb25MG0RNGW7Bz4FN0NhVwaFCMwl2r228aXZl JzNzofXNRQv1nPqCBIizuFgvBQpKs4zqbBJxQbOOqAguPkxG/w7Tau9O26kfULIi 6earaSbUt4iDxOXWQij/W4ibtlsO2TZqoakbv35AL3a4jEJ2CjkRdjH2iMmdM4eR UBvcjhX8Xd5RIo/FJ5jtykv78K5PgU4QV0xHgDiuPP1xH8w9b9FjBvc0gMFaWqQA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejjedgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C391D20063; Tue, 8 Dec 2020 20:13:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> In-Reply-To: References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> Date: Wed, 09 Dec 2020 12:13:15 +1100 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 01:13:38 -0000 On Wed, Dec 9, 2020, at 04:33, Eric Orth wrote: > E.g., many clients want some sort of > verifiable evidence of the "same-party" concept but once that has been > proven are more generally willing to trust the provider to maintain the > "similar-behavior" concept as long as it's defined and specified as the > intended behavior. Requirements-in-a-vacuum problem: This is a fine statement in the abstract, but if you look at how this might be implemented, I claim that you will find that you have an opportunity to solve the overarching problem. That is, the information the client needs to validate any same-party claim would also allow it to authenticate the network provider identity or choose a trustworthy, secured resolver. Why would devote resources to solving the same-provider problem when that might solve the real problem the group has? Ted made a similar point, namely that any same-provider claim is unverifiable. If it was important and verifiable, then it might be worth pursuing, but while there might be some uncertainty about the former, the latter needs support for me to consider that pursuit. From nobody Wed Dec 9 04:58:07 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685113A143E; Wed, 9 Dec 2020 04:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O--AzJhUw725; Wed, 9 Dec 2020 04:58:03 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D627B3A143D; Wed, 9 Dec 2020 04:57:54 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar25.francetelecom.fr (ESMTP service) with ESMTPS id 4CrcXd39mFz8tPM; Wed, 9 Dec 2020 13:57:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607518673; bh=dm/R7RWjyXu5DlJ4OqMyLlq6bZ7zzGutT++ug+LbEFA=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=t8NIeh3bOT6LjWrQ1mesi1m5h/10kqDzt2gycNgQPdJVLYlODLe21DVEvwD5I7SbE YVpvAVRsI5Vx3+eCK8GHDVt5+TOQX6iJfdlDk9B/8HpAAe7JPwTkApOlryNsRZk1cb oP6aiZcvFei9/w+IAX6s7yhZCuoFwhQNgXMbUodtVeP+qY8ns5kZghZkZDaKYq6AwU Q0GBte5P5X+boQjzp0ajQgjbo2ECGjXj+JnV1UJryUpyWVyBMa51+sEoiC94Il5Xqw hLJskNU3NVpo1kyrvN6/MTScNVVk/COjjOAS1r1/vLT82Z8dUWA8BacWpDkwMl+004 Y7ang7U6aPbbQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4CrcXd1j3VzCqkY; Wed, 9 Dec 2020 13:57:53 +0100 (CET) From: To: Daniel Migault , ADD Mailing list CC: "draft-btw-add-home@ietf.org" Thread-Topic: [Add] discussion on draft-btw-add-home Thread-Index: AQHWw3at46XWoNjo4k6dfvaGIiwDNqnutf3Q Date: Wed, 9 Dec 2020 12:57:51 +0000 Message-ID: <3485_1607518673_5FD0C9D1_3485_172_40_787AE7BB302AE849A7480A190F8B93303159A5F6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303159A5F6OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Add] discussion on draft-btw-add-home X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 12:58:07 -0000 --_000_787AE7BB302AE849A7480A190F8B93303159A5F6OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuaWVsLA0KDQpOb3Qgc3VyZSB0byBnZXQgeW91ciBwb2ludCwgYnV0IHRoZSBvcHRpb25z IGNhbiByZXR1cm4gYW4gQUROLCBhIGxpc3Qgb2YgSVAgYWRkcmVzc2VzLCBhbiBhbHRlcm5hdGUg cG9ydCBudW1iZXIsIHR5cGUocykgb2YgdGhlIGVuY3J5cHRlZCBETlMsIGFuZCAgVVJJIFRlbXBs YXRlcyBmb3IgRG9ILiBUaGF04oCZcyBhbHJlYWR5IGEgZ29vZCBzZXQgb2YgaW5mb3JtYXRpb24g dG8gYmUgbGVhcm5lZC4NCg0KRG8geW91IGhhdmUgaW4gbWluZCBvdGhlciBpbmZvcm1hdGlvbiB0 aGF0IGlzIHdvcnRoIHRvIGJlIGRpc2NvdmVyZWQ/DQoNCkNoZWVycywNCk1lZA0KDQpEZSA6IEFk ZCBbbWFpbHRvOmFkZC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIERhbmllbCBNaWdh dWx0DQpFbnZvecOpIDogbWVyY3JlZGkgMjUgbm92ZW1icmUgMjAyMCAyMzowMg0Kw4AgOiBBREQg TWFpbGluZyBsaXN0IDxhZGRAaWV0Zi5vcmc+DQpPYmpldCA6IFtBZGRdIGRpc2N1c3Npb24gb24g ZHJhZnQtYnR3LWFkZC1ob21lDQoNCkhpLA0KDQpJIHVuZGVyc3RhbmQgdGhlIEFETiBkZXNpZ25h dGluZyB0aGUgRlFETiBvZiB0aGUgRE5TIHNlcnZlci4gSSBhbSB3b25kZXJpbmcgaWYgdGhlIEVu Y3IgRE5TIFR5cGVzIGZpZWxkIG1heSBub3QgYmUgYSBiaXQgbGltaXRlZCwgYW5kIGlmIGl0IG1p Z2h0IG5vdCBiZSBwcmVmZXJyZWQgdG8gcmVxdWVzdCBhIHJlcXVlc3Qgb2YgdHlwZSBTVkNCLg0K DQpBZGRpdGlvbmFsbHksIHRob3VnaCBpdCBtYXkgZGVwZW5kIG9uIHRoZSBzaXplIG9mIHRoZSBT VkNCIHJlc3BvbnNlLCBJIGFtIGFsc28gd29uZGVyaW5nIGlmIHNlbmRpbmcgdGhlIHJhdyBTVkNC IHJlc3BvbnNlIGNvdWxkIGJlIHBvc3NpYmxlLg0KDQpZb3VycywNCkRhbmllbA0KDQotLQ0KRGFu aWVsIE1pZ2F1bHQNCkVyaWNzc29uDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_787AE7BB302AE849A7480A190F8B93303159A5F6OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9s bG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJs YWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRl Y29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkZSIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIERhbmllbCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPk5vdCBzdXJlIHRvIGdldCB5b3VyIHBvaW50LCBidXQgdGhlIG9wdGlv bnMgY2FuIHJldHVybiBhbiBBRE4sIGEgbGlzdCBvZiBJUCBhZGRyZXNzZXMsIGFuIGFsdGVybmF0 ZSBwb3J0IG51bWJlciwgdHlwZShzKSBvZiB0aGUNCiBlbmNyeXB0ZWQgRE5TLCBhbmQgJm5ic3A7 VVJJIFRlbXBsYXRlcyBmb3IgRG9ILiBUaGF04oCZcyBhbHJlYWR5IGEgZ29vZCBzZXQgb2YgaW5m b3JtYXRpb24gdG8gYmUgbGVhcm5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+RG8geW91IGhhdmUgaW4gbWluZCBvdGhlciBpbmZvcm1hdGlvbiB0aGF0 IGlzIHdvcnRoIHRvIGJlIGRpc2NvdmVyZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gQWRkIFttYWlsdG86YWRkLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5EZSBsYSBw YXJ0IGRlPC9iPiBEYW5pZWwgTWlnYXVsdDxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJj cmVkaSAyNSBub3ZlbWJyZSAyMDIwIDIzOjAyPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBBREQgTWFp bGluZyBsaXN0ICZsdDthZGRAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBb QWRkXSBkaXNjdXNzaW9uIG9uIGRyYWZ0LWJ0dy1hZGQtaG9tZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSwmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVuZGVyc3RhbmQmbmJz cDt0aGUgQUROIGRlc2lnbmF0aW5nIHRoZSBGUUROIG9mIHRoZSBETlMgc2VydmVyLiBJIGFtIHdv bmRlcmluZyBpZiB0aGUmbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpi bGFjayI+RW5jciBETlMgVHlwZXMgZmllbGQgbWF5IG5vdCBiZSBhIGJpdCBsaW1pdGVkLCZuYnNw O2FuZCBpZiBpdCBtaWdodCBub3QgYmUgcHJlZmVycmVkIHRvIHJlcXVlc3QgYSByZXF1ZXN0IG9m IHR5cGUgU1ZDQi4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9y OmJsYWNrIj5BZGRpdGlvbmFsbHksIHRob3VnaCBpdCBtYXkgZGVwZW5kIG9uIHRoZSBzaXplIG9m IHRoZSBTVkNCIHJlc3BvbnNlLCBJIGFtIGFsc28gd29uZGVyaW5nIGlmIHNlbmRpbmcgdGhlIHJh dyBTVkNCIHJlc3BvbnNlIGNvdWxkIGJlIHBvc3NpYmxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPllvdXJzLCZuYnNwOzxicj4NCkRhbmllbCZuYnNwOyZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkRhbmllbCBNaWdhdWx0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Fcmljc3NvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv bi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz aWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNo b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1l c3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhh bmsgeW91Lgo8L1BSRT48L2JvZHk+DQo8L2h0bWw+DQo= --_000_787AE7BB302AE849A7480A190F8B93303159A5F6OPEXCAUBMA2corp_-- From nobody Wed Dec 9 05:46:40 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BC83A167B; Wed, 9 Dec 2020 05:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdYjzknRWeif; Wed, 9 Dec 2020 05:46:37 -0800 (PST) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004D53A16B4; Wed, 9 Dec 2020 05:46:36 -0800 (PST) Received: by mail-vs1-xe2d.google.com with SMTP id x4so892956vsp.7; Wed, 09 Dec 2020 05:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SXXPXcGZ9ZTg4aWiQD51dFk78hue4Wa+z5wZPzeCRWM=; b=TepuWJv7hxwH+xbwAJBqYdwIPFHRP2VXwGb0k6qapec+IsYyUrYFNmwZtsfr3w+/+5 fTwigSXa+5Y3poAH9+rA0+TlzrAYCwmJ/Uy3vy0TL+otGZtmc8a51VE1tTIPwAkBUpVj x4rdGsInPLIFNdm8q3qdQHciqYpv3K91Qd5IMvaJAWjexDH4gtC1AOyOZUapzO7NeU9z GchahQoEEouWKcE8jR7JK9QJFqRHtfzLAuunvTR6SLm2MMtiA5aYvDP0+5xQf91MSLi8 hCuPN+U/eMhHj6jEdElYN5+KKTSDk4K1/7cAYTNLKHeGX0jPysInPuwAQaDZ+n7rjgXv XolA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SXXPXcGZ9ZTg4aWiQD51dFk78hue4Wa+z5wZPzeCRWM=; b=QjPPj/WvBICJJ9Vn5uhKSEwnEDcdF+kA6kLjS6GQHyvGMsNuHsGuuynWaibCelciEn Db6scFK6Uaofvd9NNPqHLcFfAFbwzn3LV/Uq54I+sjIZLCUj08fb6rgUDx+zASoq3Kja kG6CX+tMR7ez/gxAiXsnwkgpD5E9fNWNHBXeYQ5Ap6JCskfZH5pfAYpX6ycvLPPRYvNE mPY7df3HJ8XKFiaM/l3N6csXM9finiw2tKgorx/WyHD4DlmSgKAtjcx7gtcm3VyIx1xG Kj3MsaALGIiKSDa4wSKMCEc31spqSdTol1y/HjsNQ9m3ljvDJ8gDknvEtYR0RYgobzKF uV+w== X-Gm-Message-State: AOAM531XLomxHV5HXUW+Wtmh6VczgwWXw//+1ethKKzcKw8fUjiEJFzg 4TAVcnWbq6qolXpH0/0s7vnR+X8sK1owAM86ztg= X-Google-Smtp-Source: ABdhPJwfJM6b1JkwOCj6bPrAB6e8pW92MBf37IptoNgeRBNY5Ql6mMck/cwK+TsAXA8igkg31DDH5NNj0PfV497oQmo= X-Received: by 2002:a67:32d4:: with SMTP id y203mr1703197vsy.30.1607521595919; Wed, 09 Dec 2020 05:46:35 -0800 (PST) MIME-Version: 1.0 References: <3485_1607518673_5FD0C9D1_3485_172_40_787AE7BB302AE849A7480A190F8B93303159A5F6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <3485_1607518673_5FD0C9D1_3485_172_40_787AE7BB302AE849A7480A190F8B93303159A5F6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Daniel Migault Date: Wed, 9 Dec 2020 08:46:24 -0500 Message-ID: To: Mohamed Boucadair Cc: ADD Mailing list , "draft-btw-add-home@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b19d4105b608492f" Archived-At: Subject: Re: [Add] discussion on draft-btw-add-home X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 13:46:39 -0000 --000000000000b19d4105b608492f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, It seems sufficient to upgrade a designated resolver from Do53 interface to DoT or DoH. However, when a DNS client needs to select among different resolvers the selection may be based on other parameters. Exemples I can think of [1] are, the ability to filter, to perform DNSSEC validation, the name that the resolver claims being authoritative for, acceptable IP addresses.... Yours, Daniel [1] https://tools.ietf.org/html/draft-mglt-add-rdp-03#section-8 On Wed, Dec 9, 2020 at 7:57 AM wrote: > Hi Daniel, > > > > Not sure to get your point, but the options can return an ADN, a list of > IP addresses, an alternate port number, type(s) of the encrypted DNS, and > URI Templates for DoH. That=E2=80=99s already a good set of information = to be > learned. > > > > Do you have in mind other information that is worth to be discovered? > > > > Cheers, > > Med > > > > *De :* Add [mailto:add-bounces@ietf.org] *De la part de* Daniel Migault > *Envoy=C3=A9 :* mercredi 25 novembre 2020 23:02 > *=C3=80 :* ADD Mailing list > *Objet :* [Add] discussion on draft-btw-add-home > > > > Hi, > > > > I understand the ADN designating the FQDN of the DNS server. I am > wondering if the Encr DNS Types field may not be a bit limited, and if it > might not be preferred to request a request of type SVCB. > > > > Additionally, though it may depend on the size of the SVCB response, I am > also wondering if sending the raw SVCB response could be possible. > > > > Yours, > Daniel > > > > -- > > Daniel Migault > > Ericsson > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --=20 Daniel Migault Ericsson --000000000000b19d4105b608492f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

It seems sufficient to upgrad= e a designated resolver from Do53 interface to DoT or DoH. However, when a = DNS client needs to select among different resolvers the selection=C2=A0may= be based on other parameters. Exemples I can think of [1] are, the ability= to filter, to perform DNSSEC validation, the name that the resolver claims= being authoritative for, acceptable IP addresses....

<= div>Yours,=C2=A0
Daniel


On Wed, Dec 9, 2= 020 at 7:57 AM <mohamed.= boucadair@orange.com> wrote:

Hi Daniel,

=C2=A0

Not sure to get your point, but t= he options can return an ADN, a list of IP addresses, an alternate port num= ber, type(s) of the encrypted DNS, and =C2=A0URI Templates for DoH. That=E2=80=99s already a g= ood set of information to be learned.

=C2=A0

Do you have in mind other informa= tion that is worth to be discovered?

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Add [mailto:add-bounces@ietf.org] De la part de Daniel Migault
Envoy=C3=A9=C2=A0: mercredi 25 novembre 2020 23:02
=C3=80=C2=A0: ADD Mailing list <add@ietf.org>
Objet=C2=A0: [Add] discussion on draft-btw-add-home

=C2=A0

Hi,=C2=A0

=C2=A0

I understand=C2=A0the ADN designating the FQDN of th= e DNS server. I am wondering if the=C2=A0Encr DNS Types field may not be a bit limited,=C2=A0and if it migh= t not be preferred to request a request of type SVCB.=C2=A0

=C2=A0

Additiona= lly, though it may depend on the size of the SVCB response, I am also wonde= ring if sending the raw SVCB response could be possible.

=C2=A0

Yours,=C2= =A0
Daniel=C2=A0=C2=A0

=C2=A0

--

Daniel Migault

Ericsson

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


--
Daniel Migault
Ericsson
--000000000000b19d4105b608492f-- From nobody Wed Dec 9 06:54:32 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBED3A0DC1; Wed, 9 Dec 2020 06:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SByOHAaqxFz6; Wed, 9 Dec 2020 06:54:29 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129DE3A0DA1; Wed, 9 Dec 2020 06:54:29 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by opfedar26.francetelecom.fr (ESMTP service) with ESMTPS id 4Crg774114zFqFn; Wed, 9 Dec 2020 15:54:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1607525667; bh=MaghCtPy2u0fHasf69a/i4v+RvZvhFtS1d7/2MvKHl8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=LKibFKvO6sYmd55fmzQ/YhP+rOb+0u/wT0g5llsb+c7H6zL50eccuC6BVbJA/9zBU eNeW8S7HTroNvWAoQhrATBkNmjCqD/b+DMie7+5hkmTA8bca7VjdXjSBRUoevHaWHS u2AuCjvkdq3IYMYdH0kuexmOl8f6gNMzVYSoukWK7CV/o38aoTlr5gnghAoOxt4mmJ EluAy+MB4Ex6GzQq2GdgCN0aDYK2faBXlQjSKQ16yPQSTTIQCZIU1QVxfoY5MAUc1d MYuuDLWyeCdWYFiN8PMX5bTSozmRCrpHEdGHH/8hoHntyjW6Xw2vG5qa/bS8f72vXV /bhEtze08O95Q== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by opfedar00.francetelecom.fr (ESMTP service) with ESMTPS id 4Crg772nfKzCqkY; Wed, 9 Dec 2020 15:54:27 +0100 (CET) From: To: Daniel Migault CC: ADD Mailing list , "draft-btw-add-home@ietf.org" Thread-Topic: [Add] discussion on draft-btw-add-home Thread-Index: AQHWzjGv46XWoNjo4k6dfvaGIiwDNqnu2GcQ Date: Wed, 9 Dec 2020 14:54:25 +0000 Message-ID: <19393_1607525667_5FD0E523_19393_234_1_787AE7BB302AE849A7480A190F8B93303159A7A0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <3485_1607518673_5FD0C9D1_3485_172_40_787AE7BB302AE849A7480A190F8B93303159A5F6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303159A7A0OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Add] discussion on draft-btw-add-home X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 14:54:31 -0000 --_000_787AE7BB302AE849A7480A190F8B93303159A7A0OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmUtLA0KDQpJIHNlZS4NCg0KU3VjaCBpbmZvcm1hdGlvbiBjYW4gYmUgcmV0cmlldmVkOg0KKiBk aXJlY3RseSBmcm9tIHRoZSBzZXJ2ZXIgYXQgdGhlIGNvc3Qgb2YgZXN0YWJsaXNoaW5nIGEgY29u bmVjdGlvbiB3aXRoIGEgZGlzY292ZXJlZCBzZXJ2ZXIuDQoNCm9yDQoNCiogdXNlIHRoZSBBRE4g dG8gcXVlcnkgd2hhdGV2ZXIgZmF2b3VyaXRlLVJSIHdvdWxkIHByb3ZpZGUgdGhvc2UuDQoNCkNo ZWVycywNCk1lZA0KDQpEZSA6IERhbmllbCBNaWdhdWx0IFttYWlsdG86bWdsdC5pZXRmQGdtYWls LmNvbV0NCkVudm95w6kgOiBtZXJjcmVkaSA5IGTDqWNlbWJyZSAyMDIwIDE0OjQ2DQrDgCA6IEJP VUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+DQpD YyA6IEFERCBNYWlsaW5nIGxpc3QgPGFkZEBpZXRmLm9yZz47IGRyYWZ0LWJ0dy1hZGQtaG9tZUBp ZXRmLm9yZw0KT2JqZXQgOiBSZTogW0FkZF0gZGlzY3Vzc2lvbiBvbiBkcmFmdC1idHctYWRkLWhv bWUNCg0KSGksDQoNCkl0IHNlZW1zIHN1ZmZpY2llbnQgdG8gdXBncmFkZSBhIGRlc2lnbmF0ZWQg cmVzb2x2ZXIgZnJvbSBEbzUzIGludGVyZmFjZSB0byBEb1Qgb3IgRG9ILiBIb3dldmVyLCB3aGVu IGEgRE5TIGNsaWVudCBuZWVkcyB0byBzZWxlY3QgYW1vbmcgZGlmZmVyZW50IHJlc29sdmVycyB0 aGUgc2VsZWN0aW9uIG1heSBiZSBiYXNlZCBvbiBvdGhlciBwYXJhbWV0ZXJzLiBFeGVtcGxlcyBJ IGNhbiB0aGluayBvZiBbMV0gYXJlLCB0aGUgYWJpbGl0eSB0byBmaWx0ZXIsIHRvIHBlcmZvcm0g RE5TU0VDIHZhbGlkYXRpb24sIHRoZSBuYW1lIHRoYXQgdGhlIHJlc29sdmVyIGNsYWltcyBiZWlu ZyBhdXRob3JpdGF0aXZlIGZvciwgYWNjZXB0YWJsZSBJUCBhZGRyZXNzZXMuLi4uDQoNCllvdXJz LA0KRGFuaWVsDQoNClsxXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWdsdC1h ZGQtcmRwLTAzI3NlY3Rpb24tOA0KDQpPbiBXZWQsIERlYyA5LCAyMDIwIGF0IDc6NTcgQU0gPG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+PiB3cm90ZToNCkhpIERhbmllbCwNCg0KTm90IHN1cmUgdG8gZ2V0IHlvdXIgcG9pbnQs IGJ1dCB0aGUgb3B0aW9ucyBjYW4gcmV0dXJuIGFuIEFETiwgYSBsaXN0IG9mIElQIGFkZHJlc3Nl cywgYW4gYWx0ZXJuYXRlIHBvcnQgbnVtYmVyLCB0eXBlKHMpIG9mIHRoZSBlbmNyeXB0ZWQgRE5T LCBhbmQgIFVSSSBUZW1wbGF0ZXMgZm9yIERvSC4gVGhhdOKAmXMgYWxyZWFkeSBhIGdvb2Qgc2V0 IG9mIGluZm9ybWF0aW9uIHRvIGJlIGxlYXJuZWQuDQoNCkRvIHlvdSBoYXZlIGluIG1pbmQgb3Ro ZXIgaW5mb3JtYXRpb24gdGhhdCBpcyB3b3J0aCB0byBiZSBkaXNjb3ZlcmVkPw0KDQpDaGVlcnMs DQpNZWQNCg0KRGUgOiBBZGQgW21haWx0bzphZGQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YWRk LWJvdW5jZXNAaWV0Zi5vcmc+XSBEZSBsYSBwYXJ0IGRlIERhbmllbCBNaWdhdWx0DQpFbnZvecOp IDogbWVyY3JlZGkgMjUgbm92ZW1icmUgMjAyMCAyMzowMg0Kw4AgOiBBREQgTWFpbGluZyBsaXN0 IDxhZGRAaWV0Zi5vcmc8bWFpbHRvOmFkZEBpZXRmLm9yZz4+DQpPYmpldCA6IFtBZGRdIGRpc2N1 c3Npb24gb24gZHJhZnQtYnR3LWFkZC1ob21lDQoNCkhpLA0KDQpJIHVuZGVyc3RhbmQgdGhlIEFE TiBkZXNpZ25hdGluZyB0aGUgRlFETiBvZiB0aGUgRE5TIHNlcnZlci4gSSBhbSB3b25kZXJpbmcg aWYgdGhlIEVuY3IgRE5TIFR5cGVzIGZpZWxkIG1heSBub3QgYmUgYSBiaXQgbGltaXRlZCwgYW5k IGlmIGl0IG1pZ2h0IG5vdCBiZSBwcmVmZXJyZWQgdG8gcmVxdWVzdCBhIHJlcXVlc3Qgb2YgdHlw ZSBTVkNCLg0KDQpBZGRpdGlvbmFsbHksIHRob3VnaCBpdCBtYXkgZGVwZW5kIG9uIHRoZSBzaXpl IG9mIHRoZSBTVkNCIHJlc3BvbnNlLCBJIGFtIGFsc28gd29uZGVyaW5nIGlmIHNlbmRpbmcgdGhl IHJhdyBTVkNCIHJlc3BvbnNlIGNvdWxkIGJlIHBvc3NpYmxlLg0KDQpZb3VycywNCkRhbmllbA0K DQotLQ0KRGFuaWVsIE1pZ2F1bHQNCkVyaWNzc29uDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0K DQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQoNCi0tDQpEYW5pZWwgTWlnYXVsdA0KRXJp Y3Nzb24NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_787AE7BB302AE849A7480A190F8B93303159A7A0OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBI VE1MIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOp Zm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkZSO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6Ymxh Y2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVj b3JhdGlvbjpub25lIG5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmUtLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj azttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHNlZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj azttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5TdWNoIGluZm9ybWF0aW9uIGNhbiBiZSByZXRy aWV2ZWQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4q IGRpcmVjdGx5IGZyb20gdGhlIHNlcnZlciBhdCB0aGUgY29zdCBvZiBlc3RhYmxpc2hpbmcgYSBj b25uZWN0aW9uIHdpdGggYSBkaXNjb3ZlcmVkIHNlcnZlci4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj azttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5vcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4qIHVzZSB0aGUgQUROIHRvIHF1ZXJ5IHdoYXRldmVyIGZh dm91cml0ZS1SUiB3b3VsZCBwcm92aWRlIHRob3NlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EZSZuYnNwOzo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IERhbmllbCBNaWdhdWx0IFttYWlsdG86bWdsdC5pZXRmQGdtYWlsLmNv bV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSA5IGTDqWNlbWJyZSAyMDIw IDE0OjQ2PGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBCT1VDQURBSVIgTW9oYW1lZCBUR0kvT0xOICZs dDttb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tJmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4g QUREIE1haWxpbmcgbGlzdCAmbHQ7YWRkQGlldGYub3JnJmd0OzsgZHJhZnQtYnR3LWFkZC1ob21l QGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW0FkZF0gZGlzY3Vzc2lvbiBv biBkcmFmdC1idHctYWRkLWhvbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGksJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyBzdWZmaWNpZW50IHRvIHVwZ3JhZGUgYSBkZXNpZ25h dGVkIHJlc29sdmVyIGZyb20gRG81MyBpbnRlcmZhY2UgdG8gRG9UIG9yIERvSC4gSG93ZXZlciwg d2hlbiBhIEROUyBjbGllbnQgbmVlZHMgdG8gc2VsZWN0IGFtb25nIGRpZmZlcmVudCByZXNvbHZl cnMgdGhlIHNlbGVjdGlvbiZuYnNwO21heSBiZSBiYXNlZCBvbiBvdGhlciBwYXJhbWV0ZXJzLiBF eGVtcGxlcyBJIGNhbiB0aGluayBvZiBbMV0gYXJlLA0KIHRoZSBhYmlsaXR5IHRvIGZpbHRlciwg dG8gcGVyZm9ybSBETlNTRUMgdmFsaWRhdGlvbiwgdGhlIG5hbWUgdGhhdCB0aGUgcmVzb2x2ZXIg Y2xhaW1zIGJlaW5nIGF1dGhvcml0YXRpdmUgZm9yLCBhY2NlcHRhYmxlIElQIGFkZHJlc3Nlcy4u Li48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ WW91cnMsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5EYW5pZWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LW1nbHQtYWRkLXJkcC0wMyNzZWN0aW9uLTgiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1tZ2x0LWFkZC1yZHAtMDMjc2VjdGlvbi04PC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIERlYyA5LCAyMDIw IGF0IDc6NTcgQU0gJmx0OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu Y29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhpIERhbmllbCwNCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5Ob3Qgc3VyZSB0byBnZXQgeW91ciBwb2ludCwg YnV0IHRoZSBvcHRpb25zIGNhbiByZXR1cm4gYW4gQUROLCBhIGxpc3Qgb2YgSVAgYWRkcmVzc2Vz LCBhbiBhbHRlcm5hdGUNCiBwb3J0IG51bWJlciwgdHlwZShzKSBvZiB0aGUgZW5jcnlwdGVkIERO UywgYW5kICZuYnNwO1VSSSBUZW1wbGF0ZXMgZm9yIERvSC4gVGhhdOKAmXMgYWxyZWFkeSBhIGdv b2Qgc2V0IG9mIGluZm9ybWF0aW9uIHRvIGJlIGxlYXJuZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5EbyB5b3UgaGF2ZSBpbiBtaW5kIG90 aGVyIGluZm9ybWF0aW9uIHRoYXQgaXMgd29ydGggdG8gYmUgZGlzY292ZXJlZD88L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkNoZWVycyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+TWVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQWRkIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOmFkZC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ YWRkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gRGFuaWVsIE1p Z2F1bHQ8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMjUgbm92ZW1icmUgMjAy MCAyMzowMjxicj4NCjxiPsOAJm5ic3A7OjwvYj4gQUREIE1haWxpbmcgbGlzdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmFkZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmFkZEBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBbQWRkXSBkaXNjdXNzaW9uIG9uIGRyYWZ0LWJ0 dy1hZGQtaG9tZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SGksJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdW5kZXJzdGFuZCZuYnNwO3RoZSBBRE4gZGVzaWduYXRp bmcgdGhlIEZRRE4gb2YgdGhlIEROUyBzZXJ2ZXIuIEkgYW0gd29uZGVyaW5nIGlmIHRoZSZuYnNw OzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5FbmNyIEROUyBUeXBl cyBmaWVsZCBtYXkgbm90IGJlIGEgYml0IGxpbWl0ZWQsJm5ic3A7YW5kDQogaWYgaXQgbWlnaHQg bm90IGJlIHByZWZlcnJlZCB0byByZXF1ZXN0IGEgcmVxdWVzdCBvZiB0eXBlIFNWQ0IuJm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPkFkZGl0 aW9uYWxseSwgdGhvdWdoIGl0IG1heSBkZXBlbmQgb24gdGhlIHNpemUgb2YgdGhlIFNWQ0IgcmVz cG9uc2UsIEkgYW0gYWxzbyB3b25kZXJpbmcgaWYgc2VuZGluZyB0aGUgcmF3IFNWQ0IgcmVzcG9u c2UgY291bGQgYmUgcG9zc2libGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Y29sb3I6YmxhY2siPllvdXJzLCZuYnNwOzxicj4NCkRhbmllbCZuYnNwOyZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0N CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5EYW5pZWwgTWlnYXVsdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5Fcmljc3NvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cHJlPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5DZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86 cD48L286cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48 L286cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+SWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48 L286cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwv cHJlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkRhbmllbCBNaWdhdWx0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Fcmljc3NvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt ZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B93303159A7A0OPEXCAUBMA2corp_-- From nobody Wed Dec 9 09:26:30 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D517D3A0FBD; Wed, 9 Dec 2020 09:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRus7Xu3pePs; Wed, 9 Dec 2020 09:26:26 -0800 (PST) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AFCD3A0D8B; Wed, 9 Dec 2020 09:26:26 -0800 (PST) Received: by mail-vk1-xa33.google.com with SMTP id i62so519494vkb.7; Wed, 09 Dec 2020 09:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=clpPeVwn521pORVfiUew3HE7IgsELu1lc8OBzU1WpOU=; b=bIARr1bYFa8JQF39LoLT4vHPjUzXF+eFNcqTb2ou1Idd75CecCt5Mf/eESKh8WUnzG Pg8J4p69AMmuO2/txKioMsvhtssrqycc3fNrBlbK8HjSegJf/a8CuVMr4v6Q0hSbYTvO u66hlJkoSVmRmxnnJ6p8ypTh+UJxW8ECm4B4GTbA/EeIfhmdLsWpqE24jfz0msSiea0t QgqbiWZC6u618ArhJLSuXwWQSarcje/Qrqkbgt2WR5f4sXcd/Lfv3y9W56UwQj3ccuP6 F+LXzjXw/Y/LzzUfYneUZWzrgYoQU8CK1FWszrOCWH83FlPylZ5M30SqDudtCkcfey1a waAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=clpPeVwn521pORVfiUew3HE7IgsELu1lc8OBzU1WpOU=; b=pRgE0etIyGoEj/X+JKI6qA7+IBdDsbwkO/RiQrMzecjESXQlqjhbGX8rFP4qI08yhT wim+q0CZ1MHiGGT5VVTxUMqM4uiQCg4Z8EfutTW4mcXNTgH4UekcU9W9Bwv4Y6VeIhv7 5uN4eY3uyIeWHzrJ1rD3FuBSX/zrFrKH51l/zy43CKTx71nKAsURfekJ4foeSVCdkiyH I3VkQ/eYst53nlw5QFtw0SqUIFNEjp5tN/J3fgXf4wn0bsjARQmWGduCzVTghpvJZjZs VomXdsSwOJ30f03JQEAHvyL9xUB0YE35VtPTUo/5nWoHiSl/Gdbxlk3fbuL0CVyld6Yo vSVw== X-Gm-Message-State: AOAM530JUxxy1Pn+iCNcUIaDSDExVVskNxaTkJ0olD0nunaT7oT1vzIw t/zfxdZUJd1mxdzGGe3J9T8Si1t6mmTukDSvg0M= X-Google-Smtp-Source: ABdhPJxsJ8ai7tdG7E3BKs9B6n/+cGvHC3yTIjTPvAKGP/IA3wUHJ78+ku045k88xzt+NQ31Hlm0+d2A4uY7JZJALa8= X-Received: by 2002:a1f:3293:: with SMTP id y141mr3298804vky.13.1607534785329; Wed, 09 Dec 2020 09:26:25 -0800 (PST) MIME-Version: 1.0 References: <3485_1607518673_5FD0C9D1_3485_172_40_787AE7BB302AE849A7480A190F8B93303159A5F6@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <19393_1607525667_5FD0E523_19393_234_1_787AE7BB302AE849A7480A190F8B93303159A7A0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <19393_1607525667_5FD0E523_19393_234_1_787AE7BB302AE849A7480A190F8B93303159A7A0@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Daniel Migault Date: Wed, 9 Dec 2020 12:26:13 -0500 Message-ID: To: Mohamed Boucadair Cc: ADD Mailing list , "draft-btw-add-home@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d7fcf505b60b5b17" Archived-At: Subject: Re: [Add] discussion on draft-btw-add-home X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 17:26:28 -0000 --000000000000d7fcf505b60b5b17 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the response. I agree and support your approach. I prefer the second option for the purpose of discovery as it enables the selection prior the connection of the resolver. Yours, Daniel On Wed, Dec 9, 2020 at 9:54 AM wrote: > Re-, > > > > I see. > > > > Such information can be retrieved: > > * directly from the server at the cost of establishing a connection with = a > discovered server. > > > > or > > > > * use the ADN to query whatever favourite-RR would provide those. > > > > Cheers, > > Med > > > > *De :* Daniel Migault [mailto:mglt.ietf@gmail.com] > *Envoy=C3=A9 :* mercredi 9 d=C3=A9cembre 2020 14:46 > *=C3=80 :* BOUCADAIR Mohamed TGI/OLN > *Cc :* ADD Mailing list ; draft-btw-add-home@ietf.org > *Objet :* Re: [Add] discussion on draft-btw-add-home > > > > Hi, > > > > It seems sufficient to upgrade a designated resolver from Do53 interface > to DoT or DoH. However, when a DNS client needs to select among different > resolvers the selection may be based on other parameters. Exemples I can > think of [1] are, the ability to filter, to perform DNSSEC validation, th= e > name that the resolver claims being authoritative for, acceptable IP > addresses.... > > > > Yours, > > Daniel > > > > [1] https://tools.ietf.org/html/draft-mglt-add-rdp-03#section-8 > > > > On Wed, Dec 9, 2020 at 7:57 AM wrote: > > Hi Daniel, > > > > Not sure to get your point, but the options can return an ADN, a list of > IP addresses, an alternate port number, type(s) of the encrypted DNS, and > URI Templates for DoH. That=E2=80=99s already a good set of information = to be > learned. > > > > Do you have in mind other information that is worth to be discovered? > > > > Cheers, > > Med > > > > *De :* Add [mailto:add-bounces@ietf.org] *De la part de* Daniel Migault > *Envoy=C3=A9 :* mercredi 25 novembre 2020 23:02 > *=C3=80 :* ADD Mailing list > *Objet :* [Add] discussion on draft-btw-add-home > > > > Hi, > > > > I understand the ADN designating the FQDN of the DNS server. I am > wondering if the Encr DNS Types field may not be a bit limited, and if it > might not be preferred to request a request of type SVCB. > > > > Additionally, though it may depend on the size of the SVCB response, I am > also wondering if sending the raw SVCB response could be possible. > > > > Yours, > Daniel > > > > -- > > Daniel Migault > > Ericsson > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > > > > -- > > Daniel Migault > > Ericsson > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --=20 Daniel Migault Ericsson --000000000000d7fcf505b60b5b17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the response. I agree and support your approach= . I prefer the second option for the purpose of discovery as it enables the= selection prior the connection of the resolver.

Yours,= =C2=A0
Daniel=C2=A0

On Wed, Dec 9, 2020 at 9:54 AM <mohamed.boucadair@orange.com> = wrote:

Re-,

=C2=A0

I see.

=C2=A0

Such information can be retrieved= :

* directly from the server at the= cost of establishing a connection with a discovered server.

=C2=A0

or

=C2=A0

* use the ADN to query whatever f= avourite-RR would provide those.

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Daniel Migault [mailto:mglt.ietf@gmail.com]
Envoy=C3=A9=C2=A0: mercredi 9 d=C3=A9cembre 2020 14:46
=C3=80=C2=A0: BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com&= gt;
Cc=C2=A0: ADD Mailing list <add@ietf.org>; draft-btw-add-home@ietf.org
Objet=C2=A0: Re: [Add] discussion on draft-btw-add-home

=C2=A0

Hi,=C2=A0

=C2=A0

It seems sufficient to upgrade a designated resolver= from Do53 interface to DoT or DoH. However, when a DNS client needs to sel= ect among different resolvers the selection=C2=A0may be based on other para= meters. Exemples I can think of [1] are, the ability to filter, to perform DNSSEC validation, the name that the res= olver claims being authoritative for, acceptable IP addresses....=

=C2=A0

Yours,=C2=A0

Daniel

=C2=A0

=C2=A0

On Wed, Dec 9, 2020 at 7:57 AM <mohamed.boucadair@orange.c= om> wrote:

Hi Daniel,

=C2=A0

Not sure to get your point, but t= he options can return an ADN, a list of IP addresses, an alternate port number, type(s) of the encrypted DNS, and =C2=A0URI Templates for DoH= . That=E2=80=99s already a good set of information to be learned.=

=C2=A0

Do you have in mind other informa= tion that is worth to be discovered?

=C2=A0

Cheers,

Med

=C2=A0

De=C2=A0: Add [mailto:add-bounces@ietf.org] De la part de Daniel Migault
Envoy=C3=A9=C2=A0: mercredi 25 novembre 2020 23:02
=C3=80=C2=A0: ADD Mailing list <add@ietf.org>
Objet=C2=A0: [Add] discussion on draft-btw-add-home=

=C2=A0

Hi,=C2=A0

=C2=A0

I understand=C2=A0the ADN designating the FQDN of th= e DNS server. I am wondering if the=C2=A0Encr DNS Types field may not be a bit limited,=C2=A0and if it might not be preferred to request a request of type SVCB.=C2=A0

=C2=A0

Additiona= lly, though it may depend on the size of the SVCB response, I am also wonde= ring if sending the raw SVCB response could be possible.

=C2=A0

Yours,=C2= =A0
Daniel=C2=A0=C2=A0

=C2=A0

--

Daniel Migault

Ericsson

______________________________________________________________________=
___________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
u>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.


=C2=A0

--

Daniel Migault

Ericsson

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.


--
Daniel Migault
Ericsson
--000000000000d7fcf505b60b5b17-- From nobody Wed Dec 9 23:25:12 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3373A05AA for ; Wed, 9 Dec 2020 23:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAXGaDs_HT4F for ; Wed, 9 Dec 2020 23:25:09 -0800 (PST) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75C523A0489 for ; Wed, 9 Dec 2020 23:25:07 -0800 (PST) Received: by family.redbarn.org (Postfix, from userid 716) id 356CDC3F03; Thu, 10 Dec 2020 07:25:05 +0000 (UTC) Date: Thu, 10 Dec 2020 07:25:05 +0000 From: Paul Vixie To: Martin Thomson Cc: add@ietf.org Message-ID: <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 07:25:11 -0000 On Wed, Dec 09, 2020 at 12:13:15PM +1100, Martin Thomson wrote: > On Wed, Dec 9, 2020, at 04:33, Eric Orth wrote: > > ... > > Requirements-in-a-vacuum problem: This is a fine statement in the abstract, > but if you look at how this might be implemented, I claim that you will find > that you have an opportunity to solve the overarching problem. i think the opportunity for obviation occurs elsewhere... > That is, the information the client needs to validate any same-party claim > would also allow it to authenticate the network provider identity or choose > a trustworthy, secured resolver. ...specifically here. validation is an antipattern here. if one is inclined to believe any answer received from the same-party claim-source, then one must be prepared to believe its same-party claims. if we must reject either due to non-validation, then we must reject both, which is absurd. reason backward. > Why would devote resources to solving the same-provider problem when that > might solve the real problem the group has? we won't be. we will either say that the referral ("pointer") must only be sent for same-entity, or say that same-entity is a boolean attached to the referral ("pointer"). the rest is local policy, and out of scope. > Ted made a similar point, namely that any same-provider claim is > unverifiable. ... i answered ted similarly. > ... If it was important and verifiable, then it might be worth pursuing, > but while there might be some uncertainty about the former, the latter > needs support for me to consider that pursuit. this is nonsequitur, though at heart, noone will expect you to pursue something you see no point in. -- Paul Vixie From nobody Thu Dec 10 15:48:32 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D70A3A1350 for ; Thu, 10 Dec 2020 15:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=gnuhMZY7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CKRK9qSZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JITwn2uHdZJJ for ; Thu, 10 Dec 2020 15:48:26 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7F03A134C for ; Thu, 10 Dec 2020 15:48:25 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 22113AF7; Thu, 10 Dec 2020 18:48:25 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Thu, 10 Dec 2020 18:48:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=Z9UcdX9jDMkGt/N7p29brUbxCL75 5jH4Vs+Pt2kmzMw=; b=gnuhMZY7CNyY7ggYFDsm++VfDOoqHyhkolJ67/UFECik Ujq01aL/NnlXGUpz0Mb4QiaV+wQ+gug1XhcbKSyfqMfyUC2N7HSONC4cwIEIbXX2 61zdkqKqwxSfKeiWBv0msINW6WJUExNOD+M9WVIlpasxe0MrpL0meeSHBj/WmhgI 4PzUN/1IpfHrnPG6mB7hcBxgfhvjaOK2MQQq8DEeX/NY8gps5J5+hlQ+u518aG5I NB/hEkv2BIBfzOwHjB8ZFp4AEqJgX0nQr8XTSJSOY+xJgxmGCulfQS1CIRRwUUsU Qy6SMXF5K12wqr8ND6zOIAbafnYzQwNyiQlFq0PBOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=Z9UcdX 9jDMkGt/N7p29brUbxCL755jH4Vs+Pt2kmzMw=; b=CKRK9qSZnwZu+8x6Lzf3u+ F/tOfuaNvqFa4DL0BoDwU8EibXWp3ER6kDMrnI1dssJrazdcEwhYcv1MHXYY/2n8 Mwc89I4a6EOKkS1RJ7McSuAXep8u2shxMkRHlQOi6G3rG0qmjQshimvYgV8KXkoC Zm+vdElv4PVzI5mWpoS+F7DielVgDaxoITGtLAQ1jMReZis4Tg+/8y/Gg3RTNX0l NCS8Ysb5yu7qfJ49x+7yz0MZIjn3WkqiiJ3tzB4je09U5gS++xk1ZEYtEiQRuvdN zoTlkSuZp+NqYPpjJvmkGrXoqGyohaV9p+JFPcFF2mRVApoGKFFvk38iWZxWS6ow == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekuddgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepkeetueeikedtkeelfeekvefhkeffvedvvefgkefgleeugfdvjeej geffieegtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E93372006A; Thu, 10 Dec 2020 18:48:22 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> In-Reply-To: <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> Date: Fri, 11 Dec 2020 10:48:03 +1100 From: "Martin Thomson" To: "Paul Vixie" Cc: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 23:48:27 -0000 On Thu, Dec 10, 2020, at 18:25, Paul Vixie wrote: > ...specifically here. validation is an antipattern here. if one is inclined > to believe any answer received from the same-party claim-source, then one must > be prepared to believe its same-party claims. if we must reject either due to > non-validation, then we must reject both, which is absurd. reason backward. I think that we agree on the facts, but not the conclusion you draw from it. I conclude that same-entity isn't a requirement that is worth trying to build a protocol mechanism for. I infer that you would agree, but still insist on same-entity being a deployment requirement. Is that the split? From nobody Fri Dec 11 02:01:42 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E05C3A0896 for ; Fri, 11 Dec 2020 02:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdLo_K734O9x for ; Fri, 11 Dec 2020 02:01:38 -0800 (PST) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A3F3A02BD for ; Fri, 11 Dec 2020 02:01:37 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx4.open-xchange.com (Postfix) with ESMTPS id CB8B86A335; Fri, 11 Dec 2020 11:01:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1607680893; bh=dh2wngCaFTSvVPr9vLxsUzLFnd9WsFGjYVJffmdAfng=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=E/YYd63ohPyGqcMwX2iqEvtcqyc0zcqbIiFOs4U/kz3g4BG/CR1Q+xyPHOWWXg08D NAIYru5/qrvxutmCmkZ0QefZ98oBsZUosCDbM1soNrFhZdy0wwXhTtT8qKuMgh3PM/ 1YEpAX9SttXKl/NwHYM+NszvYD7sVZrPAB5gMcNXEj7iO9oftWh1b1pOUHyj6mJS+o +6NohiecaMqG+PG/kRQI+M8XdXpUGddEKxi5BPo120snzI1SAVhLqnDNWH3PyiuWod R7D3Wz0ML4Lger+BspPIhg1zl+IZRZEoPBBrpa9e3KWJ542E2fEONSfwxTTCDNZWBs jv/H8BozXkSNA== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id BF03E3C052C; Fri, 11 Dec 2020 11:01:33 +0100 (CET) Date: Fri, 11 Dec 2020 11:01:33 +0100 (CET) From: Vittorio Bertola To: Martin Thomson , Paul Vixie Cc: add@ietf.org Message-ID: <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> In-Reply-To: <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev14 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 10:01:40 -0000 > Il 11/12/2020 00:48 Martin Thomson ha scritto: > > > On Thu, Dec 10, 2020, at 18:25, Paul Vixie wrote: > > ...specifically here. validation is an antipattern here. if one is inclined > > to believe any answer received from the same-party claim-source, then one must > > be prepared to believe its same-party claims. if we must reject either due to > > non-validation, then we must reject both, which is absurd. reason backward. > > I think that we agree on the facts, but not the conclusion you draw from it. I conclude that same-entity isn't a requirement that is worth trying to build a protocol mechanism for. I infer that you would agree, but still insist on same-entity being a deployment requirement. Is that the split? If I may provide another perspective, I think that the requirements for non-experimental deployment models will be significantly shaped by the legal constraints. Thus, same-entity is likely to be a deployment requirement for those that want to do automatic upgrades in countries with strict privacy laws, as it avoids the problem of how to legally add one more entity into the personal data loop without having to ask anything to the user. If we want to give up providing a better technical mechanism for same-provider auto-upgrade, we should be very clear on whether we also mean that we recommend not to use that as a deployment model, or that we recommend to use it through existing technologies, or that we do not want to enter into that decision as it is a policy choice, so both choices would be valid. In any case, there are strong expectations among external non-technical stakeholders that the IETF will soon produce a SPAU discovery mechanism, as that has been understood as the way through which the IETF will respond to the policy issues raised by early DoH deployments. If this is not the case any more, we'd better have a clear plan B. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Fri Dec 11 02:05:30 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5D83A08BD for ; Fri, 11 Dec 2020 02:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=OxHCzwiI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=U3QQsAC5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooEwvwMC5oX5 for ; Fri, 11 Dec 2020 02:05:25 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00223A08D4 for ; Fri, 11 Dec 2020 02:05:24 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E31375C018F; Fri, 11 Dec 2020 05:05:23 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Fri, 11 Dec 2020 05:05:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=cepwLIrkiUM6593JDVcRxU52+bsc gcIQxnLXx5dKG9Q=; b=OxHCzwiIAKSLSesQf1N2xisDplvP962ljoVdYvVQVXxa 62aM2oJynpfBFP0iOjx43+Fz7wB5nML0EIGlZxYr6UJFTxipxCDluUwTub/5Gyl/ DtSbhUCknpISMLjerUdNgc/CVTa8yoWveQbP3kEVvtWxA/EF4oF6Er4qctmRqHt3 9we/xX5QRNhoBtlZtbCU82IS0771eK9d04SQh6bk5yx2+NHbGGlv8W4/UXESahsm PYSviqyWsOQ+DQhoO6S4700jQqLB15HjvEaalsMJEzUoy3wQOCmDljUOA5b4YnXt P32JX3NlgIVxXzQZ9KpEtLZzvFziZxXKq4FeH0fqYg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=cepwLI rkiUM6593JDVcRxU52+bscgcIQxnLXx5dKG9Q=; b=U3QQsAC5qxvu1KAVAKeiML 7f4XLJv0294GON0OOjYnYEZNpgI5KHVQFP+mSlhnYT1ogdSb6zug3WnuiOKvst5p hk3B5MzmDcv519J142iHETFyzGZI0x+qPpqnJAc/SW93XrbD3+lNumtEku9KEhit b+N7lHGwvUPGa/QfJNM5e7CYvmuq5jtjq2c715qVrH24Rls+xws6U45OjgYfwerr ZbkOY1A5jk+WFpKeNPRuT+zM20/eBA+oiCmyF/bATeFhhzY6a0TaIDghHBteP/D6 wned4h4T6Fb96UfEyPSZnjxjkNFai8Y52IWpNnt175Yq7Z6Tpw5VxgyAXEljcOAQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekvddgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepkeetueeikedtkeelfeekvefhkeffvedvvefgkefgleeugfdvjeej geffieegtdejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A7EA2006A; Fri, 11 Dec 2020 05:05:18 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <58427333-bcb0-4a4e-bcff-7722da565d43@www.fastmail.com> In-Reply-To: <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> Date: Fri, 11 Dec 2020 21:04:57 +1100 From: "Martin Thomson" To: "Vittorio Bertola" , "Paul Vixie" Cc: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 10:05:26 -0000 On Fri, Dec 11, 2020, at 21:01, Vittorio Bertola wrote: > If I may provide another perspective, I think that the requirements for > non-experimental deployment models will be significantly shaped by the > legal constraints. Thus, same-entity is likely to be a deployment > requirement for those that want to do automatic upgrades in countries > with strict privacy laws, as it avoids the problem of how to legally > add one more entity into the personal data loop without having to ask > anything to the user. This seems reasonable. What expectations do you have regarding where the responsibility for compliance would lie in the case where a network operator provides a reference? Or, where the DNS resolver provides a reference? Would the client share responsibility? I ask because if the client can't authenticate the claim, it might not be reasonable to have it assume responsibility in this case. It might be that best effort (check that the IP matches) is acceptable though. (It might be that this comes down to: wait and see, then ask a lawyer, that's OK too, but it doesn't give us much to base design decisions on.) From nobody Fri Dec 11 07:12:12 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296C63A0C88 for ; Fri, 11 Dec 2020 07:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nominet.uk header.b=MWChI8tl; dkim=pass (1024-bit key) header.d=nominetuk.onmicrosoft.com header.b=tr1+q/S+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjEomOmeLTKY for ; Fri, 11 Dec 2020 07:12:09 -0800 (PST) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F8D3A0C06 for ; Fri, 11 Dec 2020 07:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nominet.uk; i=@nominet.uk; q=dns/txt; s=nominetuk.dkim.nominet.selector2; t=1607699529; x=1639235529; h=from:to:subject:date:message-id:mime-version; bh=MNirWSbgQci4QEgJJW7QBOdD+kOOYgXnm+V8/+a3Qrg=; b=MWChI8tlZrpZofjRi/QAcZcWsJJOSGA8Hmjw85YuxGIDwmYgJx8Ap1sJ x7UE7t5qzg33wmLdeHbcKsdz/ipymlvi1PJVpetsXxnAfdrio8JS+/Fgi FDwkevi+v9KuIcqtYobjii6a+aBedq7YlcD1R6aAnQobbxm5+1M3B7S+3 e3EFuYxtxWwcEk3C3HxGFYc+Z3VJV9aVCZxczJRj5eaI09I7MncBc4SYb mhgWdpKjCiVh02DTtw7UlKvgdAa6MnCJ8j4O2JG8vySu+M2O8q3whe8Zu +PIbYnzFrf72Q58+zy7HVDc1l4/GbitMrZmLTCmau+PbtqHrKrPVeTO2M Q==; IronPort-SDR: 55vS9NK0neg/XFCXQUvs48VpFp81hbowXn4bcf48PPGz9EFqIS1Q82250UJromB2RHzyHzpK5g UtBs2rVz9ISi1sm7nT4HmVpSdpFFLzKCa7ISl2LKQr5vD0lbJ5SjFt9dxD7oiaLj/ZOqjOKtfQ XSJ4dKfpoDi+pA6GoIxObACgmaUJd/VB+U9Zq5rWOvs+puh9DZumI2nFd7kePCI8Quk58i2Lih S3CHjMRb0S/+qbD2oSv6qSagxzYROo5hq3ixz8mx4rY2P5V6bQuKHlAsOes4BVTbQR0HaNa+jk MkA= Received: from mail-ve1eur01lp2055.outbound.protection.outlook.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) ([104.47.1.55]) by mx2.nominet.org.uk with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Dec 2020 15:12:08 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gjw3ckeSc6nrTeX0wKTEXO9OoljnZ2ZnBd3ek0aEqMBkaBPMyaX8TZ5Y9vwcl3e1L5xr+tn0kIgja7+k+npa5UAGHYhN+0hXXzJAowJUkDpfGDZhI4IyVl1iXUcD1sukdERp08lRLTa1yCPlofJRe4ZFIlIMZ6q1NLj8ibuMLGcRg58ndTcKOKdMiCCIFdp+vjR8yXQYOtXztdqD3yaPwv24Tm5ZWh/5F+0npjgu/kLQUj7JHOXxhPZAQalSpye91eewgKt6JgaQS3mJACJsvaNAg4MKjJJ8k9s5yuR+eESaapy9rFAUs9HEbE05r+BPU7LeZv+eYYMvFqCxybfJ4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MNirWSbgQci4QEgJJW7QBOdD+kOOYgXnm+V8/+a3Qrg=; b=L1A1Ew+xqZZCCiXqH4uom7Uh2UfCGNgA+LWrRIqldVH2oLK+uVDar6kWQenbMzDPzlq81sZsMamzru3XQMRgct7CYpc5/fb/AprAqH7kghlOyRc/FJmckx4qCumiyWSjzy9KKHWmr+FS/wiBAub+2Fm8VhkyxljZgk6CtAKhlb29Qrw5xY2X/zLyY6hdF66seKvLjF56jdPKRC5BYzkjFS7MVT86UYqibMvYEhVoPMiEWSsZaY7YVmUZFN3F+Mh05y3F4iAteMw0EHzW30fepNMHLMlkLR40JJPOHsb0V8m18p1J5vrNpM+cH/SeG0KQ9ubiPfu9aKsTlmhc1pXNSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nominet.uk; dmarc=pass action=none header.from=nominet.uk; dkim=pass header.d=nominet.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NominetUK.onmicrosoft.com; s=selector2-NominetUK-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MNirWSbgQci4QEgJJW7QBOdD+kOOYgXnm+V8/+a3Qrg=; b=tr1+q/S+uRtq4foJuFyHmdMzoUMvxm5ejCXvC0ONi1hdGtEEN4vgxdzAlHOeZgvIWdNu2YAuunEwb/X8Vvjgx79hJL6cSErxQnd4eRr85YXEA1VqV33IjEr8QvDKbKR7RdzDGmeyONn7Ng/3RSCYuyiCIWAZJU++UOBy/tkCd7I= Received: from DB3PR0502MB4025.eurprd05.prod.outlook.com (2603:10a6:8:8::25) by DB6PR0501MB2647.eurprd05.prod.outlook.com (2603:10a6:4:81::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.15; Fri, 11 Dec 2020 15:12:05 +0000 Received: from DB3PR0502MB4025.eurprd05.prod.outlook.com ([fe80::a47f:eca4:b02b:2c97]) by DB3PR0502MB4025.eurprd05.prod.outlook.com ([fe80::a47f:eca4:b02b:2c97%5]) with mapi id 15.20.3632.025; Fri, 11 Dec 2020 15:12:05 +0000 From: Brett Carr To: ADD Mailing list Thread-Topic: OARC 34 Workshop, February 4th & 5th, Registration and Call for Contributions now open Thread-Index: AQHWz8/8bK3nifblvESgWjy2/B6Kgw== Date: Fri, 11 Dec 2020 15:12:05 +0000 Message-ID: <115E338F-420A-4E4E-989D-3559BF3AB585@nominet.uk> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nominet.uk; x-originating-ip: [81.110.99.158] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5b4d273e-bcf7-4561-dddf-08d89de71f04 x-ms-traffictypediagnostic: DB6PR0501MB2647: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pVSiShW6p0wK2B8kjc+3/dKTMySiQY1wtnDprSy32s5XMpNydYZ7kftSO1Acs5yZxs6q7aHkqABETw5AvDoKHyo85h1keLG0ZsdTwepk2VCN998S+PpCdIku6cJTflDwZ8SpTCxheMONqWJkHC/5So1mHUldo12d2jIKPCdIbFhPCsn+m0DWrVqJbif2/FVWLwVLQlq6M8jJJYTYRVpH7sWK97OP+2DwiGw9yXlk9ZDxQ9v93RdKmIocI07J14jR4Xf/2Qek4O+8++rHjUhQicnisxfj6tp47IbIawQENCq8uRz3DE+7zecNgqI7NQAITQeI+dRtZoiogVZdgbbt9Uf+jWxiFLkj9Siq5rGXli+pvEA8sTgfxSZu3W9QzqXSpBOCxw42ld5DBjZgt9vnDny6YA2DDeLUBnqVRWFSzbo5JNXJbszefWU04/7j0XdhO72At/KMzwKjgycs+7HNJw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB3PR0502MB4025.eurprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(376002)(136003)(396003)(39850400004)(76116006)(33656002)(316002)(478600001)(6506007)(83380400001)(66556008)(66446008)(64756008)(6486002)(66476007)(44832011)(966005)(8676002)(6916009)(2906002)(26005)(2616005)(86362001)(66946007)(71200400001)(6512007)(5660300002)(8936002)(36756003)(186003)(91956017)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?aWRhdzRmcExoNjR0NGEzWTQ5Z2R3d0x6RmI2bDl4Nm5tMjJRTUJSYVE2OUNu?= =?utf-8?B?SS91ZWQ1NHd1NlFVVnc0VjhaaE9ld3R3clZERE9VbmNVeStIaS9aTTlBTUFN?= =?utf-8?B?YTBWTUVoQ3QzK2lxR3ZBZHNOVHdOT1d6d3ZYZDQvdHo3WURNbVhQNHlDK0RJ?= =?utf-8?B?SEh0KzJsUHlLMkFGeGVwOGxTVXJzRnd0VzgyTDZEakpoL0ROQTJkamtBMTJ6?= =?utf-8?B?cnU1Tlh3TlRrOEs2SG5rK21uQXVLWUU0WlVzQ2d3K2hzSml5d2R3QzNtQm1j?= =?utf-8?B?NTVOQ1UxOXJIWlFlbjEwblBLVDR0NmZoRXB4aTNPcjJrNDVOanJtWHp0anBE?= =?utf-8?B?VElTSTRwaG8vaGhaYmIrTkI0YnBxNUFoS21LMVJ0UnB0aHIyTHhrQUdLSDNG?= =?utf-8?B?Um9iM0tSQkdGL3FHK0JsK3d2QnlkN2trOEhGOUhYTDMyeHRobHpUTEYrSUc5?= =?utf-8?B?WEV3YzlZWXovT3lTT25PT3krcHlWL25aemJPejRTQkhmU0VsV1k4YUNNOG1i?= =?utf-8?B?VXZMUXFaTzRDdjJyRVJoUmRIUlByWmJXTkl1V2tkMUV0ZzY0djJvczZ4Y1Qv?= =?utf-8?B?K3ZJZmdpKzlBWFBoZGNBVEtyZlJacUdzMUNQdVNmcFdGbHpwbFdTeVZ5c09q?= =?utf-8?B?UW5sM2lGR2REZ3R5b0tNLzJDTWRLSFUwKzdyaUIyRTVmcjEyZURwRFNzR2Er?= =?utf-8?B?NXJBYnU3T3ZKdzQrZnA0U0hTcW53TDFFQ245aVBXWkY1N0VjT21iNjRHcXhz?= =?utf-8?B?WUFXQzhLVi82U2NyclFLSmxYTXVybzRUdGp6YU16Q3RRa2ttK3dxQjNzcHVt?= =?utf-8?B?RUJOZjVJQjhTZjNuTkE4clB1emdNM1poN1NDWG01ZWlQaVR2bWpxUWEwcXZZ?= =?utf-8?B?UE5RQ0hIVDN4anlxOEVndWdBV3MzNmZvVi9NQ2lXd2h6NTVVWHBrWTlvMy9J?= =?utf-8?B?UFpvVnlkSzl3UW9Gd3pXOEF1N2ZLeDBRUjN3aThHeldCZVlHRDZMZjZVcm9T?= =?utf-8?B?SlQ1bmxkeTRVcXlhOWtrQXZkZTZ2dlpZejlPUDNOWXZ1NFI3N0tMUmQvNUxK?= =?utf-8?B?UERyVkRYejJJNEI5ZmZ6S2xCUUpwK2sxUTZuWTZGTnFsREtrS1VWQWlSUzE4?= =?utf-8?B?SU1CM2N6MjRKK2d6R200NDh6eWs4dysrOHJEWWtIVHhJa3B6ZjNERHkwUytZ?= =?utf-8?B?d2tsRnBHa0N5bnprS0tKc282K1pQZFRFcEluVnR1M2pFL1FvbFJmY3hPeS9k?= =?utf-8?B?S01pZ0l2K0dBc1YzUks3RWErbHRJa1V1c1NPTGhmNDdUemhHZkNkSjltT1FB?= =?utf-8?Q?zlpogjwTTNI1+IFwGXucoAZPzmvZ9yBoSU?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_115E338F420A4E4E989D3559BF3AB585nominetuk_" MIME-Version: 1.0 X-OriginatorOrg: nominet.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB3PR0502MB4025.eurprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5b4d273e-bcf7-4561-dddf-08d89de71f04 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Dec 2020 15:12:05.4754 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 797b4183-8c85-46bd-ba6d-6371cfdf5059 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +sZEAkBgdb7j4gpOyVR7yxe2vw5ye4mySD17dpq/06rdFjMyQvGuUZSQP4d2YTml9iaZ1LwQhXm5jns1uX2v3g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0501MB2647 Archived-At: Subject: [Add] OARC 34 Workshop, February 4th & 5th, Registration and Call for Contributions now open X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 15:12:11 -0000 --_000_115E338F420A4E4E989D3559BF3AB585nominetuk_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0FSQyAzNCB3aWxsIGJlIGFuIG9ubGluZSBtZWV0aW5nIG9uIEZlYnJ1YXJ5IDR0aCAmIDV0aCBz dGFydGluZyBhdCAxNjowMCBVVEMuIFRoZSBQcm9ncmFtbWUgQ29tbWl0dGVlIGlzIHNlZWtpbmcg Y29udHJpYnV0aW9ucyBmcm9tIHRoZSBjb21tdW5pdHkuDQoNCkFsbCBETlMtcmVsYXRlZCBzdWJq ZWN0cyBhbmQgc3VnZ2VzdGlvbnMgZm9yIGRpc2N1c3Npb24gdG9waWNzIGFyZSB3ZWxjb21lLiBC YXNlZCBvbiB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgcHJldmlvdXMgd29ya3Nob3AsIHRoZSBETlMt T0FSQyBhdWRpZW5jZSBpcyBpbnRlcmVzdGVkIHRvIHNlZSBtb3JlIGNvbnRlbnQgcmVsYXRlZCB0 byBETlMgb3BlcmF0aW9ucy4gVGhlcmVmb3JlIHdlIGFyZSBwYXJ0aWN1bGFybHkgaW50ZXJlc3Rl ZCBpbiBzdWJtaXNzaW9ucyBmcm9tIEROUyBPcGVyYXRvcnMgYWJvdXQgYXR0YWNrIG1pdGlnYXRp b24gYW5kIGFueSBtYWpvciAocHVibGljIG9yIG5vbi1wdWJsaWMpIEROUyBvdXRhZ2VzIHRoYXQg eW91ciBvcmdhbml6YXRpb24gbWlnaHQgaGF2ZSBmYWNlZCBvdmVyIHRoZSBsYXN0IHllYXIgb3Ig c28sIHRoZSBzdGVwcyB0YWtlbiB0byByZXNvbHZlL21pdGlnYXRlIHRoZSBpbW1lZGlhdGUgaXNz dWUsIGFuZCB0byBwcmV2ZW50IGZ1dHVyZSBzdWNoIGV2ZW50cyBhbmQgYW55IGxlc3NvbnMgbGVh cm5lZC4NCg0KQXMgaXQgaXMgYW4gb25saW5lIHdvcmtzaG9wLCB3ZSdkIGxpa2UgdG8gZW5jb3Vy YWdlIGJyZXZpdHk7IHByZXNlbnRhdGlvbnMgc2hvdWxkIG5vdCBiZSBsb25nZXIgdGhhbiAyMCBt aW51dGVzICh3aXRoIGFkZGl0aW9uYWwgdGltZSBmb3IgcXVlc3Rpb25zKS4NCg0KKipXb3Jrc2hv cCBNaWxlc3RvbmVzOioqDQoNCiogOSBEZWMgMjAyMCAtIFN1Ym1pc3Npb25zIG9wZW4gdmlhIElu ZGljbw0KKiA0IEphbiAyMDIxIC0gRGVhZGxpbmUgZm9yIHN1Ym1pc3Npb24gKDIzOjU5IFVUQykN CiogMTQgSmFuIDIwMjEgLSBJbml0aWFsIENvbnRyaWJ1dGlvbiBsaXN0IHB1Ymxpc2hlZA0KKiAy MSBKYW4gMjAyMSAtIEZ1bGwgYWdlbmRhIHB1Ymxpc2hlZA0KKiAyOCBKYW4gMjAyMSAtIERlYWRs aW5lIGZvciBzbGlkZXNldCBzdWJtaXNzaW9uIGFuZCBSZWhlYXJzYWwNCiogNCBGZWIgMjAyMSAt IE9BUkMgMzQgV29ya3Nob3ANCg0KVGhlIFJlZ2lzdHJhdGlvbiBwYWdlIGFuZCBkZXRhaWxzIGZv ciBwcmVzZW50YXRpb24gc3VibWlzc2lvbiBhcmUgcHVibGlzaGVkIGF0Og0KDQogICAgPGh0dHBz Oi8vd3d3LmRucy1vYXJjLm5ldC9vYXJjMzQ+DQoNClRvIGFsbG93IHRoZSBQcm9ncmFtbWUgQ29t bWl0dGVlIHRvIG1ha2Ugb2JqZWN0aXZlIGFzc2Vzc21lbnRzIG9mIHN1Ym1pc3Npb25zLCBzbyBh cyB0byBlbnN1cmUgdGhlIHF1YWxpdHkgb2YgdGhlIHdvcmtzaG9wLCBzdWJtaXNzaW9ucyBTSE9V TEQgaW5jbHVkZSBzbGlkZXMuIERyYWZ0IHNsaWRlcyBhcmUgYWNjZXB0YWJsZSBvbiBzdWJtaXNz aW9uLg0KDQpBZGRpdGlvbmFsIGluZm9ybWF0aW9uIGZvciBzcGVha2VycyBvZiBPQVJDIDM0Og0K DQogICogeW91ciB0YWxrIHdpbGwgYmUgYnJvYWRjYXN0IGxpdmUgYW5kIHJlY29yZGVkIGZvciBm dXR1cmUgcmVmZXJlbmNlDQogICogeW91ciBwcmVzZW50YXRpb24gc2xpZGVzIHdpbGwgYmUgYXZh aWxhYmxlIGZvciBkZWxlZ2F0ZXMgYW5kIG90aGVycyB0byBkb3dubG9hZCBhbmQgcmVmZXIgdG8s IGJlZm9yZSwgZHVyaW5nIGFuZCBhZnRlciB0aGUgbWVldGluZw0KICAqIHlvdSB3aWxsIGJlIGV4 cGVjdGVkIHRvIGF0dGVuZCBhIHJlaGVhcnNhbCBvbiBKYW51YXJ5IDI4dGguIEl0IHdvdWxkIGJl IHZlcnkgdXNlZnVsIHRvIGhhdmUgeW91ciBzbGlkZXMgKGV2ZW4gaWYgZHJhZnQpIHJlYWR5IGZv ciB0aGlzLg0KDQpJZiB5b3UgaGF2ZSBxdWVzdGlvbnMgb3IgY29uY2VybnMgeW91IGNhbiBjb250 YWN0IHRoZSBQcm9ncmFtbWUgQ29tbWl0dGVlOg0KDQogICAgaHR0cHM6Ly93d3cuZG5zLW9hcmMu bmV0L29hcmMvcHJvZ3JhbW1lDQoNCnZpYSA8c3VibWlzc2lvbnNAZG5zLW9hcmMubmV0Pg0KDQpC cmV0dCBDYXJyLCBmb3IgdGhlIEROUy1PQVJDIFByb2dyYW1tZSBDb21taXR0ZWUNCg0KT0FSQyBk ZXBlbmRzIG9uIHNwb25zb3JzaGlwIHRvIGZ1bmQgaXRzIHdvcmtzaG9wcyBhbmQgYXNzb2NpYXRl ZCBzb2NpYWwgZXZlbnRzLiAgUGxlYXNlIGNvbnRhY3QgPHNwb25zb3JAZG5zLW9hcmMubmV0PiBp ZiB5b3VyIG9yZ2FuaXphdGlvbiBpcyBpbnRlcmVzdGVkIGluIGJlY29taW5nIGEgc3BvbnNvci4N Cg0KKFBsZWFzZSBub3RlIHRoYXQgT0FSQyBpcyBydW4gb24gYSBub24tcHJvZml0IGJhc2lzLCBh bmQgaXMgbm90IGluIGEgcG9zaXRpb24gdG8gcmVpbWJ1cnNlIGV4cGVuc2VzIG9yIHRpbWUgZm9y IHNwZWFrZXJzIGF0IGl0cyBtZWV0aW5ncy4pDQoNCg0KLS0NCkJyZXR0IENhcnINCk1hbmFnZXIg RE5TIGFuZCBOZXR3b3JrIEVuZ2luZWVyaW5nDQpOb21pbmV0IFVLDQoNCg0K --_000_115E338F420A4E4E989D3559BF3AB585nominetuk_ Content-Type: text/html; charset="utf-8" Content-ID: <9CD9DFD94B3C414B95600E4488619D57@eurprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIj OTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5PQVJDIDM0IHdpbGwgYmUgYW4gb25saW5lIG1lZXRpbmcgb24gRmVicnVhcnkgNHRoICZh bXA7IDV0aCBzdGFydGluZyBhdCAxNjowMCBVVEMuIFRoZSBQcm9ncmFtbWUgQ29tbWl0dGVlIGlz IHNlZWtpbmcgY29udHJpYnV0aW9ucyBmcm9tIHRoZSBjb21tdW5pdHkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BbGwgRE5TLXJlbGF0ZWQgc3ViamVjdHMgYW5k IHN1Z2dlc3Rpb25zIGZvciBkaXNjdXNzaW9uIHRvcGljcyBhcmUgd2VsY29tZS4gQmFzZWQgb24g dGhlIGZlZWRiYWNrIGZyb20gdGhlIHByZXZpb3VzIHdvcmtzaG9wLCB0aGUgRE5TLU9BUkMgYXVk aWVuY2UgaXMgaW50ZXJlc3RlZCB0byBzZWUgbW9yZSBjb250ZW50IHJlbGF0ZWQgdG8gRE5TIG9w ZXJhdGlvbnMuDQogVGhlcmVmb3JlIHdlIGFyZSBwYXJ0aWN1bGFybHkgaW50ZXJlc3RlZCBpbiBz dWJtaXNzaW9ucyBmcm9tIEROUyBPcGVyYXRvcnMgYWJvdXQgYXR0YWNrIG1pdGlnYXRpb24gYW5k IGFueSBtYWpvciAocHVibGljIG9yIG5vbi1wdWJsaWMpIEROUyBvdXRhZ2VzIHRoYXQgeW91ciBv cmdhbml6YXRpb24gbWlnaHQgaGF2ZSBmYWNlZCBvdmVyIHRoZSBsYXN0IHllYXIgb3Igc28sIHRo ZSBzdGVwcyB0YWtlbiB0byByZXNvbHZlL21pdGlnYXRlIHRoZSBpbW1lZGlhdGUNCiBpc3N1ZSwg YW5kIHRvIHByZXZlbnQgZnV0dXJlIHN1Y2ggZXZlbnRzIGFuZCBhbnkgbGVzc29ucyBsZWFybmVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QXMgaXQgaXMgYW4g b25saW5lIHdvcmtzaG9wLCB3ZSdkIGxpa2UgdG8gZW5jb3VyYWdlIGJyZXZpdHk7IHByZXNlbnRh dGlvbnMgc2hvdWxkIG5vdCBiZSBsb25nZXIgdGhhbiAyMCBtaW51dGVzICh3aXRoIGFkZGl0aW9u YWwgdGltZSBmb3IgcXVlc3Rpb25zKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPioqV29ya3Nob3AgTWlsZXN0b25lczoqKjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+KiA5IERlYyAyMDIwIC0gU3VibWlzc2lvbnMgb3BlbiB2aWEg SW5kaWNvPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiogNCBKYW4gMjAyMSAtIERlYWRsaW5lIGZvciBzdWJt aXNzaW9uICgyMzo1OSBVVEMpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiogMTQgSmFuIDIwMjEgLSBJbml0 aWFsIENvbnRyaWJ1dGlvbiBsaXN0IHB1Ymxpc2hlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4qIDIxIEph biAyMDIxIC0gRnVsbCBhZ2VuZGEgcHVibGlzaGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiogMjggSmFu IDIwMjEgLSBEZWFkbGluZSBmb3Igc2xpZGVzZXQgc3VibWlzc2lvbiBhbmQgUmVoZWFyc2FsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPiogNCBGZWIgMjAyMSAtIE9BUkMgMzQgV29ya3Nob3A8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBSZWdpc3RyYXRpb24gcGFnZSBh bmQgZGV0YWlscyBmb3IgcHJlc2VudGF0aW9uIHN1Ym1pc3Npb24gYXJlIHB1Ymxpc2hlZCBhdDo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7aHR0cHM6Ly93d3cuZG5zLW9hcmMubmV0L29hcmMzNCZndDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRvIGFsbG93IHRoZSBQcm9ncmFtbWUgQ29t bWl0dGVlIHRvIG1ha2Ugb2JqZWN0aXZlIGFzc2Vzc21lbnRzIG9mIHN1Ym1pc3Npb25zLCBzbyBh cyB0byBlbnN1cmUgdGhlIHF1YWxpdHkgb2YgdGhlIHdvcmtzaG9wLCBzdWJtaXNzaW9ucyBTSE9V TEQgaW5jbHVkZSBzbGlkZXMuIERyYWZ0IHNsaWRlcyBhcmUgYWNjZXB0YWJsZSBvbiBzdWJtaXNz aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWRkaXRpb25h bCBpbmZvcm1hdGlvbiBmb3Igc3BlYWtlcnMgb2YgT0FSQyAzNDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAqIHlvdXIgdGFsayB3aWxsIGJlIGJyb2Fk Y2FzdCBsaXZlIGFuZCByZWNvcmRlZCBmb3IgZnV0dXJlIHJlZmVyZW5jZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij4mbmJzcDsgKiB5b3VyIHByZXNlbnRhdGlvbiBzbGlkZXMgd2lsbCBiZSBhdmFpbGFibGUg Zm9yIGRlbGVnYXRlcyBhbmQgb3RoZXJzIHRvIGRvd25sb2FkIGFuZCByZWZlciB0bywgYmVmb3Jl LCBkdXJpbmcgYW5kIGFmdGVyIHRoZSBtZWV0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAq IHlvdSB3aWxsIGJlIGV4cGVjdGVkIHRvIGF0dGVuZCBhIHJlaGVhcnNhbCBvbiBKYW51YXJ5IDI4 dGguIEl0IHdvdWxkIGJlIHZlcnkgdXNlZnVsIHRvIGhhdmUgeW91ciBzbGlkZXMgKGV2ZW4gaWYg ZHJhZnQpIHJlYWR5IGZvciB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDsgPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPklmIHlvdSBoYXZlIHF1ZXN0aW9ucyBvciBjb25jZXJucyB5b3UgY2FuIGNvbnRh Y3QgdGhlIFByb2dyYW1tZSBDb21taXR0ZWU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgaHR0cHM6Ly93d3cuZG5zLW9hcmMubmV0 L29hcmMvcHJvZ3JhbW1lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij52aWEgJmx0O3N1Ym1pc3Npb25zQGRucy1vYXJjLm5ldCZndDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkJyZXR0IENhcnIsIGZvciB0aGUgRE5TLU9BUkMgUHJv Z3JhbW1lIENvbW1pdHRlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+T0FSQyBkZXBlbmRzIG9uIHNwb25zb3JzaGlwIHRvIGZ1bmQgaXRzIHdvcmtzaG9wcyBhbmQg YXNzb2NpYXRlZCBzb2NpYWwgZXZlbnRzLiZuYnNwOyBQbGVhc2UgY29udGFjdCAmbHQ7c3BvbnNv ckBkbnMtb2FyYy5uZXQmZ3Q7IGlmIHlvdXIgb3JnYW5pemF0aW9uIGlzIGludGVyZXN0ZWQgaW4g YmVjb21pbmcgYSBzcG9uc29yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+KFBsZWFzZSBub3RlIHRoYXQgT0FSQyBpcyBydW4gb24gYSBub24tcHJvZml0IGJhc2lz LCBhbmQgaXMgbm90IGluIGEgcG9zaXRpb24gdG8gcmVpbWJ1cnNlIGV4cGVuc2VzIG9yIHRpbWUg Zm9yIHNwZWFrZXJzIGF0IGl0cyBtZWV0aW5ncy4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48YnI+DQotLTxicj4NCkJyZXR0IENhcnI8YnI+DQpNYW5hZ2VyIERO UyBhbmQgTmV0d29yayBFbmdpbmVlcmluZzxicj4NCk5vbWluZXQgVUs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_115E338F420A4E4E989D3559BF3AB585nominetuk_-- From nobody Fri Dec 11 09:10:31 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C8B3A0D37 for ; Fri, 11 Dec 2020 09:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4DNz9v5P64x for ; Fri, 11 Dec 2020 09:10:27 -0800 (PST) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0948F3A0D32 for ; Fri, 11 Dec 2020 09:10:26 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id B22816A32C; Fri, 11 Dec 2020 18:10:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1607706624; bh=VDGf8dWCQR39JFUEeXIe0km2ORWxqTuK+/xBjB4qqlw=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=zKzZSOWaQzjELt9h6L76KBoIC0Y33UVZ36mGSNO8jUdPd6zlC2Ygp6R2wb8y0CzcW F5g4EH0P+Yaw7E83GJ6hDVgy+0j2R+WeRFViicFjTVm+rQK17LQx7k1DrunppeF239 ndWoi4wl7CLoaIS1acJkGSAFf5OhcQ2YJyooZ5BWKR5qxRNmCtpcypPtKSjsGkb+qB 2SCAm8SgyRn+znNNv2MUGuOaVkdmzj6mgTbQJNzDGKPUs9K45/9EP9Cf8VXoAoQKjB evLkLKdLFnDTzSZK6UtdgycXJkguPPHtlK1T6/WcMYdS8leuC0dCvEvV+QuQKeqiq3 Gavu8FlK1LvUg== Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id A49503C0066; Fri, 11 Dec 2020 18:10:24 +0100 (CET) Date: Fri, 11 Dec 2020 18:10:24 +0100 (CET) From: Vittorio Bertola To: Martin Thomson , Paul Vixie Cc: add@ietf.org Message-ID: <2068518088.4578.1607706624615@appsuite-gw1.open-xchange.com> In-Reply-To: <58427333-bcb0-4a4e-bcff-7722da565d43@www.fastmail.com> References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> <58427333-bcb0-4a4e-bcff-7722da565d43@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.4-Rev14 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] [EXT] Re: Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 17:10:29 -0000 > Il 11/12/2020 11:04 Martin Thomson ha scritto: > > > On Fri, Dec 11, 2020, at 21:01, Vittorio Bertola wrote: > > If I may provide another perspective, I think that the requirements for > > non-experimental deployment models will be significantly shaped by the > > legal constraints. Thus, same-entity is likely to be a deployment > > requirement for those that want to do automatic upgrades in countries > > with strict privacy laws, as it avoids the problem of how to legally > > add one more entity into the personal data loop without having to ask > > anything to the user. > > This seems reasonable. What expectations do you have regarding where the responsibility for compliance would lie in the case where a network operator provides a reference? Or, where the DNS resolver provides a reference? Would the client share responsibility? This is definitely a question for a lawyer :-) In GDPR terms, I would say that the DNS client is at least a "joint controller" of the user's DNS queries, no matter who tells them what. But if you go down that path, you might conclude that the client will always have to ask for the user's informed consent whenever a new server is contacted, and you end up with the DNS version of cookie popups. As an exception, the resolver of the user's Internet access provider might be safe, as the user consents to share data with it when they sign a contract for Internet access. But again, this is a question for a lawyer. > I ask because if the client can't authenticate the claim, it might not be reasonable to have it assume responsibility in this case. It might be that best effort (check that the IP matches) is acceptable though. > > (It might be that this comes down to: wait and see, then ask a lawyer, that's OK too, but it doesn't give us much to base design decisions on.) This looks like a bit of a problem in the IETF's process: standards seem to be designed without having ascertained the non-technical requirements. Even if we wanted to do that, however, how to do that is not immediate. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Tue Dec 22 09:48:36 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8377B3A11CA for ; Tue, 22 Dec 2020 09:48:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfqLMI4_9HEl for ; Tue, 22 Dec 2020 09:48:32 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9873A1188 for ; Tue, 22 Dec 2020 09:48:32 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id p14so12604864qke.6 for ; Tue, 22 Dec 2020 09:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FVHfYdWk6ADka0x0wR4Tr+blTYQ5Rg41xn8kOXV91xw=; b=NzMaMj4DOKHXyqEfx9g2TdOYXr5NnTSoSclyUwLafGFw94RsyeVeuuTkaMK+zgmmey LI5AnqLwrNBr2krje03eJqcB/UIUgZvg0tSw5WBReffJ5EdkDl8AHeYLdl3R30CIclA6 RZR9lzxRoSbfunFoNfwyr6k3TGvfGcJXS4qoORSbWsPvlcExTWAu23S3xHMrZgnDFuLH JS4kYX/7DwWmPa853oobElVCUxmCA9j4JhZ9yuNozTsuTv1Ezsa19rmfLDbKHNFpjJpU Vr68Op5PpEMd0LjXM/+YRChBngl1XFzR2TchnUH9PkNhDi+XsqQLozvohVgK2jXdmYQj oNJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FVHfYdWk6ADka0x0wR4Tr+blTYQ5Rg41xn8kOXV91xw=; b=sg4C1I8jdd4V3qHEhrkVB+dmP3AUkZ3y7hhTyeKuq8/CoLuLOyATU3QFTRMsJPJLyt G24LtJTyr6OGg/pL0+HmcxoMu0pt1yMf9xnHD3pzE8SM+S8vlw1eb00C+RSQWZV/rA1U DyKvMLfOLYi2wirNu8eNnkUDx9S+ElYMeCVGBd/TBQHP46S1l6Bc4U64KEEcMzmoDJQ/ 7oZKD25xhS1WK1izVcy5Mqe8rf7DNfjGs9Fk88PmFLsRhl9Xk36h3Y0JInSw8s3aXg39 CaMzY2+yoBv8F5AI2slaPYfTIoi0FfHQxUPVel3MNrSnuYcIixGfsH3VSiWZ5oTp/Zxe oTAA== X-Gm-Message-State: AOAM532AchZBZQ5BQtAcbq1tVFYXnSIoFFNH1piqSPgUv8QPmNkoDyan qc2gSMcaWD3Ps/OPDPKEwa4B/syu8hDgkqr16WlEnM7KLR4= X-Google-Smtp-Source: ABdhPJz4pFAINIKYm2zlp/unzbOm+8imee9M2IUCqypWtFg7dA2u2hrP1M1fQvSX42c6MSvwKhE3Cw/BZumQmGewllo= X-Received: by 2002:a05:620a:4db:: with SMTP id 27mr23533212qks.431.1608659311289; Tue, 22 Dec 2020 09:48:31 -0800 (PST) MIME-Version: 1.0 References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> <58427333-bcb0-4a4e-bcff-7722da565d43@www.fastmail.com> <2068518088.4578.1607706624615@appsuite-gw1.open-xchange.com> In-Reply-To: <2068518088.4578.1607706624615@appsuite-gw1.open-xchange.com> From: Chris Box Date: Tue, 22 Dec 2020 17:48:20 +0000 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000d067bd05b7112e0b" Archived-At: Subject: Re: [Add] [EXT] Re: Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 17:48:35 -0000 --000000000000d067bd05b7112e0b Content-Type: text/plain; charset="UTF-8" I've waited for the dust to settle on this thread, and would like to attempt to move it towards a conclusion in the new year. Here goes! I think Eric Orth's proposal is wise, i.e. separating "same-party" (1) from similar-behavior (2,3,4). We appear to agree on the need for an expectation of similar behavior, perhaps with tweaks to the wording. What is more extensively debated is same-party or same-entity. To be clear, this is not saying anything about the operator of the network; it's purely referring to the operators of the DNS servers (A and B). Vittorio and Andrew made similar points: a claim for same-entity is particularly useful in the context of GDPR, because it removes the need for the client to have to seek the end user's permission to use a new data processor (and perhaps controller). Of course these are only claims, and servers can lie, but dealing with the lies goes well beyond the scope of this working group, to regulators, courts, the press, etc. So I agree that the ability to say "B is also operated by me" is useful for clients, just as the ability to say "B has the same behavior as me" is useful. They're different concepts, but both have value in different applications. Martin, do you still object to having same-party as an optional component of this use case? Ted, same question, do you still object? I know you also raised the point about what happens when A is already operated by multiple entities (like the Root), or if B is operated by more than one. My answer is that in those cases, the same-party claim should not be made. This will probably be my last post of 2020 so I wish you all a good Christmas break, and hope you have time away from complex technical discussions! Chris On Fri, 11 Dec 2020 at 17:10, Vittorio Bertola wrote: > > > > Il 11/12/2020 11:04 Martin Thomson ha scritto: > > > > > > On Fri, Dec 11, 2020, at 21:01, Vittorio Bertola wrote: > > > If I may provide another perspective, I think that the requirements > for > > > non-experimental deployment models will be significantly shaped by the > > > legal constraints. Thus, same-entity is likely to be a deployment > > > requirement for those that want to do automatic upgrades in countries > > > with strict privacy laws, as it avoids the problem of how to legally > > > add one more entity into the personal data loop without having to ask > > > anything to the user. > > > > This seems reasonable. What expectations do you have regarding where > the responsibility for compliance would lie in the case where a network > operator provides a reference? Or, where the DNS resolver provides a > reference? Would the client share responsibility? > > This is definitely a question for a lawyer :-) In GDPR terms, I would say > that the DNS client is at least a "joint controller" of the user's DNS > queries, no matter who tells them what. But if you go down that path, you > might conclude that the client will always have to ask for the user's > informed consent whenever a new server is contacted, and you end up with > the DNS version of cookie popups. As an exception, the resolver of the > user's Internet access provider might be safe, as the user consents to > share data with it when they sign a contract for Internet access. But > again, this is a question for a lawyer. > > > I ask because if the client can't authenticate the claim, it might not > be reasonable to have it assume responsibility in this case. It might be > that best effort (check that the IP matches) is acceptable though. > > > > (It might be that this comes down to: wait and see, then ask a lawyer, > that's OK too, but it doesn't give us much to base design decisions on.) > > This looks like a bit of a problem in the IETF's process: standards seem > to be designed without having ascertained the non-technical requirements. > Even if we wanted to do that, however, how to do that is not immediate. > > -- > Vittorio Bertola | Head of Policy & Innovation, Open-Xchange > vittorio.bertola@open-xchange.com > Office @ Via Treviso 12, 10144 Torino, Italy > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000d067bd05b7112e0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've waited for the dust to settle on this thread, and= would like to attempt to move it towards a conclusion in the new year. Her= e goes!

I think Eric Orth's proposal is wise, i.e. separati= ng "same-party" (1) from similar-behavior (2,3,4). We appear to a= gree on the need for an expectation of similar behavior, perhaps with tweak= s to the wording. What is more extensively debated is same-party or same-en= tity. To be clear, this is not saying anything about the operator of the ne= twork; it's purely referring to the operators of the DNS servers (A and= B).

Vittorio and Andrew made similar points: = a claim for same-entity is particularly useful in the context of GDPR, beca= use it removes the need for the client to have to seek the end user's p= ermission to use a new data processor (and perhaps controller). Of course t= hese are only claims, and servers can lie, but dealing with the lies goes w= ell beyond the scope of this working group, to regulators, courts, the pres= s, etc.

So I agree that the ability to say "B= is also operated by me" is useful for clients, just as the ability to= say "B has the same behavior as me" is useful. They're diffe= rent concepts, but both have value in different applications.
Martin, do you still object to having same-party as an optional= component of this use case?

Ted, same question, d= o you still object? I know you also raised the point about what happens whe= n A is already operated by multiple entities (like the Root), or if B is op= erated by more than one. My answer is that in those cases, the same-party c= laim should not be made.

This will prob= ably be my last post of 2020 so I wish you all a good Christmas break, and = hope you have time away from complex technical discussions!

<= /div>
Chris


On Fri, 11 Dec 2020 at 17:10, Vittorio = Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org> wrote:


> Il 11/12/2020 11:04 Martin Thomson <mt@lowentropy.net> ha scritto:
>
>=C2=A0
> On Fri, Dec 11, 2020, at 21:01, Vittorio Bertola wrote:
> > If I may provide another perspective, I think that the requiremen= ts for
> > non-experimental deployment models will be significantly shaped b= y the
> > legal constraints. Thus, same-entity is likely to be a deployment=
> > requirement for those that want to do automatic upgrades in count= ries
> > with strict privacy laws, as it avoids the problem of how to lega= lly
> > add one more entity into the personal data loop without having to= ask
> > anything to the user.
>
> This seems reasonable.=C2=A0 What expectations do you have regarding w= here the responsibility for compliance would lie in the case where a networ= k operator provides a reference?=C2=A0 Or, where the DNS resolver provides = a reference?=C2=A0 Would the client share responsibility?

This is definitely a question for a lawyer :-) In GDPR terms, I would say t= hat the DNS client is at least a "joint controller" of the user&#= 39;s DNS queries, no matter who tells them what. But if you go down that pa= th, you might conclude that the client will always have to ask for the user= 's informed consent whenever a new server is contacted, and you end up = with the DNS version of cookie popups. As an exception, the resolver of the= user's Internet access provider might be safe, as the user consents to= share data with it when they sign a contract for Internet access. But agai= n, this is a question for a lawyer.

> I ask because if the client can't authenticate the claim, it might= not be reasonable to have it assume responsibility in this case.=C2=A0 It = might be that best effort (check that the IP matches) is acceptable though.=
>
> (It might be that this comes down to: wait and see, then ask a lawyer,= that's OK too, but it doesn't give us much to base design decision= s on.)

This looks like a bit of a problem in the IETF's process: standards see= m to be designed without having ascertained the non-technical requirements.= Even if we wanted to do that, however, how to do that is not immediate.
--
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vitt= orio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000d067bd05b7112e0b-- From nobody Tue Dec 22 13:29:57 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A473A12B5 for ; Tue, 22 Dec 2020 13:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es4SxYKKzRQc for ; Tue, 22 Dec 2020 13:29:53 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CE13A0E9D for ; Tue, 22 Dec 2020 13:29:53 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id x20so35222449lfe.12 for ; Tue, 22 Dec 2020 13:29:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1PpugKfkNP5TeLz0uuM3qAAgAj7OUmZqYl0BsZjqAV0=; b=LOpJftuKR5wHjy4p9mwMQQNw593ZZfEegqC53J6j2M+ZwFb4i7pCwFNVRxDpRRpMnm 0/M2exI7eC0A1GHs6Xrh2APLjX+QwzigePvzTezipNhhZvZoS7/PMUUy5brjrBhLuplj Jvzlj1V6T6kwPKf7kN93rDMAEoo3zd5AMPkIAu0y817dg7uEfcalg0Vx+8k0W+r/9h6/ JduLgBIo7HW4BIodcyy+EgO6m4sYljzYFNAc5H3o7nSGA0iTPBzfaicbgTdtHyD5eKev PxBDvqOawmx4jyY4Bc3rcSdakc9MjfC9VeLtO3Yeh3W75CK6SxA4JYayYAAFuI+suVU3 5FaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1PpugKfkNP5TeLz0uuM3qAAgAj7OUmZqYl0BsZjqAV0=; b=LhXEs9r8m/IhPfJObR+BgcPvFim+dBrRcb+R6/OoQrM0gHUkSumI4lacBAUE29qJyR /o7hoL3XF61UT4z3ruY+53/myNs8V11jPYqTZoxXxc0ogTAoeNe+z/IS+zCcg3XnfRxj zlPXc+ERPkvQLM6+My5FY7P95sokUU1GwwfMEgi/Ipir6UgGaatwBR8vGhsZTonQmQkj d34GoKO6sFQAvN6Df3FeSF/P3ZBdXIYZkhfTwO6RN2qoz/eEKwiHPcnBnuZzgCNy79yX qQVQ/s1wX13GZU0A5hlDUeH6VnTK/eHjpiLDx0D9S5D8Kg0umHZZOeQf12lFx2sCf9lb bU1A== X-Gm-Message-State: AOAM532IrrHjTnNpuAg1y9K8ikJDG5w8YByHivxvCaewQ5MXElLC+LnH oJCm2+Wrs7OUuHonN+cyXu2jYMDV5CN3pperVPQLgQ== X-Google-Smtp-Source: ABdhPJwF+Mjqasah9eihEHF88uS8Ej7bcAlTlnd4yp5vRT2P9KKlw/+jL34aIkDY2vEjjZ7SH9U/2Q+veYXS59QnTb0= X-Received: by 2002:a05:6512:3051:: with SMTP id b17mr7189494lfb.16.1608672591088; Tue, 22 Dec 2020 13:29:51 -0800 (PST) MIME-Version: 1.0 References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> <58427333-bcb0-4a4e-bcff-7722da565d43@www.fastmail.com> <2068518088.4578.1607706624615@appsuite-gw1.open-xchange.com> In-Reply-To: From: Eric Rescorla Date: Tue, 22 Dec 2020 13:29:14 -0800 Message-ID: To: Chris Box Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000005a28e805b71446f6" Archived-At: Subject: Re: [Add] [EXT] Re: Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 21:29:56 -0000 --0000000000005a28e805b71446f6 Content-Type: text/plain; charset="UTF-8" I actually think we should just abandon the use of equivalence. As I understand it, the purpose of this general line of work is for the network to communicate to clients "I'd like you to use this DoE server". At that point, the client can then either choose to use that server or not. >From the perspective of requirements, then, I think the relevant question is what other information the client might be interested in having in order to make the decision as to whether to use that server [0]. For instance, the network might represent: 1. This resolver will give more or less the same answers as the Do53 resolver. 2. This resolver is operated by the same people as the Do53 resolver. However, I don't think the right way to address this is to say that you can only advertise a new resolver if you meet certain criteria. Rather, the way to address these issues is to have an extensible protocol which allows the network to make a set of such assertions that are potentially of interest to the client. This of course brings us to the question then becomes, "what assertions might the client be interested in consuming", which is, I imagine, different for different clients. Of course, at this point we are writing requirements text, so I think we should stop saying anything about equivalent and instead just talk about "recommended" as you do in S 3 of your draft. Specifically, I would say something like: * Discovery MUST provide a local network the ability to announce to clients a set of, or absence of, recommended resolvers. * Discovery MUST provide extensible functionality to announce other properties of recommended resolvers. One might imagine having the requirements document also specify an initial set of properties for this second bullet (e.g., "recommended resolver gives similar answers", "recommended resolver is operated the same entity") but as it's extensible it's probably just easiest to defer that to protocol definition. -Ekr [0] It's worth noting that for Do53, pretty much all you get is "hey, over here". On Tue, Dec 22, 2020 at 9:48 AM Chris Box wrote: > I've waited for the dust to settle on this thread, and would like to > attempt to move it towards a conclusion in the new year. Here goes! > > I think Eric Orth's proposal is wise, i.e. separating "same-party" (1) > from similar-behavior (2,3,4). We appear to agree on the need for an > expectation of similar behavior, perhaps with tweaks to the wording. What > is more extensively debated is same-party or same-entity. To be clear, this > is not saying anything about the operator of the network; it's purely > referring to the operators of the DNS servers (A and B). > > Vittorio and Andrew made similar points: a claim for same-entity is > particularly useful in the context of GDPR, because it removes the need for > the client to have to seek the end user's permission to use a new data > processor (and perhaps controller). Of course these are only claims, and > servers can lie, but dealing with the lies goes well beyond the scope of > this working group, to regulators, courts, the press, etc. > > So I agree that the ability to say "B is also operated by me" is useful > for clients, just as the ability to say "B has the same behavior as me" is > useful. They're different concepts, but both have value in different > applications. > > Martin, do you still object to having same-party as an optional component > of this use case? > > Ted, same question, do you still object? I know you also raised the point > about what happens when A is already operated by multiple entities (like > the Root), or if B is operated by more than one. My answer is that in those > cases, the same-party claim should not be made. > > This will probably be my last post of 2020 so I wish you all a good > Christmas break, and hope you have time away from complex technical > discussions! > > Chris > > > On Fri, 11 Dec 2020 at 17:10, Vittorio Bertola 40open-xchange.com@dmarc.ietf.org> wrote: > >> >> >> > Il 11/12/2020 11:04 Martin Thomson ha scritto: >> > >> > >> > On Fri, Dec 11, 2020, at 21:01, Vittorio Bertola wrote: >> > > If I may provide another perspective, I think that the requirements >> for >> > > non-experimental deployment models will be significantly shaped by >> the >> > > legal constraints. Thus, same-entity is likely to be a deployment >> > > requirement for those that want to do automatic upgrades in countries >> > > with strict privacy laws, as it avoids the problem of how to legally >> > > add one more entity into the personal data loop without having to ask >> > > anything to the user. >> > >> > This seems reasonable. What expectations do you have regarding where >> the responsibility for compliance would lie in the case where a network >> operator provides a reference? Or, where the DNS resolver provides a >> reference? Would the client share responsibility? >> >> This is definitely a question for a lawyer :-) In GDPR terms, I would say >> that the DNS client is at least a "joint controller" of the user's DNS >> queries, no matter who tells them what. But if you go down that path, you >> might conclude that the client will always have to ask for the user's >> informed consent whenever a new server is contacted, and you end up with >> the DNS version of cookie popups. As an exception, the resolver of the >> user's Internet access provider might be safe, as the user consents to >> share data with it when they sign a contract for Internet access. But >> again, this is a question for a lawyer. >> >> > I ask because if the client can't authenticate the claim, it might not >> be reasonable to have it assume responsibility in this case. It might be >> that best effort (check that the IP matches) is acceptable though. >> > >> > (It might be that this comes down to: wait and see, then ask a lawyer, >> that's OK too, but it doesn't give us much to base design decisions on.) >> >> This looks like a bit of a problem in the IETF's process: standards seem >> to be designed without having ascertained the non-technical requirements. >> Even if we wanted to do that, however, how to do that is not immediate. >> >> -- >> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange >> vittorio.bertola@open-xchange.com >> Office @ Via Treviso 12, 10144 Torino, Italy >> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000005a28e805b71446f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I actually think we should just abandon the use of equival= ence.

As I understand it, the purpose of this general line of work i= s for
the network to communicate to clients "I'd like you to us= e this DoE
server". At that point, the client can then either choos= e to use that
server or not.

From the perspective of requirements= , then, I think the relevant
question is what other information the clie= nt might be interested in
having in order to make the decision as to whe= ther to use that server
[0]. For instance, the network might represent:<= br>
1. This resolver will give more or less the same answers as the
= =C2=A0 =C2=A0Do53 resolver.
2. This resolver is operated by the same peo= ple as the Do53 resolver.

However, I don't think the right way t= o address this is to say that
you can only advertise a new resolver if y= ou meet certain criteria.
Rather, the way to address these issues is to = have an extensible
protocol which allows the network to make a set of su= ch assertions
that are potentially of interest to the client.

Thi= s of course brings us to the question then becomes, "what
assertion= s might the client be interested in consuming", which is, I
imagine= , different for different clients.

Of course, at this point we are w= riting requirements text,
so I think we should stop saying anything abou= t equivalent
and instead just talk about "recommended" as you = do in S 3
of your draft. Specifically, I would say something like:
* Discovery MUST provide a local network the ability to announce to
= =C2=A0 clients a set of, or absence of, recommended resolvers.

* Dis= covery MUST provide extensible functionality to announce other
=C2=A0 pr= operties of recommended resolvers.

One might imagine having the requ= irements document also specify
an initial set of properties for this sec= ond bullet (e.g.,
"recommended resolver gives similar answers"= , "recommended resolver
is operated the same entity") but as i= t's
extensible it's probably just easiest to defer that to proto= col
definition.

-Ekr

[0] It's worth noting that for Do= 53, pretty much all you get is "hey,
over here".

<= /div>

On Tue, Dec 22, 2020 at 9:48 AM Chris Box <chris.box.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
I've = waited for the dust to settle on this thread, and would like to attempt to = move it towards a conclusion in the new year. Here goes!

I thin= k Eric Orth's proposal is wise, i.e. separating "same-party" = (1) from similar-behavior (2,3,4). We appear to agree on the need for an ex= pectation of similar behavior, perhaps with tweaks to the wording. What is = more extensively debated is same-party or same-entity. To be clear, this is= not saying anything about the operator of the network; it's purely ref= erring to the operators of the DNS servers (A and B).

Vittorio and Andrew made similar points: a claim for same-entity is= particularly useful in the context of GDPR, because it removes the need fo= r the client to have to seek the end user's permission to use a new dat= a processor (and perhaps controller). Of course these are only claims, and = servers can lie, but dealing with the lies goes well beyond the scope of th= is working group, to regulators, courts, the press, etc.

So I agree that the ability to say "B is also operated by me&qu= ot; is useful for clients, just as the ability to say "B has the same = behavior as me" is useful. They're different concepts, but both ha= ve value in different applications.

Martin, do you= still object to having same-party as an optional component of this use cas= e?

Ted, same question, do you still object? I know= you also raised the point about what happens when A is already operated by= multiple entities (like the Root), or if B is operated by more than one. M= y answer is that in those cases, the same-party claim should not be made.

This will probably be my last post of 20= 20 so I wish you all a good Christmas break, and hope you have time away fr= om complex technical discussions!

Chris
=

On Fri, 11 Dec 2020 at 17:10, Vittorio Bertola <vittorio.berto= la=3D40open-xchange.com@dmarc.ietf.org> wrote:


> Il 11/12/2020 11:04 Martin Thomson <mt@lowentropy.net> ha scritto:
>
>=C2=A0
> On Fri, Dec 11, 2020, at 21:01, Vittorio Bertola wrote:
> > If I may provide another perspective, I think that the requiremen= ts for
> > non-experimental deployment models will be significantly shaped b= y the
> > legal constraints. Thus, same-entity is likely to be a deployment=
> > requirement for those that want to do automatic upgrades in count= ries
> > with strict privacy laws, as it avoids the problem of how to lega= lly
> > add one more entity into the personal data loop without having to= ask
> > anything to the user.
>
> This seems reasonable.=C2=A0 What expectations do you have regarding w= here the responsibility for compliance would lie in the case where a networ= k operator provides a reference?=C2=A0 Or, where the DNS resolver provides = a reference?=C2=A0 Would the client share responsibility?

This is definitely a question for a lawyer :-) In GDPR terms, I would say t= hat the DNS client is at least a "joint controller" of the user&#= 39;s DNS queries, no matter who tells them what. But if you go down that pa= th, you might conclude that the client will always have to ask for the user= 's informed consent whenever a new server is contacted, and you end up = with the DNS version of cookie popups. As an exception, the resolver of the= user's Internet access provider might be safe, as the user consents to= share data with it when they sign a contract for Internet access. But agai= n, this is a question for a lawyer.

> I ask because if the client can't authenticate the claim, it might= not be reasonable to have it assume responsibility in this case.=C2=A0 It = might be that best effort (check that the IP matches) is acceptable though.=
>
> (It might be that this comes down to: wait and see, then ask a lawyer,= that's OK too, but it doesn't give us much to base design decision= s on.)

This looks like a bit of a problem in the IETF's process: standards see= m to be designed without having ascertained the non-technical requirements.= Even if we wanted to do that, however, how to do that is not immediate.
--
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vitt= orio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000005a28e805b71446f6-- From nobody Tue Dec 22 13:56:44 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B303A12DC for ; Tue, 22 Dec 2020 13:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-xTP9Xuqfs2 for ; Tue, 22 Dec 2020 13:56:40 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9988A3A12DA for ; Tue, 22 Dec 2020 13:56:39 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id s26so35379155lfc.8 for ; Tue, 22 Dec 2020 13:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nChe+hmftWsRR9XtfdrYunhW8c5/Bf61Nj/9kDbdQg0=; b=s4+xUiuwRVK/HEmJwLA/5F7PQT3ubFJ0icwGFZ/B+jUOLlaS93PuwuS9psiHALTkig 1IlmzBFtixpJMtwp+pyY8OU7Yd5t8ik1cxAymqx1xEFYqa4JxUaIaF0qttXFhhh2Pk8v KdmKFGrY2zdimr6enze5tgV18J4QVxkqdvIuG2Vpt4cmK9FC/3il2mMYVFXx3cov/11a RE0b8v9einqhzgbs78fiE2m3yRShZ6hGfOjrVTHvdLp7u/gy7sfa4zQSKXnl3VlQz8NO NXgmtObxUycquSmyQYdTqxwqURP/JM92Zm5jeLOxdlQZXldiqn6Qq+PapH30sckS/fjl 1JcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nChe+hmftWsRR9XtfdrYunhW8c5/Bf61Nj/9kDbdQg0=; b=S2bqPVUdraSDEdQFIalDB4zx3KsBzK0MIxSDBfhrKSTywFOQX2yV0GAxB8CNGhYRe1 9M6Z1EC/MATPnL2yTIQadnHZojjtSWVfFPtj6kYLYgrNp0YexSuGguvxHa+zvn/9CbWd IfCJ8zJW7HkA5S15+B8yaMe1PiPC5Wybu5APv+hGcO+km+dOPDTCpMMamYcw/Yf+TeoL FwrXot9xuKVg9RQDwum/Bjb7hbqZjd3bNwDTT8IQMhj7Q1J8Yh+8+fTJ75xU0nzhtMVO nb7lEbpMNHJShjeIriYycmt78Q6gSGMzga6+tWeTyvC+QqgRtB0YyaL/vn0Fv/I/dbeK 1anw== X-Gm-Message-State: AOAM530vdGGq+YAR8BKjysTbYskjXe5QmOZ4FuTXCCYPPfqDZTpKyRwR YtszpWvjWxBO6qxbA2K0m21CaBKllKE0nyKyJsLfbw== X-Google-Smtp-Source: ABdhPJywtQcdqndB8f1RAnfjZpA9XCXkPYWj8UDjV5I1gpxMo86fAxE77NPVFCpxUVXLLBpRWPKyhvZalpJ2eNyxCfw= X-Received: by 2002:a2e:b88e:: with SMTP id r14mr10225911ljp.254.1608674196967; Tue, 22 Dec 2020 13:56:36 -0800 (PST) MIME-Version: 1.0 References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> <58427333-bcb0-4a4e-bcff-7722da565d43@www.fastmail.com> <2068518088.4578.1607706624615@appsuite-gw1.open-xchange.com> In-Reply-To: From: Eric Orth Date: Tue, 22 Dec 2020 16:56:26 -0500 Message-ID: To: Eric Rescorla Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000012395f05b714a6b3" Archived-At: Subject: Re: [Add] [EXT] Re: Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 21:56:42 -0000 --00000000000012395f05b714a6b3 Content-Type: text/plain; charset="UTF-8" While I agree that declaring "equivalence" or anything like that to be an absolute requirement for advertising providers is probably too far, I think these (equivalence, same-party, etc) are signals that clients will want to use often enough in decision making that it seems very beneficial to come up with common definitions of the concepts in the requirements document. It can then be left to the protocol to define how/if the signal is communicated (or make protocol-specific equivalence/etc requirements and thus signal equivalence/etc by pure presence of the recommended provider iff it makes sense for the usecases of the specific protocol). On Tue, Dec 22, 2020 at 4:30 PM Eric Rescorla wrote: > I actually think we should just abandon the use of equivalence. > > As I understand it, the purpose of this general line of work is for > the network to communicate to clients "I'd like you to use this DoE > server". At that point, the client can then either choose to use that > server or not. > > From the perspective of requirements, then, I think the relevant > question is what other information the client might be interested in > having in order to make the decision as to whether to use that server > [0]. For instance, the network might represent: > > 1. This resolver will give more or less the same answers as the > Do53 resolver. > 2. This resolver is operated by the same people as the Do53 resolver. > > However, I don't think the right way to address this is to say that > you can only advertise a new resolver if you meet certain criteria. > Rather, the way to address these issues is to have an extensible > protocol which allows the network to make a set of such assertions > that are potentially of interest to the client. > > This of course brings us to the question then becomes, "what > assertions might the client be interested in consuming", which is, I > imagine, different for different clients. > > Of course, at this point we are writing requirements text, > so I think we should stop saying anything about equivalent > and instead just talk about "recommended" as you do in S 3 > of your draft. Specifically, I would say something like: > > * Discovery MUST provide a local network the ability to announce to > clients a set of, or absence of, recommended resolvers. > > * Discovery MUST provide extensible functionality to announce other > properties of recommended resolvers. > > One might imagine having the requirements document also specify > an initial set of properties for this second bullet (e.g., > "recommended resolver gives similar answers", "recommended resolver > is operated the same entity") but as it's > extensible it's probably just easiest to defer that to protocol > definition. > > -Ekr > > [0] It's worth noting that for Do53, pretty much all you get is "hey, > over here". > > > On Tue, Dec 22, 2020 at 9:48 AM Chris Box > wrote: > >> I've waited for the dust to settle on this thread, and would like to >> attempt to move it towards a conclusion in the new year. Here goes! >> >> I think Eric Orth's proposal is wise, i.e. separating "same-party" (1) >> from similar-behavior (2,3,4). We appear to agree on the need for an >> expectation of similar behavior, perhaps with tweaks to the wording. What >> is more extensively debated is same-party or same-entity. To be clear, this >> is not saying anything about the operator of the network; it's purely >> referring to the operators of the DNS servers (A and B). >> >> Vittorio and Andrew made similar points: a claim for same-entity is >> particularly useful in the context of GDPR, because it removes the need for >> the client to have to seek the end user's permission to use a new data >> processor (and perhaps controller). Of course these are only claims, and >> servers can lie, but dealing with the lies goes well beyond the scope of >> this working group, to regulators, courts, the press, etc. >> >> So I agree that the ability to say "B is also operated by me" is useful >> for clients, just as the ability to say "B has the same behavior as me" is >> useful. They're different concepts, but both have value in different >> applications. >> >> Martin, do you still object to having same-party as an optional component >> of this use case? >> >> Ted, same question, do you still object? I know you also raised the point >> about what happens when A is already operated by multiple entities (like >> the Root), or if B is operated by more than one. My answer is that in those >> cases, the same-party claim should not be made. >> >> This will probably be my last post of 2020 so I wish you all a good >> Christmas break, and hope you have time away from complex technical >> discussions! >> >> Chris >> >> >> On Fri, 11 Dec 2020 at 17:10, Vittorio Bertola > 40open-xchange.com@dmarc.ietf.org> wrote: >> >>> >>> >>> > Il 11/12/2020 11:04 Martin Thomson ha scritto: >>> > >>> > >>> > On Fri, Dec 11, 2020, at 21:01, Vittorio Bertola wrote: >>> > > If I may provide another perspective, I think that the requirements >>> for >>> > > non-experimental deployment models will be significantly shaped by >>> the >>> > > legal constraints. Thus, same-entity is likely to be a deployment >>> > > requirement for those that want to do automatic upgrades in >>> countries >>> > > with strict privacy laws, as it avoids the problem of how to legally >>> > > add one more entity into the personal data loop without having to >>> ask >>> > > anything to the user. >>> > >>> > This seems reasonable. What expectations do you have regarding where >>> the responsibility for compliance would lie in the case where a network >>> operator provides a reference? Or, where the DNS resolver provides a >>> reference? Would the client share responsibility? >>> >>> This is definitely a question for a lawyer :-) In GDPR terms, I would >>> say that the DNS client is at least a "joint controller" of the user's DNS >>> queries, no matter who tells them what. But if you go down that path, you >>> might conclude that the client will always have to ask for the user's >>> informed consent whenever a new server is contacted, and you end up with >>> the DNS version of cookie popups. As an exception, the resolver of the >>> user's Internet access provider might be safe, as the user consents to >>> share data with it when they sign a contract for Internet access. But >>> again, this is a question for a lawyer. >>> >>> > I ask because if the client can't authenticate the claim, it might not >>> be reasonable to have it assume responsibility in this case. It might be >>> that best effort (check that the IP matches) is acceptable though. >>> > >>> > (It might be that this comes down to: wait and see, then ask a lawyer, >>> that's OK too, but it doesn't give us much to base design decisions on.) >>> >>> This looks like a bit of a problem in the IETF's process: standards seem >>> to be designed without having ascertained the non-technical requirements. >>> Even if we wanted to do that, however, how to do that is not immediate. >>> >>> -- >>> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange >>> vittorio.bertola@open-xchange.com >>> Office @ Via Treviso 12, 10144 Torino, Italy >>> >>> -- >>> Add mailing list >>> Add@ietf.org >>> https://www.ietf.org/mailman/listinfo/add >>> >> -- >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add >> > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000012395f05b714a6b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I agree that declaring "equivalence" or an= ything like that to be an absolute requirement for advertising providers is= probably too far, I think these (equivalence, same-party, etc) are signals= that clients will want to use often enough in decision making that it seem= s very beneficial to come up with common definitions of the concepts in the= requirements document.=C2=A0 It can then be left to the protocol to define= how/if the signal is communicated (or make protocol-specific equivalence/e= tc requirements and thus signal equivalence/etc by pure presence=C2=A0of th= e recommended provider iff it makes sense for the usecases of the specific = protocol).

On Tue, Dec 22, 2020 at 4:30 PM Eric Rescorla <ekr@rtfm.com> wrote:
I actually think we should ju= st abandon the use of equivalence.

As I understand it, the purpose o= f this general line of work is for
the network to communicate to clients= "I'd like you to use this DoE
server". At that point, the= client can then either choose to use that
server or not.

From th= e perspective of requirements, then, I think the relevant
question is wh= at other information the client might be interested in
having in order t= o make the decision as to whether to use that server
[0]. For instance, = the network might represent:

1. This resolver will give more or less= the same answers as the
=C2=A0 =C2=A0Do53 resolver.
2. This resolver= is operated by the same people as the Do53 resolver.

However, I don= 't think the right way to address this is to say that
you can only a= dvertise a new resolver if you meet certain criteria.
Rather, the way to= address these issues is to have an extensible
protocol which allows the= network to make a set of such assertions
that are potentially of intere= st to the client.

This of course brings us to the question then beco= mes, "what
assertions might the client be interested in consuming&q= uot;, which is, I
imagine, different for different clients.

Of co= urse, at this point we are writing requirements text,
so I think we shou= ld stop saying anything about equivalent
and instead just talk about &qu= ot;recommended" as you do in S 3
of your draft. Specifically, I wou= ld say something like:

* Discovery MUST provide a local network the = ability to announce to
=C2=A0 clients a set of, or absence of, recommend= ed resolvers.

* Discovery MUST provide extensible functionality to a= nnounce other
=C2=A0 properties of recommended resolvers.

One mig= ht imagine having the requirements document also specify
an initial set = of properties for this second bullet (e.g.,
"recommended resolver g= ives similar answers", "recommended resolver
is operated the s= ame entity") but as it's
extensible it's probably just easi= est to defer that to protocol
definition.

-Ekr

[0] It'= s worth noting that for Do53, pretty much all you get is "hey,
over= here".


On Tue, Dec 22, 2020 at 9:48 AM Chris B= ox <chris.= box.ietf@gmail.com> wrote:
I've waited for the dust to settle o= n this thread, and would like to attempt to move it towards a conclusion in= the new year. Here goes!

I think Eric Orth's proposal is w= ise, i.e. separating "same-party" (1) from similar-behavior (2,3,= 4). We appear to agree on the need for an expectation of similar behavior, = perhaps with tweaks to the wording. What is more extensively debated is sam= e-party or same-entity. To be clear, this is not saying anything about the = operator of the network; it's purely referring to the operators of the = DNS servers (A and B).

Vittorio and Andrew mad= e similar points: a claim for same-entity is particularly useful in the con= text of GDPR, because it removes the need for the client to have to seek th= e end user's permission to use a new data processor (and perhaps contro= ller). Of course these are only claims, and servers can lie, but dealing wi= th the lies goes well beyond the scope of this working group, to regulators= , courts, the press, etc.

So I agree that the abil= ity to say "B is also operated by me" is useful for clients, just= as the ability to say "B has the same behavior as me" is useful.= They're different concepts, but both have value in different applicati= ons.

Martin, do you still object to having same-pa= rty as an optional component of this use case?

Ted= , same question, do you still object? I know you also raised the point abou= t what happens when A is already operated by multiple entities (like the Ro= ot), or if B is operated by more than one. My answer is that in those cases= , the same-party claim should not be made.

<= div>This will probably be my last post of 2020 so I wish you all a good Chr= istmas break, and hope you have time away from complex technical discussion= s!

Chris


On Fri, 11 Dec 2020 = at 17:10, Vittorio Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf= .org> wrote:


> Il 11/12/2020 11:04 Martin Thomson <mt@lowentropy.net> ha scritto:
>
>=C2=A0
> On Fri, Dec 11, 2020, at 21:01, Vittorio Bertola wrote:
> > If I may provide another perspective, I think that the requiremen= ts for
> > non-experimental deployment models will be significantly shaped b= y the
> > legal constraints. Thus, same-entity is likely to be a deployment=
> > requirement for those that want to do automatic upgrades in count= ries
> > with strict privacy laws, as it avoids the problem of how to lega= lly
> > add one more entity into the personal data loop without having to= ask
> > anything to the user.
>
> This seems reasonable.=C2=A0 What expectations do you have regarding w= here the responsibility for compliance would lie in the case where a networ= k operator provides a reference?=C2=A0 Or, where the DNS resolver provides = a reference?=C2=A0 Would the client share responsibility?

This is definitely a question for a lawyer :-) In GDPR terms, I would say t= hat the DNS client is at least a "joint controller" of the user&#= 39;s DNS queries, no matter who tells them what. But if you go down that pa= th, you might conclude that the client will always have to ask for the user= 's informed consent whenever a new server is contacted, and you end up = with the DNS version of cookie popups. As an exception, the resolver of the= user's Internet access provider might be safe, as the user consents to= share data with it when they sign a contract for Internet access. But agai= n, this is a question for a lawyer.

> I ask because if the client can't authenticate the claim, it might= not be reasonable to have it assume responsibility in this case.=C2=A0 It = might be that best effort (check that the IP matches) is acceptable though.=
>
> (It might be that this comes down to: wait and see, then ask a lawyer,= that's OK too, but it doesn't give us much to base design decision= s on.)

This looks like a bit of a problem in the IETF's process: standards see= m to be designed without having ascertained the non-technical requirements.= Even if we wanted to do that, however, how to do that is not immediate.
--
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vitt= orio.bertola@open-xchange.com
Office @ Via Treviso 12, 10144 Torino, Italy

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000012395f05b714a6b3-- From nobody Tue Dec 22 14:03:17 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D653A1295 for ; Tue, 22 Dec 2020 14:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TPgw1DB3; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=FTs3hofq Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAFddZvbR5zu for ; Tue, 22 Dec 2020 14:03:13 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8107C3A0F02 for ; Tue, 22 Dec 2020 14:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27878; q=dns/txt; s=iport; t=1608674593; x=1609884193; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=HL5VSZRjm3xZfvhO/jJMVqGyqN+9vxOU5PfWiW1QTgY=; b=TPgw1DB3c2l9HNHt7Kwe1OBUfgaPk/Coe9ZsPl2rclGRPWrsh7hfCSSA PgklXFQw9WWuM3FoocRQIS/J+WM/JDaSD8UYOCGPDQsbhfsaSoUHRzkg+ DEzpiLAcppuRZ1bIJBh3WnRQ+smKocTUITuNznvp6Tfp5zisl8Usq0fEA Q=; X-Files: smime.p7s : 3980 X-IPAS-Result: =?us-ascii?q?A0DfAgCWa+JfkJhdJa1iHAEBAQEBAQcBARIBAQQEAQGCD?= =?us-ascii?q?4EjLyMufS0uLy6EP4NIA41aA4oaigCEcoJTA1QEBAMBAQEKAwEBGAEKCgIEA?= =?us-ascii?q?QGESgKBcgIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQGGOAyFcwEBA?= =?us-ascii?q?QMBAQEQEQoTAQEsCwEECwIBCBEEAQEBJwMCAgIfBgsUCQgCBAENBQgGFIMEA?= =?us-ascii?q?YF+VwMOEQ8BDqUzAoE8iBEFU3aBMoMEAQEGhRUNC4IJBwMGN4EBgVOBIoUCh?= =?us-ascii?q?TIIHhuBQT+BEUOCVj6CG0IBAQKBRQkRFRYJgmI0giyBWAEQKDEIBScyBEMQF?= =?us-ascii?q?A4sDSAVBwcQBBAIDQQNQRMFL49Hp1hYCoJ0hF2CaIhYhhmFPqJHlAqOB44vh?= =?us-ascii?q?HoCBAIEBQIOAQEGgW0hLIEtcBU7gmlQFwINjiEag1eFFIVEdAIBNAIGAQkBA?= =?us-ascii?q?QMJfIdtgkQBAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3ASEjntxW6K5KdmVhYeoDolmlycJbV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+Huf5BgvDd9aHtRWJG5oyO4zgOc51JAh?= =?us-ascii?q?kCj8he3wktG9WMBkCzKvn2Jzc7E8JPWB4AnTm7PEFZFdy4awjUpXu/vjIXEw?= =?us-ascii?q?/0cwt4OuqzHZTd3Iy70umo8MjVZANFzDO2fbJ1KkCwqgPc/skbiIdvMOA/0B?= =?us-ascii?q?zM93BJYO9Rg2hvIAGe?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,440,1599523200"; d="p7s'?scan'208,217";a="634391315" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Dec 2020 22:03:12 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0BMM34GH000895 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Dec 2020 22:03:11 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Dec 2020 16:03:06 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Dec 2020 16:03:06 -0600 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 22 Dec 2020 16:03:06 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ILHkwrqzT54R3ayWfkJtgTwSW1y8LhTbtfNzvBrgJO9v2zIKHV33CGpMzLPPYT9Vh1qm4tXXMN98dz2CdQxKvQCr5acVoAQDJI63LA7BFexmDzB646ExE/Du6zAn9muTMUgUncnRKzeAY2mRg2LvBgfYdpo+TXCn1+b5G96t6ATaokPcg5JJB43+6Apu9tQSf09BGsQzUauHeYl0risOn/7TYqr3G/vgBYUph79uYdwCVYC6ZG8kE5N5yE0j452XteqfsY++g1p/lAm+/+PZn8BCb1psoVDlFHk3aRG/g4Y5oGyNsKU40tGLMIPLFUo7q5bJeO73VMgjqP5+3dgLYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RVrtD5UrpJ6h/wEkziKVYVzMMDlKDtbOlxP7MdUFEfI=; b=VudCb6oWBS+y1t+X5u1K7WGvCseNKg11eq0WYNz/ZO+vHUwzTpakFnmko00iN6MsNV61WzIMtWqbeFdtOu9K7oYI9q9wxJn8LyzGL4iIZB5pW259nC4y9nJV5OnoosZG+kEX43AFx6XPlkJUwuDsyO4jDv6UZnrxkrWFO1ThG2ICz11Z6JAK5GzbVGB2S+Xil+eHunrT9mt6iDJwAL+vbTQQ0LIYWH9fjraLEu/nvstCT0CeW5slEj3xskOXROSlBepQV+d48KH1uZctQ0ZS6sEJXJSccgGYtkbPItzn3a4ELE8IV+JnuQxnpb8700b+q+9NTxGJs1C06K7mN1pUcg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RVrtD5UrpJ6h/wEkziKVYVzMMDlKDtbOlxP7MdUFEfI=; b=FTs3hofqdQJ6lJ6aG0+howrQwESnH8kTwcKEoC9FVRBEkKxE7WxiKGmKhE00vP+9tXrdwJVnyvVrXkhJcqQMsIvHMlW/CR8jozXStRM/Clxbt97M7Q0xKRsKJLSEbRw/z/zJs9kV4jWDsLoTIOPEENc2DlQDhaymz7wwKwuDHwQ= Received: from MN2PR11MB4760.namprd11.prod.outlook.com (2603:10b6:208:266::22) by MN2PR11MB4301.namprd11.prod.outlook.com (2603:10b6:208:188::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.29; Tue, 22 Dec 2020 22:03:04 +0000 Received: from MN2PR11MB4760.namprd11.prod.outlook.com ([fe80::195e:17a5:40a:46f0]) by MN2PR11MB4760.namprd11.prod.outlook.com ([fe80::195e:17a5:40a:46f0%7]) with mapi id 15.20.3676.033; Tue, 22 Dec 2020 22:03:04 +0000 From: "Vinny Parla (vparla)" To: Eric Orth , Eric Rescorla CC: ADD Mailing list Thread-Topic: [Add] [EXT] Re: Definition of equivalence Thread-Index: AQHW2Iq2Wt0q8DYmUU2jODiOQjg+caoDoecAgAAHmgCAAADXQA== Date: Tue, 22 Dec 2020 22:03:04 +0000 Message-ID: References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> <58427333-bcb0-4a4e-bcff-7722da565d43@www.fastmail.com> <2068518088.4578.1607706624615@appsuite-gw1.open-xchange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2601:188:c400:bde0:ac5f:6b8c:24ab:63f4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 94a4aa49-b896-4f93-ec61-08d8a6c55b45 x-ms-traffictypediagnostic: MN2PR11MB4301: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:568; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: L4F4dEWtySkKNtjy50yChP/PrSojvReQvbSidJwq6kgjEb3ZfRkAEyCphZYJpVaKD/jMRolDLKY3Y/6rXSq+BLuDFW3ptSSksJEhajPcWRwuAKK7zwh6qEq1ReKV0BvFbKh601gQqN1Al/Xh9WggJIlbubi+Pg39mzXH4yCCxc7EX607Bui3clw94Naq7JF8xIO4LOgOswm+o71M5m+8/YzlrxDcpmhuR0iDq8rz1BdHO6gT5U3lJZuT8dunoXPvrKW4IwqnApbKEVi1TKJqR+thNPydYm7Iz8HNPTeLhMU4HdUg89KGVFyXBQLceKkSgEgC8BF7NfTwclcVLDFjzI0Fn0DNJDxy4xG2BJ5afcp2+n+vyrgB9wuZdHtuOA2TCqZ/c3IBY9mvGsw7NyWykXyYQUERr5t4x6GJwAP07JDGBUtkxArGU2SGlXsQf7hbb1LqeK3jbPyQp3xPwoZWJA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4760.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(376002)(346002)(396003)(366004)(86362001)(53546011)(966005)(55016002)(33656002)(166002)(66446008)(66616009)(83380400001)(4326008)(478600001)(5660300002)(66476007)(64756008)(76116006)(66946007)(66556008)(316002)(2906002)(9686003)(66574015)(8936002)(7696005)(110136005)(52536014)(6506007)(71200400001)(9326002)(99936003)(8676002)(186003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?eFUzZnZTVmJrRE5YcUgrQ3dMMmVnR1RTTzFZMkhDSzdLd1hRQzB2OE10UGU3?= =?utf-8?B?NWFjeGxsdlVJcU9qUmxzemJJM1hIc0REMjhlT1VtN2ZGUVVYb3czWGk5d1Zs?= =?utf-8?B?THNWMWhpdHJxcXozOWxia1dtT0NsZlRUWmJ2RVFqQ3Q4ZjBuYWJ1Y3NON2xp?= =?utf-8?B?TUMvTUw5K09WMnhlejhTZWl5eUtwMjUzQmVOOFZmUDBXNHBubnlLS05Sc0RD?= =?utf-8?B?UUV2ZGMxaDNmbFRkdlZlVVhNeW5EeEJkb2w0NVVoVEFQVWFqdy96RkgyQmwr?= =?utf-8?B?TXNveXlOSHFuMURyaDVPWG9acWYxR292L0dIb25YTitzSUgrSGVZbjBjck1L?= =?utf-8?B?UGFKOEVaSGhKSWpyTXBnRXpsRkpZYUVWM0ZJUDI2SUY4NWJkQUZEcmxramlt?= =?utf-8?B?aEFETUtONXpRMDZvSGNTSlA2Rm9LTFJhemJiN3N4MGtydDc2NGNQQ2w4bXA3?= =?utf-8?B?ZnRXWjlhMHBkVVVCbkU1TlA4NkdZck1LWFNsdDBxU05RemdsZjNKUFlCOTB0?= =?utf-8?B?WlVyMzdWNnB2TXp3U1BWUmUrYTIxVlFvVXhHcnRjWUJuYUQ5d2EwNEpQRFB6?= =?utf-8?B?VFNkU2xRenQ4ejJZZklGektTM3h3Y210TGdEUVY2akdRR25sNTdMSGxLV1Y4?= =?utf-8?B?aGFzVlBmbm5DNEtYMUJFOU1odHdTVFQwTmdOaXM0TE9WZ3FMT3Q5NUI5MkNv?= =?utf-8?B?dHRFTUlid1l0NUxDWjQwdVczWGlzSTVRNWsrejNyalhuajBRK0FhRFRrdk9i?= =?utf-8?B?NVNuYVNRVzZQOWhYcXV3aGg3M0tsZkdkL2UwMllGUVc4NlY5Mjg2dmx4T2VQ?= =?utf-8?B?Z0cvMVU4TVgvVWtuNUtwYnd0aTB0VDd3d2tHbFZlaWJKMDM3aTBzYUhoTHg3?= =?utf-8?B?dEVHMjNmUUp4RlZsZXJhWUdEQnhjeEpCVjVZdDhUYVdVTGxEMGdXVmh3b0l1?= =?utf-8?B?KzFzaE95WHF4ak10YUpXNnBJbVcyc3BXMXhYUGcweXdXdFYxR0dpV2xRRHND?= =?utf-8?B?YVBxaFJnUFJ6Y2VKb1B1K3RDcm9VWXU5aWpSb0lKWkcxVzdrMGdoT1Y5MUYw?= =?utf-8?B?U04yWlN1ODZ5QXFrMk1vaEVQWVZLZE1FODY5U2t0Zmg0d2EwZWl0M3h6ZDIy?= =?utf-8?B?RHpHQTVkY0FMcnBoWnFJQk5lcjZtK1RTc013c1VGendXR2pCWGwzbXlFQjFS?= =?utf-8?B?VmZ0TUlUb3I5dXN3ZTU1STV2TUNVUHZtdFdjWE1IZlc5TnFFamZFM2JnYzFP?= =?utf-8?B?WWhxeVlibnlUOTREMmtZV0lDQ1dKQkpQeVBTNW5NQWFTM2txWUdpQnlMZ1pD?= =?utf-8?B?bDRHcWhjeE02UHF0SUc5UG8vbHQ2WnZLeHF5eWgyNy8xb2JRclR6bHpneXk4?= =?utf-8?Q?RgysjCWqkSQP8wAmwcCKUqv9k0wxB2eM=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_089D_01D6D884.4EEF5A00" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4760.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 94a4aa49-b896-4f93-ec61-08d8a6c55b45 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2020 22:03:04.1568 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2Th3J2EkuHthzDZC2WzbViulsGIfTYqUhoKjJUXxpzsruoegOWIw7MTmGbD0M6kq8heToZC70satq4oB0aHlBg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4301 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Add] [EXT] Re: Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2020 22:03:16 -0000 ------=_NextPart_000_089D_01D6D884.4EEF5A00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_089E_01D6D884.4EEF5A00" ------=_NextPart_001_089E_01D6D884.4EEF5A00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, =20 I take =E2=80=98equivalence=E2=80=99 to mean it will provide the same = capabilities/limitations as Do53 with the additional security offered by = the encryption protocol(s). Nothing more. There is no way to reliably = determine that Do53 and Encrypted-DNS =E2=80=98equivalence=E2=80=99 are = the same entity since there is no way to actually ascertain the = provenance of the original Do53 messages. =20 -Vinny =20 From: Add On Behalf Of Eric Orth Sent: Tuesday, December 22, 2020 4:56 PM To: Eric Rescorla Cc: ADD Mailing list Subject: Re: [Add] [EXT] Re: Definition of equivalence =20 While I agree that declaring "equivalence" or anything like that to be = an absolute requirement for advertising providers is probably too far, I = think these (equivalence, same-party, etc) are signals that clients will = want to use often enough in decision making that it seems very = beneficial to come up with common definitions of the concepts in the = requirements document. It can then be left to the protocol to define = how/if the signal is communicated (or make protocol-specific = equivalence/etc requirements and thus signal equivalence/etc by pure = presence of the recommended provider iff it makes sense for the usecases = of the specific protocol). =20 On Tue, Dec 22, 2020 at 4:30 PM Eric Rescorla > wrote: I actually think we should just abandon the use of equivalence. As I understand it, the purpose of this general line of work is for the network to communicate to clients "I'd like you to use this DoE server". At that point, the client can then either choose to use that server or not. >From the perspective of requirements, then, I think the relevant question is what other information the client might be interested in having in order to make the decision as to whether to use that server [0]. For instance, the network might represent: 1. This resolver will give more or less the same answers as the Do53 resolver. 2. This resolver is operated by the same people as the Do53 resolver. However, I don't think the right way to address this is to say that you can only advertise a new resolver if you meet certain criteria. Rather, the way to address these issues is to have an extensible protocol which allows the network to make a set of such assertions that are potentially of interest to the client. This of course brings us to the question then becomes, "what assertions might the client be interested in consuming", which is, I imagine, different for different clients. Of course, at this point we are writing requirements text, so I think we should stop saying anything about equivalent and instead just talk about "recommended" as you do in S 3 of your draft. Specifically, I would say something like: * Discovery MUST provide a local network the ability to announce to clients a set of, or absence of, recommended resolvers. * Discovery MUST provide extensible functionality to announce other properties of recommended resolvers. One might imagine having the requirements document also specify an initial set of properties for this second bullet (e.g., "recommended resolver gives similar answers", "recommended resolver is operated the same entity") but as it's extensible it's probably just easiest to defer that to protocol definition. -Ekr [0] It's worth noting that for Do53, pretty much all you get is "hey, over here". =20 =20 On Tue, Dec 22, 2020 at 9:48 AM Chris Box > wrote: I've waited for the dust to settle on this thread, and would like to = attempt to move it towards a conclusion in the new year. Here goes! I think Eric Orth's proposal is wise, i.e. separating "same-party" (1) = from similar-behavior (2,3,4). We appear to agree on the need for an = expectation of similar behavior, perhaps with tweaks to the wording. = What is more extensively debated is same-party or same-entity. To be = clear, this is not saying anything about the operator of the network; = it's purely referring to the operators of the DNS servers (A and B). =20 Vittorio and Andrew made similar points: a claim for same-entity is = particularly useful in the context of GDPR, because it removes the need = for the client to have to seek the end user's permission to use a new = data processor (and perhaps controller). Of course these are only = claims, and servers can lie, but dealing with the lies goes well beyond = the scope of this working group, to regulators, courts, the press, etc. =20 So I agree that the ability to say "B is also operated by me" is useful = for clients, just as the ability to say "B has the same behavior as me" = is useful. They're different concepts, but both have value in different = applications. =20 Martin, do you still object to having same-party as an optional = component of this use case? =20 Ted, same question, do you still object? I know you also raised the = point about what happens when A is already operated by multiple entities = (like the Root), or if B is operated by more than one. My answer is that = in those cases, the same-party claim should not be made. =20 This will probably be my last post of 2020 so I wish you all a good = Christmas break, and hope you have time away from complex technical = discussions! =20 Chris =20 =20 On Fri, 11 Dec 2020 at 17:10, Vittorio Bertola = > wrote: > Il 11/12/2020 11:04 Martin Thomson > ha scritto: >=20 > =20 > On Fri, Dec 11, 2020, at 21:01, Vittorio Bertola wrote: > > If I may provide another perspective, I think that the requirements = for=20 > > non-experimental deployment models will be significantly shaped by = the=20 > > legal constraints. Thus, same-entity is likely to be a deployment=20 > > requirement for those that want to do automatic upgrades in = countries=20 > > with strict privacy laws, as it avoids the problem of how to legally = > > add one more entity into the personal data loop without having to = ask=20 > > anything to the user. >=20 > This seems reasonable. What expectations do you have regarding where = the responsibility for compliance would lie in the case where a network = operator provides a reference? Or, where the DNS resolver provides a = reference? Would the client share responsibility? This is definitely a question for a lawyer :-) In GDPR terms, I would = say that the DNS client is at least a "joint controller" of the user's = DNS queries, no matter who tells them what. But if you go down that = path, you might conclude that the client will always have to ask for the = user's informed consent whenever a new server is contacted, and you end = up with the DNS version of cookie popups. As an exception, the resolver = of the user's Internet access provider might be safe, as the user = consents to share data with it when they sign a contract for Internet = access. But again, this is a question for a lawyer. > I ask because if the client can't authenticate the claim, it might not = be reasonable to have it assume responsibility in this case. It might = be that best effort (check that the IP matches) is acceptable though. >=20 > (It might be that this comes down to: wait and see, then ask a lawyer, = that's OK too, but it doesn't give us much to base design decisions on.) This looks like a bit of a problem in the IETF's process: standards seem = to be designed without having ascertained the non-technical = requirements. Even if we wanted to do that, however, how to do that is = not immediate. --=20 Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com = =20 Office @ Via Treviso 12, 10144 Torino, Italy --=20 Add mailing list Add@ietf.org =20 https://www.ietf.org/mailman/listinfo/add --=20 Add mailing list Add@ietf.org =20 https://www.ietf.org/mailman/listinfo/add --=20 Add mailing list Add@ietf.org =20 https://www.ietf.org/mailman/listinfo/add ------=_NextPart_001_089E_01D6D884.4EEF5A00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

 

I take = =E2=80=98equivalence=E2=80=99 to mean it will provide the same = capabilities/limitations as Do53 with the additional security offered by = the encryption protocol(s). Nothing more. =C2=A0There is no way to = reliably determine that Do53 and Encrypted-DNS = =E2=80=98equivalence=E2=80=99 are the same entity since there is no way = to actually ascertain the provenance of the original Do53 = messages.

 

-Vinny

 

From: Add = <add-bounces@ietf.org> On Behalf Of Eric = Orth
Sent: Tuesday, December 22, 2020 4:56 PM
To: = Eric Rescorla <ekr@rtfm.com>
Cc: ADD Mailing list = <add@ietf.org>
Subject: Re: [Add] [EXT] Re: Definition = of equivalence

 

While I = agree that declaring "equivalence" or anything like that to be = an absolute requirement for advertising providers is probably too far, I = think these (equivalence, same-party, etc) are signals that clients will = want to use often enough in decision making that it seems very = beneficial to come up with common definitions of the concepts in the = requirements document.  It can then be left to the protocol to = define how/if the signal is communicated (or make protocol-specific = equivalence/etc requirements and thus signal equivalence/etc by pure = presence of the recommended provider iff it makes sense for the = usecases of the specific protocol).

 

On = Tue, Dec 22, 2020 at 4:30 PM Eric Rescorla <ekr@rtfm.com> = wrote:

I = actually think we should just abandon the use of equivalence.

As = I understand it, the purpose of this general line of work is for
the = network to communicate to clients "I'd like you to use this = DoE
server". At that point, the client can then either choose to = use that
server or not.

From the perspective of requirements, = then, I think the relevant
question is what other information the = client might be interested in
having in order to make the decision as = to whether to use that server
[0]. For instance, the network might = represent:

1. This resolver will give more or less the same = answers as the
   Do53 resolver.
2. This resolver is = operated by the same people as the Do53 resolver.

However, I = don't think the right way to address this is to say that
you can only = advertise a new resolver if you meet certain criteria.
Rather, the = way to address these issues is to have an extensible
protocol which = allows the network to make a set of such assertions
that are = potentially of interest to the client.

This of course brings us = to the question then becomes, "what
assertions might the client = be interested in consuming", which is, I
imagine, different for = different clients.

Of course, at this point we are writing = requirements text,
so I think we should stop saying anything about = equivalent
and instead just talk about "recommended" as you = do in S 3
of your draft. Specifically, I would say something = like:

* Discovery MUST provide a local network the ability to = announce to
  clients a set of, or absence of, recommended = resolvers.

* Discovery MUST provide extensible functionality to = announce other
  properties of recommended resolvers.

One = might imagine having the requirements document also specify
an = initial set of properties for this second bullet = (e.g.,
"recommended resolver gives similar answers", = "recommended resolver
is operated the same entity") but as = it's
extensible it's probably just easiest to defer that to = protocol
definition.

-Ekr

[0] It's worth noting that = for Do53, pretty much all you get is "hey,
over = here".

 

 

On Tue, Dec 22, 2020 at 9:48 AM Chris Box <chris.box.ietf@gmail.com> = wrote:

I've waited for the dust to settle on = this thread, and would like to attempt to move it towards a conclusion = in the new year. Here goes!

I = think Eric Orth's proposal is wise, i.e. separating = "same-party" (1) from similar-behavior (2,3,4). We appear to = agree on the need for an expectation of similar behavior, perhaps with = tweaks to the wording. What is more extensively debated is same-party or = same-entity. To be clear, this is not saying anything about the operator = of the network; it's purely referring to the operators of the DNS = servers (A and B).

 

Vittorio and Andrew made similar points: a claim for = same-entity is particularly useful in the context of GDPR, because it = removes the need for the client to have to seek the end user's = permission to use a new data processor (and perhaps controller). Of = course these are only claims, and servers can lie, but dealing with the = lies goes well beyond the scope of this working group, to regulators, = courts, the press, etc.

 

So I agree that the ability to say "B is also = operated by me" is useful for clients, just as the ability to say = "B has the same behavior as me" is useful. They're different = concepts, but both have value in different = applications.

 

Martin, do you still object to having same-party as an = optional component of this use case?

 

Ted, same question, do you still object? I know you = also raised the point about what happens when A is already operated by = multiple entities (like the Root), or if B is operated by more than one. = My answer is that in those cases, the same-party claim should not be = made.

 

This will probably be my last post of 2020 so I wish = you all a good Christmas break, and hope you have time away from complex = technical discussions!

 

Chris

 

 

On = Fri, 11 Dec 2020 at 17:10, Vittorio Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.ietf.org> = wrote:



> Il 11/12/2020 11:04 Martin Thomson <mt@lowentropy.net> ha scritto:
> =
> 
> On Fri, Dec 11, 2020, at 21:01, Vittorio Bertola = wrote:
> > If I may provide another perspective, I think that = the requirements for
> > non-experimental deployment models = will be significantly shaped by the
> > legal constraints. = Thus, same-entity is likely to be a deployment
> > requirement = for those that want to do automatic upgrades in countries
> > = with strict privacy laws, as it avoids the problem of how to legally =
> > add one more entity into the personal data loop without = having to ask
> > anything to the user.
>
> This = seems reasonable.  What expectations do you have regarding where = the responsibility for compliance would lie in the case where a network = operator provides a reference?  Or, where the DNS resolver provides = a reference?  Would the client share responsibility?

This is = definitely a question for a lawyer :-) In GDPR terms, I would say that = the DNS client is at least a "joint controller" of the user's = DNS queries, no matter who tells them what. But if you go down that = path, you might conclude that the client will always have to ask for the = user's informed consent whenever a new server is contacted, and you end = up with the DNS version of cookie popups. As an exception, the resolver = of the user's Internet access provider might be safe, as the user = consents to share data with it when they sign a contract for Internet = access. But again, this is a question for a lawyer.

> I ask = because if the client can't authenticate the claim, it might not be = reasonable to have it assume responsibility in this case.  It might = be that best effort (check that the IP matches) is acceptable = though.
>
> (It might be that this comes down to: wait and = see, then ask a lawyer, that's OK too, but it doesn't give us much to = base design decisions on.)

This looks like a bit of a problem in = the IETF's process: standards seem to be designed without having = ascertained the non-technical requirements. Even if we wanted to do = that, however, how to do that is not immediate.

--
Vittorio = Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com
Office @ Via = Treviso 12, 10144 Torino, Italy

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

--
Add mailing = list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

--
Add mailing = list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add

------=_NextPart_001_089E_01D6D884.4EEF5A00-- ------=_NextPart_000_089D_01D6D884.4EEF5A00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXjCCA0Mw ggIroAMCAQICEF/4eygrVNyNQqMVtWjJrf8wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lz Y28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTA0MDUxNDIwMTcxMloX DTI5MDUxNDIwMjU0MlowNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UEAxMSQ2lzY28g Um9vdCBDQSAyMDQ4MIIBIDANBgkqhkiG9w0BAQEFAAOCAQ0AMIIBCAKCAQEAsJq5q6evCnen4nG2 tGZilHiIR8ZiVYRAMr/Aqy6lHHHWvG57qKq6btIViEhFnaL8g9DMuYzgJmhwSnjfIRee9GEFyRXI zxbaNWGJlEOohKgxmHibuU5vLFMSbM0drSskuzHEK/+DRG+2PSR3Ceq/Kqgfalb2IA8RVJeBdacl zllqgmXvt+rn4o11i27y3U+mXmKczxAKZNBObc4rzFv1YKUnR41p9H/OG3DecBsg1m7NpgGoPBLS qT+ga167jiCLepHjtWjuoOfEAXSoUwsrSpoPZRIOgk2OY/3v65sa21OmE2Cvwn3Xx2wXJdRz+0dk UIGAlEzhv65LHN+S7S4F3wIBA6NRME8wCwYDVR0PBAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYD VR0OBBYEFCfzyBUebpoCCRatK6CJYF/aey+qMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEB BQUAA4IBAQCdnYSEo0GpfHcMt1PKTkRQYu9UfNN1Fxzo4MZIS7b+TDoZgVawVu4ZlmKqWqNkwfZO VDPGd/7FHLrlXSXK9fCTmoMRLubL+HRF/ucFuKvn38tL4TeE2rmLl3Ae8OKL17DYDp2xadYqkXup SU9+5o6V2IMnPNVoSQ7UnfYu66e+6zCkrB9E/JWrMwb7fWAK3rSKY7CcqfKkuVMBh9BopCd/q//p +slAOIhntDnGhG9XyVPbuo7uwEOy+AmDbv9mzz7vF7NYGCUJNF7jy9YUtuzykm905C+BKtWSkeDg lzwyaAWFS9H3V+JSHZMaVJ8FcMBKcWAeQwtgHv6jzoEZ4Qs1MIIEbjCCA1agAwIBAgIKYRCAbQAA AAAADjANBgkqhkiG9w0BAQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJD aXNjbyBSb290IENBIDIwNDgwHhcNMTQwNDA0MjAyNDE4WhcNMjkwNTE0MjAyNTQyWjAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDK334WTFMV+yNWzca5ZQoEleXeTEVnjAzHBuCrH21fNyp75+2jrYB/Ecjz guvun1DZyb89oS+7PBEHNe+4pdlRTtmw91OglIAsLJJlrRBvoYZrX0AKmaVQRBqQTc/mTPtGBo1I 4wfX4a1j19XoJwAVv24HskO7ZQYvffZZXZsSxSx9vetEsFLhwvwe7Z1Z9x2Tp6sxpkJCOSfTgWLG VCwmjNs9FNCojhXqKKQb/r2sPJ5N1tVMr4zL/0ufBWwPcYEyJGHtGau+6nG0aIy7yPTkiz93U6J+ FZ5zC+NXdF6D0uiTxsw0kQwCl53XB5N1VLRfgywCF6iwkGV32VLk7iJ3AgMBAAGjggGHMIIBgzAQ BgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUn5U2tI5d1UvDCsGnKZNDUQb9iVEwGQYJKwYBBAGC NxQCBAweCgBTAHUAYgBDAEEwCwYDVR0PBAQDAgGGMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0j BBgwFoAUJ/PIFR5umgIJFq0roIlgX9p7L6owQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL3d3dy5j aXNjby5jb20vc2VjdXJpdHkvcGtpL2NybC9jcmNhMjA0OC5jcmwwUAYIKwYBBQUHAQEERDBCMEAG CCsGAQUFBzAChjRodHRwOi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY3JjYTIw NDguY2VyMFwGA1UdIARVMFMwUQYKKwYBBAEJFQEVADBDMEEGCCsGAQUFBwIBFjVodHRwOi8vd3d3 LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvcG9saWNpZXMvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUF AAOCAQEAPk6+IxpGAo1ea9uKAjQLY5vlATwmXYxwsiTrYF7sioRkLhtZFaNnGuEW4/3gTX1EmiMo 0u2296If50TN7W3qhiFUKKxsYbz7yGVQBECKKov8n24YnvXFPqWiqRwArnGmF7tJMktKWBOTTDbp 9y8N6IDrOF1UecqFUqSk4lZ30w0HIU6cJDIM4r6lw3EtTog31PAvVmhGR0VrXVCIJfc6KaTxiEGt U35XMYYq1uBnh9hTq4GjdXe+2yHIOke0aSfV7t/39NZxjbp60XMvfd3NpniUKGXDiXdeQuroB8IQ MXl2OkF2IJGPCkFQghsJKbIRIG8D6wviPyLW+j+4Rqu2sDCCBKEwggOJoAMCAQICCgGGGmG8CetC JFAwDQYJKoZIhvcNAQELBQAwLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxv eWVlIENBMB4XDTIwMDYwOTE4MTEzOFoXDTIyMDYwOTE4MjEzOFowgZYxHTAbBgNVBAMTFFZpbm55 IFBhcmxhICh2cGFybGEpMRQwEgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVz MRMwEQYKCZImiZPyLGQBGRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHzAdBgkqhkiG9w0B CQEMEHZwYXJsYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg5zG6 WUz2eLCtkokcmka2wwjH6DXR8dfR2VqJ3szmqqmiZLHtOZQ7/3+/ztkZk0iM3yQQc2l9KsQ2jzHU rkOZpqMpYCv43rxL2uAM0gQfpIxWGoHN5L3kW7gVpXuPmgGgF6TpMI9vytRh1gl4SHJD8f9QTvTU JynVycwV0KCQfjrJ77AGHX+7+Jwt7vkY64UtJmM7gCoJj7CU7eO+PAJc2qAJMaljtK4XI6InXFPB 7meUpm8k1TBtUuOpe25WYdUcbeipNtqjTFDtYNtXSXwHn1JRWr14CMWI2iTUu69D6M5p8KxXMStS F197vWn7QrFJ1PaK366O/LgsHumVQxAHAgMBAAGjggFYMIIBVDAOBgNVHQ8BAf8EBAMCBPAwDAYD VR0TAQH/BAIwADB6BggrBgEFBQcBAQRuMGwwPAYIKwYBBQUHMAKGMGh0dHA6Ly93d3cuY2lzY28u Y29tL3NlY3VyaXR5L3BraS9jZXJ0cy9jZWNhLmNlcjAsBggrBgEFBQcwAYYgaHR0cDovL3BraWN2 cy5jaXNjby5jb20vcGtpL29jc3AwHwYDVR0jBBgwFoAUn5U2tI5d1UvDCsGnKZNDUQb9iVEwOgYD VR0fBDMwMTAvoC2gK4YpaHR0cDovL2Npc2NvY2VydHMuY2lzY28uY29tL2ZpbGUvY2VjYS5jcmww GwYDVR0RBBQwEoEQdnBhcmxhQGNpc2NvLmNvbTAdBgNVHQ4EFgQU77mvrtX1ZwgDCBrBz254abit a7kwHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAJ0C qW6utEOTvSb85ZBZel2OgSpFDDjaLWIEceNr23m4NkhjweswzFPJY4nnKgD40Ryv5WVW4KdpmbZx NBZl4Ypd5XlwleoU9jHuSwp6kaYCEJ7YfOIKVBcF1rYclNL0J0nJ2/fnaxGoYylNfW99vu4UaqEl BWU66VkGfsg5hWPRg90fuge1zZhlwI2AE6xq7pV8C2302ag94ti465IhjnHswtA4Q+r39Tc+me1o b2s1g8WKyds2DPI0PAjWnNpsEvYYOXU8MeMv9p6jPbFG9uaCpt8kCGcYytt8FD285Rmq77FRMEBe ptFCTJh5yr5hIaMVoqBUydvZmQAYKnRX8zMxggLwMIIC7AIBATA6MCwxDjAMBgNVBAoTBUNpc2Nv MRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYaYbwJ60IkUDAJBgUrDgMCGgUAoIIBizAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDEyMjIyMjAzMDJaMCMG CSqGSIb3DQEJBDEWBBQC9cu0KOsDVaeMmXP9ZibtJ6XVWDBJBgkrBgEEAYI3EAQxPDA6MCwxDjAM BgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYaYbwJ60IkUDBLBgsq hkiG9w0BCRACCzE8oDowLDEOMAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVl IENBAgoBhhphvAnrQiRQMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAAunOak0yK5y5nosOfvJCe+ATBfQnOCm6wN6anSdcQJF/MzcqQkcjI2eX9P7 wHZOnRhncPcDGp/JT4kUooi//qC6IzduUFRMfbsjvxJPKufrsnEqkBkzDXZMgBL9+fE9JLYsgezz SjvrapH42KP7JULpZU1VvSF/hPXBtAJVag2lp5FrQOeV8TwrnQOyRUunIEGx3ZvDioS+mSwLuQ8X BnR670yfq02vipmoYn73fn42tmZ6zYcwkvl6lq8n/gJpgs64N1E9wHCLcthYUn4m4mhN2zmKAPPS txNWGR14gRl2j1R8D609wUqHO47CzPcF89yeQI0dSTmJ4lML2yD3yYwAAAAAAAA= ------=_NextPart_000_089D_01D6D884.4EEF5A00-- From nobody Tue Dec 22 17:00:59 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE4B3A137D for ; Tue, 22 Dec 2020 17:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXt-VVhQd1E0 for ; Tue, 22 Dec 2020 17:00:56 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA233A137B for ; Tue, 22 Dec 2020 17:00:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C536838A0B for ; Tue, 22 Dec 2020 20:01:05 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 8hUzeZp5tOAl for ; Tue, 22 Dec 2020 20:01:05 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 60A55389AE for ; Tue, 22 Dec 2020 20:01:05 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3E4C6558 for ; Tue, 22 Dec 2020 20:00:54 -0500 (EST) From: Michael Richardson To: ADD Mailing list In-Reply-To: References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> <58427333-bcb0-4a4e-bcff-7722da565d43@www.fastmail.com> <2068518088.4578.1607706624615@appsuite-gw1.open-xchange.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Add] [EXT] Re: Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 01:00:58 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > However, I don't think the right way to address this is to say that > you can only advertise a new resolver if you meet certain criteria. > Rather, the way to address these issues is to have an extensible > protocol which allows the network to make a set of such assertions > that are potentially of interest to the client. I agree. The network can represent anything it wants, it's up to the client to decide how to behave. It's never worked to tell senders what to send, but rather,= to counsel receivers on what appropriate actions to take on each message type. > * Discovery MUST provide a local network the ability to announce to > clients a set of, or absence of, recommended resolvers. > * Discovery MUST provide extensible functionality to announce other > properties of recommended resolvers. Sounds good. Why doe the properties have to be in the discovery? Why can't they be in DNS pseudo-RRs? > [0] It's worth noting that for Do53, pretty much all you get is "hey, > over here". more of actually, "hey, it's over *there*" :-) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/ilsUACgkQgItw+93Q 3WVhjQf9GFDnPOtT1QLrrs64UQxS/7NQcSAviCzd3zJ8oDYlypz7/0OYoTOHv2YX NgpuH2e+yi1g2E9s/wy8zbPoLRqNUnL8iO4B4AnC2bLAWfiRqiQRwUc0M01WGWy/ /R0Eo2nu1L3hOw6dLAOuTHRRyEh07O61CXmiNDPpVHUSvJPkqc009fTGvN070B4s rmKJ04G7eSfoWW9TByfS3C8+QgTshkciikUiYQuIxr3e+Wr1SmK5XTpMbfaBcwKy C1dBnWglM1G5h7ca5B/RrqXPlkm+5C0fdwFDQcg85lK6wTistvdPp2fgyUd9rfwN 4avBXWZIPSy0+CVgvOwJiXCpftaqvw== =HxQ4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 22 17:04:28 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525073A1380 for ; Tue, 22 Dec 2020 17:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MShdV5KNso8R for ; Tue, 22 Dec 2020 17:04:25 -0800 (PST) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E6B3A137E for ; Tue, 22 Dec 2020 17:04:25 -0800 (PST) Received: by mail-lf1-x131.google.com with SMTP id y19so36140982lfa.13 for ; Tue, 22 Dec 2020 17:04:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4d8K1I8349pyKGiLYqnsG3hOQWHd2DVOZY9nMKihqzY=; b=vr7mbcLwJEYerS37ByYd2ezIaIfK90Ukk3RqIj+as14GhqBflB8Iydb1J8hhuA5Spf sUqNOjCORSDr1Hm+6MN3BR1ZYoUYjiO85rohZIgaIDA3e9Z7DommL1+eVTtu7GzyDBLJ 64sfx2HmL01cdB6oYZWqp064UB1Q2A8ttMdbAq9KJznDd4xVbEXskesCbETj2YaGIrhy rid7tw9iaNLWRELTA5idcZzNj/ky5qKY58feoXl6qngUgYCS/I5wKqXaCPeezBVhUR2Y moRrfCEPd9tgFptXcTAOACOxSRa2TLixj+eBI8o0JXrvubmeVQhYGKnDRQHvWRvwIJ22 WORw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4d8K1I8349pyKGiLYqnsG3hOQWHd2DVOZY9nMKihqzY=; b=XZEqdLWRcAn3MWPClLgpEJls+kmQXfr9OhbUgIwXNdl0S2zSvRrrQhuK8UtB1+jsDL Za+iaCCjBykEl5c9elyQOGuBPvMnKiojukfwM/SX/pVN3Wvy6oVLT5KaxQXR+lmTrYvs rQrqWlUK1xZ3xHHmcHR+qsJlBpC6ob9dKFwV0qfNjtzrDQak4IZA+IRa0JIAHb8704lw +Y0NqHEpP/M+ISMW/Co8DrZRy/08vB2Orc3Gq//2SWpYsnM/zTRXtUz8kpmh2zI3E19l wqOioEq0Wj0SjaBx48CGW2rcHATHwJakqhwVU8oWZrd4D7+xBO+1UR6qzbCjyrAodxyN 4ZvQ== X-Gm-Message-State: AOAM531xIpFf3Fs/a/J61++++DyaBdwF+vcGda8IsIdM4PRlhqz3T43N iS5YI4drzbufPBAN75+U+miusF7nPM6UOUrb0WwkPw== X-Google-Smtp-Source: ABdhPJwowZOdPvt4DLigyoQhb73hpPMSPyUW2Ow6sQ+nJ5eBpmj7i2R8kRyexG4AZQMLx20vVvYTzmEAFHCizgEms2Q= X-Received: by 2002:a05:6512:3284:: with SMTP id p4mr9294476lfe.245.1608685463407; Tue, 22 Dec 2020 17:04:23 -0800 (PST) MIME-Version: 1.0 References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> <58427333-bcb0-4a4e-bcff-7722da565d43@www.fastmail.com> <2068518088.4578.1607706624615@appsuite-gw1.open-xchange.com> <30614.1608685254@localhost> In-Reply-To: <30614.1608685254@localhost> From: Eric Rescorla Date: Tue, 22 Dec 2020 17:03:47 -0800 Message-ID: To: Michael Richardson Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000009a23aa05b717453e" Archived-At: Subject: Re: [Add] [EXT] Re: Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 01:04:27 -0000 --0000000000009a23aa05b717453e Content-Type: text/plain; charset="UTF-8" On Tue, Dec 22, 2020 at 5:01 PM Michael Richardson wrote: > > Eric Rescorla wrote: > > However, I don't think the right way to address this is to say that > > you can only advertise a new resolver if you meet certain criteria. > > Rather, the way to address these issues is to have an extensible > > protocol which allows the network to make a set of such assertions > > that are potentially of interest to the client. > > I agree. > The network can represent anything it wants, it's up to the client to > decide > how to behave. It's never worked to tell senders what to send, but > rather, to > counsel receivers on what appropriate actions to take on each message type. > > > * Discovery MUST provide a local network the ability to announce to > > clients a set of, or absence of, recommended resolvers. > > > * Discovery MUST provide extensible functionality to announce other > > properties of recommended resolvers. > > Sounds good. > Why doe the properties have to be in the discovery? > Why can't they be in DNS pseudo-RRs? > No particular reason. Just clumsy phrasing on my part. I think the requirement just needs to be "there's some standardized way to find them", right? > > [0] It's worth noting that for Do53, pretty much all you get is "hey, > > over here". > > more of actually, "hey, it's over *there*" :-) > Agreed. -Ekr --0000000000009a23aa05b717453e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 22, 2020 at 5:01 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Eric Rescorla <ekr@rtf= m.com> wrote:
=C2=A0 =C2=A0 > However, I don't think the right way to address this= is to say that
=C2=A0 =C2=A0 > you can only advertise a new resolver if you meet certai= n criteria.
=C2=A0 =C2=A0 > Rather, the way to address these issues is to have an ex= tensible
=C2=A0 =C2=A0 > protocol which allows the network to make a set of such = assertions
=C2=A0 =C2=A0 > that are potentially of interest to the client.

I agree.
The network can represent anything it wants, it's up to the client to d= ecide
how to behave.=C2=A0 It's never worked to tell senders what to send, bu= t rather, to
counsel receivers on what appropriate actions to take on each message type.=

=C2=A0 =C2=A0 > * Discovery MUST provide a local network the ability to = announce to
=C2=A0 =C2=A0 > clients a set of, or absence of, recommended resolvers.<= br>
=C2=A0 =C2=A0 > * Discovery MUST provide extensible functionality to ann= ounce other
=C2=A0 =C2=A0 > properties of recommended resolvers.

Sounds good.
Why doe the properties have to be in the discovery?
Why can't they be in DNS pseudo-RRs?

No particular reason. Just clumsy phrasing on my part. I think the requir= ement just needs to be "there's some standardized way to find them= ", right?


=C2=A0 =C2=A0 > [0] It's worth noting that for Do53, pretty much all= you get is "hey,
=C2=A0 =C2=A0 > over here".

more of actually, "hey, it's over *there*" :-)

Agreed.

-Ekr
--0000000000009a23aa05b717453e-- From nobody Wed Dec 23 03:18:58 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104E73A0EB8 for ; Wed, 23 Dec 2020 03:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YF7FQ_HVIfqg for ; Wed, 23 Dec 2020 03:18:55 -0800 (PST) Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07DB03A0EBA for ; Wed, 23 Dec 2020 03:18:54 -0800 (PST) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 7A1C96A27C; Wed, 23 Dec 2020 12:18:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1608722332; bh=Q69pFFtql9KXlLb9M2ueCSGYh3Jv4V9OVkalIcRZiwI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=yzlhn71GHNo3ApRm8wZy6oZx1AqZ7G1DsPlOLisEO5Q4lbgad13p86GO7ukJLJSlB HK4veJVWqUPnaV8eNrMlbZik/+HTMy7VMcOdQ+9elmo8SgHtbGJbAtAerFoIt6j9EX CEO1ZMd0cOgJw4jSsnMHk+acr7WNc0Ae1qjS9BOWqGgfpblaIZbk/UbWu1IjyMhr0M kPqX3zCsAVbatuxHewW0EUhQu4EE3UP4PCNhiy4HskU1tNyf69EIJojNvx0nvyPSmT bPHGwdn1Yi3O8H/9R516Gn5qu5wbpbcdw63Rb1kHskzm7ajg1DvpQY+Riuee49Pha2 1AUI3GTO4xt5w== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 5E8AB3C0051; Wed, 23 Dec 2020 12:18:52 +0100 (CET) Date: Wed, 23 Dec 2020 12:18:52 +0100 (CET) From: Vittorio Bertola To: Eric Rescorla , Chris Box Cc: ADD Mailing list Message-ID: <554538753.9685.1608722332313@appsuite-gw2.open-xchange.com> In-Reply-To: References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> <58427333-bcb0-4a4e-bcff-7722da565d43@www.fastmail.com> <2068518088.4578.1607706624615@appsuite-gw1.open-xchange.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9683_1674604022.1608722332296" X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.5-Rev2 X-Originating-Client: open-xchange-appsuite Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1 Archived-At: Subject: Re: [Add] [EXT] Re: Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2020 11:18:57 -0000 ------=_Part_9683_1674604022.1608722332296 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > Il 22/12/2020 22:29 Eric Rescorla ha scritto: > > From the perspective of requirements, then, I think the relevant > question is what other information the client might be interested in > having in order to make the decision as to whether to use that server > [0]. For instance, the network might represent: > > 1. This resolver will give more or less the same answers as the > Do53 resolver. > 2. This resolver is operated by the same people as the Do53 resolver. > > However, I don't think the right way to address this is to say that > you can only advertise a new resolver if you meet certain criteria. > I don't think that this was the objective. However, you still have to define a concept of equivalence if you want the resolver to provide an assertion of equivalence in the context of "other information the client might be interested in". As Eric Orth pointed out, there are clients that are interested in receiving and consuming this information, and having an agreed definition of what these concepts mean would be helpful to interoperability, even if it is interoperability in a policy sense. On the other hand, since anyone willing to use these signals will need to trust the Do53 resolver and its communications, I think we can keep the definition relatively vague, as it will entirely be up to the resolver operator to determine whether the definition is met or not, and thus whether certain properties should be declared as true; clients will have to trust their judgement (or verify it independently from the discovery process) anyway. Here we are in the realm of voluntary cooperation among good-willing parties, so I think that we are assuming that the resolver is not an adversary, because if we assumed the opposite, there would be no point in establishing any kind of discovery and property communication mechanism. Clients that are not ready to make that assumption (not even if subject to additional checks and restrictions, which pertain to each client's own policy) will not use these definitions anyway, but clients that, at least in some circumstances, are willing to trust the existing resolver would benefit from some standardization. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com mailto:vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy ------=_Part_9683_1674604022.1608722332296 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Il 22/12/2020 22:29 Eric Rescorla <ekr@rtfm.com> ha scritto:

From the perspective of requirements, then, I think the relevant
question is what other information the client might be interested in
having in order to make the decision as to whether to use that server
[0]. For instance, the network might represent:

1. This resolver will give more or less the same answers as the
   Do53 resolver.
2. This resolver is operated by the same people as the Do53 resolver.

However, I don't think the right way to address this is to say that
you can only advertise a new resolver if you meet certain criteria.
I don't think that this was the objective. However, you still have to define a concept of equivalence if you want the resolver to provide an assertion of equivalence in the context of "other information the client might be interested in". As Eric Orth pointed out, there are clients that are interested in receiving and consuming this information, and having an agreed definition of what these concepts mean would be helpful to interoperability, even if it is interoperability in a policy sense.

On the other hand, since anyone willing to use these signals will need to trust the Do53 resolver and its communications, I think we can keep the definition relatively vague, as it will entirely be up to the resolver operator to determine whether the definition is met or not, and thus whether certain properties should be declared as true; clients will have to trust their judgement (or verify it independently from the discovery process) anyway.

Here we are in the realm of voluntary cooperation among good-willing parties, so I think that we are assuming that the resolver is not an adversary, because if we assumed the opposite, there would be no point in establishing any kind of discovery and property communication mechanism. Clients that are not ready to make that assumption (not even if subject to additional checks and restrictions, which pertain to each client's own policy) will not use these definitions anyway, but clients that, at least in some circumstances, are willing to trust the existing resolver would benefit from some standardization.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
------=_Part_9683_1674604022.1608722332296-- From nobody Sun Dec 27 10:05:11 2020 Return-Path: X-Original-To: add@ietfa.amsl.com Delivered-To: add@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365983A0B04 for ; Sun, 27 Dec 2020 10:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-6cG_IHrRUz for ; Sun, 27 Dec 2020 10:05:07 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110063.outbound.protection.outlook.com [40.107.11.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F9B3A0B02 for ; Sun, 27 Dec 2020 10:05:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NA1i0Op6ojrSFZmafh83lM75VZtKxE7rMuGw/GZrUyZlIecWvIRAZjjlO/WzuDAOk5f4Qeb7TMVDUyrUrs6abtzpEaN1z4dLJYhSaekrd2qhdNCAIaGrV5thJPbbTmvAAp9txFOBWsTpsMUYoC2BR7CuuSrzFQXmM64o+wtqnpvGKu+hyM0yfNmIypCMhiQu6xkfWu+QgYE6fAAxsGo9tDOduKciTwgHA1DRTcUui31Ew/jbkBrL/2rdwYfOKr7aS02i/oOnUgIAM6enlA4W17w4nax+8az4mrqdEq61u7e0uDSdfQfwOBRtrhISp01y11MY2ZCng1URt1POQlhleg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c/9gIOTjt6kEDCEJUg9hbRH4jVA7IZh+wB2hvNBx2M0=; b=BmTmCXCBSdNnVJMOnQgh6Zle9AkLUvWKqBHVOe9pN53fMAfLZOE8jE/ADlpVoemPhPGR1PtR7VjuT3sT8oZahhl7T+qp93uuudcno62bHWVnDyP7ZmZNM3CSRCwAnmZ7Ca2pZuf+WBlBXo4HfJFSHS37IJGRtu9Y4J05cCSGfLE9C2eWmdz1IOgTURXWhg1oFgbVTSvADlWvDD7R+UGlQAIMP8S/CU2QX5JOcOZdcH/CNyhogW4ZulO1Rb29rXGQOyxcN5P3tR1LdaMXId6BwSvXm1hLQ68H7cHOAHvZ70VIXpjnVpxbHtJb5eKbYrkHYVAZuiSXLANiDH1uLUBnig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c/9gIOTjt6kEDCEJUg9hbRH4jVA7IZh+wB2hvNBx2M0=; b=QoTZIa5/91XcRKZXhOHYoi+6o8XvBbGsvHzmSQwLvtY7t2eGU3383PtSrwo0oGQVtmSStaR6Y9Va6BWqlTojP/wuIyFVC0HZ3LIjtXsH/xGXkIgZqIZy3MdHfBySMLIoSyX7QRAdtfMHB9cBjxtRTrq24jmjRCX+Lh65ONux3xk= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) by LO2P265MB1535.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9b::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.28; Sun, 27 Dec 2020 18:05:04 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::4074:aae:262:a640]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::4074:aae:262:a640%7]) with mapi id 15.20.3700.031; Sun, 27 Dec 2020 18:05:04 +0000 From: Andrew Campling To: Vittorio Bertola , Eric Rescorla , Chris Box CC: ADD Mailing list Thread-Topic: [Add] [EXT] Re: Definition of equivalence Thread-Index: AQHW3HrN4tCmDZcKC0ui26jtnCLMxA== Date: Sun, 27 Dec 2020 18:05:04 +0000 Message-ID: References: <15af2825-ec9c-454f-88aa-6f06f82a59e5@www.fastmail.com> <81382923-ca67-4c96-a2bb-1fc9d8b50b09@www.fastmail.com> <20201210072505.p7ksp7nscccvjpuq@family.redbarn.org> <30da1442-a3db-48b6-b730-95b3bd2b6964@www.fastmail.com> <141175272.3011.1607680893722@appsuite-gw1.open-xchange.com> <58427333-bcb0-4a4e-bcff-7722da565d43@www.fastmail.com> <2068518088.4578.1607706624615@appsuite-gw1.open-xchange.com> <554538753.9685.1608722332313@appsuite-gw2.open-xchange.com> In-Reply-To: <554538753.9685.1608722332313@appsuite-gw2.open-xchange.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: open-xchange.com; dkim=none (message not signed) header.d=none;open-xchange.com; dmarc=none action=none header.from=419.consulting; x-originating-ip: [86.141.219.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eae21a81-da45-456f-1b3e-08d8aa91efd6 x-ms-traffictypediagnostic: LO2P265MB1535: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GVmLtsfqWH15YgSRuY4lgYnloODxAyr+29hj1Rb2mNVHYUFK/GSTI1+pI4XVNI7YfMsGpKNhFmiZT3Efl8lvXfuHSW3ZlWoUe8xcXX7u9pkeTYu9Ezif5rPpvhFofL1emRK6xtoh97X+x4HmLxWbHwFLRyDP4J3DKpnzSmxaymyI6MoTW6E+EXHqI2lRB5IKtZXtgzz479KReku2mrvvPaQ/IOxnlgLWHIEiv3I519vECNtEjwEAALkYulvzj9ret3natIlfNL4BNJDT0vJWjHZWfKCKj5TXUOBVdqlH4b7PDyEoyRT5iTLLsNXxyqWMNh0OHmrOBECjyRDmUVju+geYlmGjPAtv+zmeEPV5NCsRXPLz+TX33UKky12akylVQ3j3mmmZu2P0xZZWENhUV7VBFpUJ0hIeUt7cQCSapV2QVeXXvQikGaU+lCtwd1Z9 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(376002)(136003)(396003)(346002)(39830400003)(86362001)(6506007)(478600001)(26005)(9686003)(2906002)(186003)(55016002)(33656002)(8936002)(4326008)(66556008)(64756008)(66476007)(52536014)(66446008)(83380400001)(44832011)(53546011)(110136005)(316002)(71200400001)(76116006)(5660300002)(8676002)(7696005)(66946007)(46492008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?TzVsckg5ZUhWY09vWUlvWDI1OUdkUnJwTXBKYnc0ZXFFL0p6QkptL0tqaS92?= =?utf-8?B?K1lYN3NTdWlKdDIzQm5BbVRQRlFzaXN1cEtIY3plUkl6UnJzM3lpUzRKTmRv?= =?utf-8?B?VnpEbm92NzlJc1VLQTVEYnFrYlBwYlZBRk8reWZMUzBxSnZvNFE4M08zdU5Q?= =?utf-8?B?N3hmbXQrWmROMTBOYWFwTEVEZXlmN0Vnb3FhK2tjZlpxU0ltRFliN3pVaHY4?= =?utf-8?B?QjN2R1dmOEVTRkM0K2xsREZzT3YrZFVPUDk1SitUTGRZTzIvbVppQmlBZjVU?= =?utf-8?B?MjlHUmwwaGxzYVgyaElzZTZmL2JFZlNwdUNXUnk0TDYvZ2NIa0NiK29wY0Zk?= =?utf-8?B?V1prbmt6WmRuRU5JVXFGbWdVaU8vSk1EZG52MndTVVRpTnhOSW1nNTZ3aFBr?= =?utf-8?B?NEhyeTBQdy9KU2UwR1RtMkRFV3Z3L2J6ei9EeTBjRXlXYUNTK2t4QnNlYU52?= =?utf-8?B?L3FYVExmdlFIbkxQMllWVlhqOUZCQ0tGMUgzbkc4ZXpUaDhVbkZVK3QzdG85?= =?utf-8?B?VUc3OHRVcWZqSVM5V1FxaWNJSUQrQzVYeFlYVzE1S1U2MXZUQTBYTHpEc2JX?= =?utf-8?B?eC83ektQL2o0TzhWZGlHRnNLU3NVczVTYmI0OVp2ck1aamk3ckF0OTVhRzJp?= =?utf-8?B?VXdhdDBQYm5zN01yMDQvMGdoUXpYVDM1V3U1dXRFb1MxblhSZkJHQklFUUV1?= =?utf-8?B?ZjQrSitwS0ZVRmUweWgvSzQ4WkkwdFFqckdpNHpRMGc0MnFDN3dpeVV0bXk4?= =?utf-8?B?WkdhK3QyMmVyWTNYbERQT0c0dFI1RExZTm9xZGEwMkZCcng2ZmhtbDZlcDM2?= =?utf-8?B?eDFrOVRjL1JabTZ2OVBtZjhRellSNDc0NEYyQjRCcTZmWmhmcnJrRmxhdFl0?= =?utf-8?B?SGVBNk14dGtuNnFmQ2lWQ1lOZzZXT3dDOHlnOUZyZ2FFeVRUelgrQXVSbFNh?= =?utf-8?B?YU0yc25XN1BXNlFYZUJDYS8wZTVRem51YmoySUpwQUtBL2YwMTE0Nkk2OEE3?= =?utf-8?B?UHFQQ1o2Q3Q1L2VRZ0h5TGl2THY5cy94Q3laS2VFMXRvL1VHeGpCVEZzMENv?= =?utf-8?B?MG56VmYrYjVIc2crVjFWYmRnbERva0U4NVlnM0dyeWJ4eEg5dWM5YjhEN2c1?= =?utf-8?B?R1pyZTRYTnNpN0NDTkF4OHZzK2xseEVlMW1VeXpVVGdoKzF5bEtPRTN1aldS?= =?utf-8?B?ME8yMVMwUUdSVndPaCsrL21ab0tscWNqL2Q5VmdSU0hvNVBidW91dkZITGhk?= =?utf-8?B?MVA5cHRvbVNDSlpsb2ozMkZsYlU2ZEd1T3JnckdFN3BMb3ZFcGZRWWRXU2Vu?= =?utf-8?Q?+OB1kyEk8RkxE=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573C2B94D71AB547AACA4AEC2DA0LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: eae21a81-da45-456f-1b3e-08d8aa91efd6 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2020 18:05:04.2402 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NufoVrgjKCPsOZRBo8JtUhvsoCsLEjZ/Py5AYc7/wXwzsEIqYNtprdf5++Knl2L+s/sVpLQEMLlQ9wfv9Jknh5qRYlWYHybwSIgFxyIkAAY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1535 Archived-At: Subject: Re: [Add] [EXT] Re: Definition of equivalence X-BeenThere: add@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Applications Doing DNS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Dec 2020 18:05:10 -0000 --_000_LO2P265MB0573C2B94D71AB547AACA4AEC2DA0LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gVHVlLCBEZWMgMjMsIDIwMjAgMTE6MTkgQU0gVml0dG9yaW8gQmVydG9sYSA8dml0dG9yaW8u YmVydG9sYUBvcGVuLXhjaGFuZ2UuY29tPG1haWx0bzp2aXR0b3Jpby5iZXJ0b2xhQG9wZW4teGNo YW5nZS5jb20+PiB3cm90ZToNCg0KSWwgMjIvMTIvMjAyMCAyMjoyOSBFcmljIFJlc2NvcmxhIDxl a3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IGhhIHNjcml0dG86DQoNCkZyb20gdGhl IHBlcnNwZWN0aXZlIG9mIHJlcXVpcmVtZW50cywgdGhlbiwgSSB0aGluayB0aGUgcmVsZXZhbnQN CnF1ZXN0aW9uIGlzIHdoYXQgb3RoZXIgaW5mb3JtYXRpb24gdGhlIGNsaWVudCBtaWdodCBiZSBp bnRlcmVzdGVkIGluDQpoYXZpbmcgaW4gb3JkZXIgdG8gbWFrZSB0aGUgZGVjaXNpb24gYXMgdG8g d2hldGhlciB0byB1c2UgdGhhdCBzZXJ2ZXINClswXS4gRm9yIGluc3RhbmNlLCB0aGUgbmV0d29y ayBtaWdodCByZXByZXNlbnQ6DQoNCjEuIFRoaXMgcmVzb2x2ZXIgd2lsbCBnaXZlIG1vcmUgb3Ig bGVzcyB0aGUgc2FtZSBhbnN3ZXJzIGFzIHRoZQ0KICAgRG81MyByZXNvbHZlci4NCjIuIFRoaXMg cmVzb2x2ZXIgaXMgb3BlcmF0ZWQgYnkgdGhlIHNhbWUgcGVvcGxlIGFzIHRoZSBEbzUzIHJlc29s dmVyLg0KDQpIb3dldmVyLCBJIGRvbid0IHRoaW5rIHRoZSByaWdodCB3YXkgdG8gYWRkcmVzcyB0 aGlzIGlzIHRvIHNheSB0aGF0DQp5b3UgY2FuIG9ubHkgYWR2ZXJ0aXNlIGEgbmV3IHJlc29sdmVy IGlmIHlvdSBtZWV0IGNlcnRhaW4gY3JpdGVyaWEuDQoNCj4gSSBkb24ndCB0aGluayB0aGF0IHRo aXMgd2FzIHRoZSBvYmplY3RpdmUuIEhvd2V2ZXIsIHlvdSBzdGlsbCBoYXZlIHRvIGRlZmluZSBh IGNvbmNlcHQgb2YgZXF1aXZhbGVuY2UgaWYgeW91IHdhbnQgdGhlIHJlc29sdmVyIHRvIHByb3Zp ZGUgYW4gYXNzZXJ0aW9uIG9mIGVxdWl2YWxlbmNlIGluIHRoZSBjb250ZXh0IG9mICJvdGhlciBp bmZvcm1hdGlvbiB0aGUgY2xpZW50IG1pZ2h0IGJlIGludGVyZXN0ZWQgaW4iLiBBcyBFcmljIE9y dGggcG9pbnRlZCBvdXQsIHRoZXJlIGFyZSBjbGllbnRzIHRoYXQgYXJlIGludGVyZXN0ZWQgaW4g cmVjZWl2aW5nIGFuZCBjb25zdW1pbmcgdGhpcyBpbmZvcm1hdGlvbiwgYW5kIGhhdmluZyBhbiBh Z3JlZWQgZGVmaW5pdGlvbiBvZiB3aGF0IHRoZXNlIGNvbmNlcHRzIG1lYW4gd291bGQgYmUgaGVs cGZ1bCB0byBpbnRlcm9wZXJhYmlsaXR5LCBldmVuIGlmIGl0IGlzIGludGVyb3BlcmFiaWxpdHkg aW4gYSBwb2xpY3kgc2Vuc2UuDQoNCj4gT24gdGhlIG90aGVyIGhhbmQsIHNpbmNlIGFueW9uZSB3 aWxsaW5nIHRvIHVzZSB0aGVzZSBzaWduYWxzIHdpbGwgbmVlZCB0byB0cnVzdCB0aGUgRG81MyBy ZXNvbHZlciBhbmQgaXRzIGNvbW11bmljYXRpb25zLCBJIHRoaW5rIHdlIGNhbiBrZWVwIHRoZSBk ZWZpbml0aW9uIHJlbGF0aXZlbHkgdmFndWUsIGFzIGl0IHdpbGwgZW50aXJlbHkgYmUgdXAgdG8g dGhlIHJlc29sdmVyIG9wZXJhdG9yIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZSBkZWZpbml0aW9u IGlzIG1ldCBvciBub3QsIGFuZCB0aHVzIHdoZXRoZXIgY2VydGFpbiBwcm9wZXJ0aWVzIHNob3Vs ZCBiZSBkZWNsYXJlZCBhcyB0cnVlOyBjbGllbnRzIHdpbGwgaGF2ZSB0byB0cnVzdCB0aGVpciBq dWRnZW1lbnQgKG9yIHZlcmlmeSBpdCBpbmRlcGVuZGVudGx5IGZyb20gdGhlIGRpc2NvdmVyeSBw cm9jZXNzKSBhbnl3YXkuDQoNCj4gSGVyZSB3ZSBhcmUgaW4gdGhlIHJlYWxtIG9mIHZvbHVudGFy eSBjb29wZXJhdGlvbiBhbW9uZyBnb29kLXdpbGxpbmcgcGFydGllcywgc28gSSB0aGluayB0aGF0 IHdlIGFyZSBhc3N1bWluZyB0aGF0IHRoZSByZXNvbHZlciBpcyBub3QgYW4gYWR2ZXJzYXJ5LCBi ZWNhdXNlIGlmIHdlIGFzc3VtZWQgdGhlIG9wcG9zaXRlLCB0aGVyZSB3b3VsZCBiZSBubyBwb2lu dCBpbiBlc3RhYmxpc2hpbmcgYW55IGtpbmQgb2YgZGlzY292ZXJ5IGFuZCBwcm9wZXJ0eSBjb21t dW5pY2F0aW9uIG1lY2hhbmlzbS4gQ2xpZW50cyB0aGF0IGFyZSBub3QgcmVhZHkgdG8gbWFrZSB0 aGF0IGFzc3VtcHRpb24gKG5vdCBldmVuIGlmIHN1YmplY3QgdG8gYWRkaXRpb25hbCBjaGVja3Mg YW5kIHJlc3RyaWN0aW9ucywgd2hpY2ggcGVydGFpbiB0byBlYWNoIGNsaWVudCdzIG93biBwb2xp Y3kpIHdpbGwgbm90IHVzZSB0aGVzZSBkZWZpbml0aW9ucyBhbnl3YXksIGJ1dCBjbGllbnRzIHRo YXQsIGF0IGxlYXN0IGluIHNvbWUgY2lyY3Vtc3RhbmNlcywgYXJlIHdpbGxpbmcgdG8gdHJ1c3Qg dGhlIGV4aXN0aW5nIHJlc29sdmVyIHdvdWxkIGJlbmVmaXQgZnJvbSBzb21lIHN0YW5kYXJkaXph dGlvbi4NCg0KDQoNCg0KDQorMSB0byBWaXR0b3Jpb+KAmXMgcG9pbnRzIGFib3ZlLg0KDQoNCg0K SGF2aW5nIGFuIGFncmVlZCBkZWZpbml0aW9uIG9mIGVxdWl2YWxlbmNlIHRoYXQgaW5jbHVkZXMg YW4gaW5kaWNhdGlvbiB0aGF0IGlzIG9wZXJhdGVkIGJ5IHRoZSBzYW1lIGVudGl0eSBpcyBuZWNl c3NhcnkgaWYgY2xpZW50cyBhcmUgdG8gY29udGludWUgdG8gb2ZmZXIgYSDigJxzYW1lIHByb3Zp ZGVyIGF1dG8tdXBncmFkZeKAnSBtZWNoYW5pc20gKEnigJltIGFzc3VtaW5nIHRoYXQgbW9zdCBj bGllbnRzIHdpbGwgcHJlZmVyIHRvIHVzZSBhIHN0YW5kYXJkcy1iYXNlZCBkaXNjb3ZlcnkgbWVj aGFuaXNtIHJhdGhlciB0aGFuIGN1cmF0aW5nIHRoZWlyIG93biBsaXN0cyBvZiByZXNvbHZlcnMp Lg0KDQoNCg0KDQoNCkFuZHJldw0K --_000_LO2P265MB0573C2B94D71AB547AACA4AEC2DA0LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgMjMsIDIwMjAgMTE6 MTkgQU0gPHNwYW4gbGFuZz0iRU4tVVMiPlZpdHRvcmlvIEJlcnRvbGEgJmx0OzxhIGhyZWY9Im1h aWx0bzp2aXR0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20iPnZpdHRvcmlvLmJlcnRvbGFA b3Blbi14Y2hhbmdlLmNvbTwvYT4mZ3Q7DQo8L3NwYW4+d3JvdGU6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWwgMjIvMTIvMjAyMCAyMjoyOSBFcmljIFJlc2Nvcmxh ICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0OyBo YSBzY3JpdHRvOg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQpGcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiByZXF1aXJlbWVudHMsIHRoZW4s IEkgdGhpbmsgdGhlIHJlbGV2YW50IDxicj4NCnF1ZXN0aW9uIGlzIHdoYXQgb3RoZXIgaW5mb3Jt YXRpb24gdGhlIGNsaWVudCBtaWdodCBiZSBpbnRlcmVzdGVkIGluIDxicj4NCmhhdmluZyBpbiBv cmRlciB0byBtYWtlIHRoZSBkZWNpc2lvbiBhcyB0byB3aGV0aGVyIHRvIHVzZSB0aGF0IHNlcnZl ciA8YnI+DQpbMF0uIEZvciBpbnN0YW5jZSwgdGhlIG5ldHdvcmsgbWlnaHQgcmVwcmVzZW50OiA8 YnI+DQo8YnI+DQoxLiBUaGlzIHJlc29sdmVyIHdpbGwgZ2l2ZSBtb3JlIG9yIGxlc3MgdGhlIHNh bWUgYW5zd2VycyBhcyB0aGUgPGJyPg0KJm5ic3A7ICZuYnNwO0RvNTMgcmVzb2x2ZXIuIDxicj4N CjIuIFRoaXMgcmVzb2x2ZXIgaXMgb3BlcmF0ZWQgYnkgdGhlIHNhbWUgcGVvcGxlIGFzIHRoZSBE bzUzIHJlc29sdmVyLiA8YnI+DQo8YnI+DQpIb3dldmVyLCBJIGRvbid0IHRoaW5rIHRoZSByaWdo dCB3YXkgdG8gYWRkcmVzcyB0aGlzIGlzIHRvIHNheSB0aGF0IDxicj4NCnlvdSBjYW4gb25seSBh ZHZlcnRpc2UgYSBuZXcgcmVzb2x2ZXIgaWYgeW91IG1lZXQgY2VydGFpbiBjcml0ZXJpYS4gPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7IDwvc3Bhbj5JIGRvbid0IHRoaW5rIHRoYXQg dGhpcyB3YXMgdGhlIG9iamVjdGl2ZS4gSG93ZXZlciwgeW91IHN0aWxsIGhhdmUgdG8gZGVmaW5l IGEgY29uY2VwdCBvZiBlcXVpdmFsZW5jZSBpZiB5b3Ugd2FudCB0aGUgcmVzb2x2ZXIgdG8gcHJv dmlkZSBhbiBhc3NlcnRpb24gb2YgZXF1aXZhbGVuY2UgaW4gdGhlIGNvbnRleHQgb2YgJnF1b3Q7 b3RoZXIgaW5mb3JtYXRpb24NCiB0aGUgY2xpZW50IG1pZ2h0IGJlIGludGVyZXN0ZWQgaW4mcXVv dDsuIEFzIEVyaWMgT3J0aCBwb2ludGVkIG91dCwgdGhlcmUgYXJlIGNsaWVudHMgdGhhdCBhcmUg aW50ZXJlc3RlZCBpbiByZWNlaXZpbmcgYW5kIGNvbnN1bWluZyB0aGlzIGluZm9ybWF0aW9uLCBh bmQgaGF2aW5nIGFuIGFncmVlZCBkZWZpbml0aW9uIG9mIHdoYXQgdGhlc2UgY29uY2VwdHMgbWVh biB3b3VsZCBiZSBoZWxwZnVsIHRvIGludGVyb3BlcmFiaWxpdHksIGV2ZW4gaWYgaXQgaXMNCiBp bnRlcm9wZXJhYmlsaXR5IGluIGEgcG9saWN5IHNlbnNlLiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBPbiB0aGUgb3RoZXIgaGFuZCwg c2luY2UgYW55b25lIHdpbGxpbmcgdG8gdXNlIHRoZXNlIHNpZ25hbHMgd2lsbCBuZWVkIHRvIHRy dXN0IHRoZSBEbzUzIHJlc29sdmVyIGFuZCBpdHMgY29tbXVuaWNhdGlvbnMsIEkgdGhpbmsgd2Ug Y2FuIGtlZXAgdGhlIGRlZmluaXRpb24gcmVsYXRpdmVseSB2YWd1ZSwgYXMgaXQgd2lsbCBlbnRp cmVseSBiZSB1cCB0byB0aGUgcmVzb2x2ZXIgb3BlcmF0b3IgdG8gZGV0ZXJtaW5lDQogd2hldGhl ciB0aGUgZGVmaW5pdGlvbiBpcyBtZXQgb3Igbm90LCBhbmQgdGh1cyB3aGV0aGVyIGNlcnRhaW4g cHJvcGVydGllcyBzaG91bGQgYmUgZGVjbGFyZWQgYXMgdHJ1ZTsgY2xpZW50cyB3aWxsIGhhdmUg dG8gdHJ1c3QgdGhlaXIganVkZ2VtZW50IChvciB2ZXJpZnkgaXQgaW5kZXBlbmRlbnRseSBmcm9t IHRoZSBkaXNjb3ZlcnkgcHJvY2VzcykgYW55d2F5Lg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSGVyZSB3ZSBhcmUgaW4gdGhlIHJl YWxtIG9mIHZvbHVudGFyeSBjb29wZXJhdGlvbiBhbW9uZyBnb29kLXdpbGxpbmcgcGFydGllcywg c28gSSB0aGluayB0aGF0IHdlIGFyZSBhc3N1bWluZyB0aGF0IHRoZSByZXNvbHZlciBpcyBub3Qg YW4gYWR2ZXJzYXJ5LCBiZWNhdXNlIGlmIHdlIGFzc3VtZWQgdGhlIG9wcG9zaXRlLCB0aGVyZSB3 b3VsZCBiZSBubyBwb2ludCBpbiBlc3RhYmxpc2hpbmcgYW55IGtpbmQNCiBvZiBkaXNjb3Zlcnkg YW5kIHByb3BlcnR5IGNvbW11bmljYXRpb24gbWVjaGFuaXNtLiBDbGllbnRzIHRoYXQgYXJlIG5v dCByZWFkeSB0byBtYWtlIHRoYXQgYXNzdW1wdGlvbiAobm90IGV2ZW4gaWYgc3ViamVjdCB0byBh ZGRpdGlvbmFsIGNoZWNrcyBhbmQgcmVzdHJpY3Rpb25zLCB3aGljaCBwZXJ0YWluIHRvIGVhY2gg Y2xpZW50J3Mgb3duIHBvbGljeSkgd2lsbCBub3QgdXNlIHRoZXNlIGRlZmluaXRpb25zIGFueXdh eSwgYnV0IGNsaWVudHMNCiB0aGF0LCBhdCBsZWFzdCBpbiBzb21lIGNpcmN1bXN0YW5jZXMsIGFy ZSB3aWxsaW5nIHRvIHRydXN0IHRoZSBleGlzdGluZyByZXNvbHZlciB3b3VsZCBiZW5lZml0IGZy b20gc29tZSBzdGFuZGFyZGl6YXRpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4rMSB0byBW aXR0b3Jpb+KAmXMgcG9pbnRzIGFib3ZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkhhdmluZyBhbiBhZ3JlZWQgZGVmaW5pdGlvbiBvZiBlcXVpdmFsZW5jZSB0 aGF0IGluY2x1ZGVzIGFuIGluZGljYXRpb24gdGhhdCBpcyBvcGVyYXRlZCBieSB0aGUgc2FtZSBl bnRpdHkgaXMgbmVjZXNzYXJ5IGlmIGNsaWVudHMgYXJlIHRvIGNvbnRpbnVlIHRvIG9mZmVyIGEg 4oCcc2FtZSBwcm92aWRlciBhdXRvLXVwZ3JhZGXigJ0gbWVjaGFuaXNtIChJ4oCZbSBhc3N1bWlu ZyB0aGF0IG1vc3QgY2xpZW50cyB3aWxsIHByZWZlciB0byB1c2UgYSBzdGFuZGFyZHMtYmFzZWQg ZGlzY292ZXJ5IG1lY2hhbmlzbSByYXRoZXIgdGhhbiBjdXJhdGluZyB0aGVpciBvd24gbGlzdHMg b2YgcmVzb2x2ZXJzKS4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+QW5kcmV3IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_LO2P265MB0573C2B94D71AB547AACA4AEC2DA0LO2P265MB0573GBRP_--