On Thu, Feb 27, 2020 at 11:48 AM Daniel Migault <mglt.i...@gmail.com> wrote:
> Hi, > > I read draft-ietf-dnsop-svcb-httpssvc-01. Please find find some comments > (with my questions) below I had while reading linearly the document. I hope > this will help. > Thanks for the comments, and sorry about the delay. > > Yours, > Daniel > > section 1.1 > > _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. > > > In my opinion, the mechanism that derives QNAME needs to be refined or > maybe > the terminology being clarified. > Thanks for the comments. I've filed an issue to track QNAME-related questions here: https://github.com/MikeBishop/dns-alt-svc/issues/122 > a) The current document describes how to generate the QNAME from an URI. > The > QNAME contains a port number while some scheme do not allow or specify port > subcomponent. Not having the port specified could be particularly useful to > provide secure transport for schemes that are not necessarily secure for > example. One the other hand, a scheme that specify a port, may not > necessarily > need to have it specified twined in the QNAME. I would be rather inclined > to > have the port optional maybe at the expense of an additional RRset, but > need > more thoughts. > As you know, the port is indeed optional. b) It is also unclear to me why HTTPS:443 or HTTP:80 has a specific > convention. > The convention tales place for the DNS resolution of a authority as > opposed to > the DNS resolution of a FQDN. One possible reason I see could would be to > prevent having a distinction between http and https (which could be done > otherwise for example using alpn), but I am wondering if there are other > rationale. So far, I do not see the need for a exception for the > derivation of > the QNAME (nor for using a specific RRtype). > This is explained in Section 7.1 ( https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-02#section-7.1): By removing the [Attrleaf] labels used in SVCB, this construction enables offline DNSSEC signing of wildcard domains, which are commonly used with HTTPS. Reusing the origin hostname also allows the targets of existing CNAME chains (e.g. CDN hosts) to start returning HTTPSSVC responses without requiring origin domains to configure and maintain an additional delegation. > c) The current document, mentions several time HTTP service. The term > service > seems to me ambiguous as it has been defined for the DNS service based > discovery in which case it means a web page. It seems to me preferable we > keep > the scope of URI scheme and port authority. > I agree, that could help us to improve the terminology. > As a side note, when scheme is > thought as a service, the convention adopted by the document slightly > differs > from the DNS based service Discovery which would use _baz._udp or > eventually > _baz._tcp. The current approach may be simpler.. I would think this is > mostly a > terminology issue. > > > section 2.3 > > """ > Protocol mappings for SVCB MAY remove the port or replace it with > other protocol-specific information, but MUST retain the scheme in > the QNAME. > """ > > I understand that for any scheme, a definition of how scheme and port > should be > defined when using SVBC. If that is correct, I would rather see that the > other > way around, that is SVBC defining from the scheme definition the QNAME > derivation. > I'm not sure that there's a universal, scheme-independent, mechanical transformation from URIs that would work. As you noted, for some schemes we want to include a port, while for others we don't. That's why we don't define a mapping here. The term MAY also suggest different interpretation will be > permitted, which could affect interoperability. > Yes, everyone definitely needs to agree on the mapping! The mapping is a standards document, which needs to be written for each scheme that wants to use SVCB. > """ > When a prior CNAME or SVCB record has aliased to an SVCB record, each > RR shall be returned under its own owner name. > """ > > If I am not misinterpreting this, this seems to be the natural way CNAME > works > and I am wondering if the text should not be removed from this section. My > general comment is that the text refers too much to CNAME. Probably only > the > fall back function of CNAME should be mentioned in the main text and other > considerations may be moved to the appendix to ease the reading. This is > obviously just a comment. > Thanks for the comment. I filed an issue to track this: https://github.com/MikeBishop/dns-alt-svc/issues/123 """ > As an example: > > _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. > svc4..example.net <http://svc4.example.net>. 7200 IN SVCB 3 ( > svc4.example.net. alpn="bar" > port="8004" esniconfig="..." ) > """ > > While many examples are useful for the understanding, they often provide > the > impression RRsets are in the same zone file. I am wondering if that would > not > be clarifying to show and mention zone files are different. Note this is > just a > feed back and your ar efree to ignore it. > > Filed as https://github.com/MikeBishop/dns-alt-svc/issues/124 > > 2.5. SVCB records: AliasForm > > It seems strange to me to have a single RRset type associated to different > functionalities, i.e. Alias and Service. I suspect that it is more > convenient > to have the same RRtype while requesting among different administrative > domains, but I would be happy to know the rationals for this design. I > have the > impression that alias form is used to indicates the next RRtype (in our > case, > SVCB) while service form indicates a terminal request. > Thanks. I filed an issue to track this question: https://github.com/MikeBishop/dns-alt-svc/issues/125 Having spent some time thinking about it in response to your question, I think that splitting the RR type into two would (1) at least double the load on recursive and authoritative servers, and (2) not actually result in any simplification, because ServiceForm lookups require chasing AliasForm records. """ > The SvcDomainName MUST point to a domain name that contains another > SVCB record, address (AAAA and/or A) records, or both address records > and a ServiceForm SVCB record. > """ > > I have some issue parsing the sentence with the AND and OR, but I also > suspect > that the first SVCB refers to an Alias form. > I've opened a PR to simplify this sentence: https://github.com/MikeBishop/dns-alt-svc/pull/118 > The sentence above could be read as the owner of api.example.com pointing > to > svc4.example.net. need to check these conditions are met. > Yeah, I think that's accurate. If the conditions aren't met, api.example.com is going to stop working, so that's the person who cares about this. > I believe the > conditions need to be enforced by the owner of the SvcDomainName. The > confusion > may be due to the fact that SvcDomainName is both a key and an RDATA. > This requirement is really stating the obvious so I'm not too concerned about whose responsibility it is. I have the impression "." or the owner domain MUST NOT be used, but I do not > see this being mentioned, though I see it later. > We can clarify the processing rules here. """ > The AliasForm's primary purpose is to allow aliasing at the zone > apex, where CNAME is not allowed. For example, if an operator of > https://example.com wanted to point HTTPS requests to a service > operating at svc.example.net, they would publish a record such as: > > example.com. 3600 IN SVCB 0 svc.example.net. > > """ > > My understanding is that SVCB "solves" the apex issue by splitting the > query in > two parts with different RRtypes and a specific resolution. > For any given URI scheme, there is only one new RR type in this draft. Is there something we could clarify on this point? > I have the > impression that SRV would have achieved this as well. > I agree. We have a comparison with SRV here: https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-02#appendix-A.1 > I would suggest to have > one annex section dedicated to this apex issue/discussion.. The main > reason is > that it is recurrently being mentioned without really exposing the > problem. In > addition, I don't see this as the main motivation for SVCB. > > > """ > Note that the SVCB record's owner name MAY be the canonical name of a > CNAME record, and the SvcDomainName MAY be the owner of a CNAME > record. Clients and recursive resolvers MUST follow CNAMEs as > normal. > """ > > I am not sure this is should be mentioned in the main part of the document > and > maybe annex would be more appropriated. > > > 2.6.1. Special handling of "." for SvcDomainName in ServiceForm > > """ > (The SvcDomainName of an SVCB RR in AliasForm MUST > NOT have this value.) > """ > > It seems to me that section 2.5 is more adapted for this normative text. > OK, i've opened a PR to remove it: https://github.com/MikeBishop/dns-alt-svc/pull/119 > This section is the first time HTTPSSVC is mentionned. My interpretation of > HTTPSSVC is that HTTPS is mentiond in the RRtype because that information > is > not contained into the QNAME. My understanding is that using RRTypes was > discouraged though I might misinterpret 8556. > I wasn't able to find this reference. > 2.6.2. SvcFieldPriority > > This field is also part of the AliasForm and a specific description may > also be > described in the aliasform as to specify how to handle SVCB RRsets with 0 > and > non 0 SvcFieldPriority. > This has been changed in the -02 draft, so hopefully it's clearer now. > 3. Client behavior > > """ > > 1. Issue parallel AAAA/A and SVCB queries for the name HOST. The > answers for these may or may not include CNAME pointers before > reaching one or more of these records. > """ > > While AAAA/A is well understood, I believe that AAAA and A is more > accurate. > The problem with "AAAA and A" is that single-stack clients will not issue both AAAA and A queries. We can improve the phrasing but we shouldn't accidentally tell everyone to perform both queries. I believe he sentence "The answers... is not necessary, but I made that > comment > earlier. > > I have the impression that the behavior considers that either alias forms > or > service form are returned, but not necessarily when both forms are > returned. > Such scenario does not seems to me realistic for example to perform load > sharing/offload the traffic. It could also happen due to misconfiguration. > The > current text seems to state that as long as alias form are found,look for > the > alias form (transition from 2) to 3)). > That's correct. > It probably end up in having all > different possibilities, but I am wondering if this is what we always > want. It > is likely that 2) and 3) can be processed in parallel. > We can certainly consider other behaviors. However, I don't currently see any configuration where mixing AliasForm and ServiceForm records would be an advantage, and we would have to make sure that we are not increasing resolvers' workload for no reason. """ > If the > connection fails, the client MAY try to connect using values from > a lower-priority record. If none of the options succeed, the > client SHOULD connect to the origin server directly. > """ > > This seems to me more like an application policy rather than a DNS > resolution. > It's important to specify this because server operators depend on the client behavior when setting up their zones. If clients don't have this fallback behavior, that means server operators need to provide higher reliability and compatibility in their SVCB endpoints. > > """ > Some important optimizations are discussed in Section 5 to avoid > additional latency in comparison to ordinary AAAA/A lookups. > """ > > I think that reduced is more accurate than avoided as, if I understood > correctly, when an alias is returned most likely another request follows. > With a conforming resolver and client-side caching (as specified in Section 5), clients never need to perform a follow-up query. Recursive resolution can be slower when caches are cold, but only if the zone owner adds a layer of indirection, which SVCB enables but does not require. """ > When responding to a query that includes the DNSSEC OK bit > ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers > MUST accompany each RRSet in the Additional section with the same > DNSSEC-related records that it would send when providing that RRSet > as an Answer. > """ > > This seems like the normal processing. > Yes, that's the idea. It's not clear to me that this is mandatory if we don't specify it. With DNSSEC and parameters that includes keys, it might happen that response > may be large and that the server may select some responses to put in the > additional data. Some selection algorithms could be provided and DNSSEC > protected RRsets should be given a preference - though this won't be the > only > criteria. > The situation where a single ServiceForm RRSet refers to domains of which some are signed and some are not seems pathological, so I'm not inclined to propose an optimization for it. If the zone owner wants to prefer the signed zones, they can give them higher SvcFieldPriority. > > """ > If none of the SVCB records are consistent with any active or in- > progress connection, clients must proceed as described in Step 3 of > the procedure in Section 3. > """ > > I think a normative MUST woudl be more accurate. > > > 7. Using SVCB with HTTPS and HTTP > > """ > Note that none of these forms alter the HTTPS origin or authority. > For example, clients MUST continue to validate TLS certificate > hostnames based on the origin host. > """ > > Just to clarify for myself, the TLS certificate on svc4.example.net will > use > example.com. > Yes. 7.4. HTTP Strict Transport Security > > I am wondering if that would be possible to make https the default scheme > and > considering http scheme as https with alpn set to null. > That sounds like an HTTPS->HTTP downgrade attack that can be executed by the recursive resolver. On Thu, Feb 27, 2020 at 11:48 AM Daniel Migault <mglt.i...@gmail.com> wrote: > Hi, > > I read draft-ietf-dnsop-svcb-httpssvc-01. Please find find some comments > (with my questions) below I had while reading linearly the document. I hope > this will help. > > Yours, > Daniel > > section 1.1 > > _8765._baz.api.example.com. 7200 IN SVCB 0 svc4-baz.example.net. > > > In my opinion, the mechanism that derives QNAME needs to be refined or > maybe > the terminology being clarified. > > a) The current document describes how to generate the QNAME from an URI. > The > QNAME contains a port number while some scheme do not allow or specify port > subcomponent. Not having the port specified could be particularly useful to > provide secure transport for schemes that are not necessarily secure for > example. One the other hand, a scheme that specify a port, may not > necessarily > need to have it specified twined in the QNAME. I would be rather inclined > to > have the port optional maybe at the expense of an additional RRset, but > need > more thoughts. > > b) It is also unclear to me why HTTPS:443 or HTTP:80 has a specific > convention. > The convention tales place for the DNS resolution of a authority as > opposed to > the DNS resolution of a FQDN. One possible reason I see could would be to > prevent having a distinction between http and https (which could be done > otherwise for example using alpn), but I am wondering if there are other > rationale. So far, I do not see the need for a exception for the > derivation of > the QNAME (nor for using a specific RRtype). > > c) The current document, mentions several time HTTP service. The term > service > seems to me ambiguous as it has been defined for the DNS service based > discovery in which case it means a web page. It seems to me preferable we > keep > the scope of URI scheme and port authority. As a side note, when scheme is > thought as a service, the convention adopted by the document slightly > differs > from the DNS based service Discovery which would use _baz._udp or > eventually > _baz._tcp. The current approach may be simpler.. I would think this is > mostly a > terminology issue. > > > section 2.3 > > """ > Protocol mappings for SVCB MAY remove the port or replace it with > other protocol-specific information, but MUST retain the scheme in > the QNAME. > """ > > I understand that for any scheme, a definition of how scheme and port > should be > defined when using SVBC. If that is correct, I would rather see that the > other > way around, that is SVBC defining from the scheme definition the QNAME > derivation. The term MAY also suggest different interpretation will be > permitted, which could affect interoperability. > > """ > When a prior CNAME or SVCB record has aliased to an SVCB record, each > RR shall be returned under its own owner name. > """ > > If I am not misinterpreting this, this seems to be the natural way CNAME > works > and I am wondering if the text should not be removed from this section. My > general comment is that the text refers too much to CNAME. Probably only > the > fall back function of CNAME should be mentioned in the main text and other > considerations may be moved to the appendix to ease the reading. This is > obviously just a comment. > > > """ > As an example: > > _8443._foo.api.example.com. 7200 IN SVCB 0 svc4.example.net. > svc4..example.net <http://svc4.example.net>. 7200 IN SVCB 3 ( > svc4.example.net. alpn="bar" > port="8004" esniconfig="..." ) > """ > > While many examples are useful for the understanding, they often provide > the > impression RRsets are in the same zone file. I am wondering if that would > not > be clarifying to show and mention zone files are different. Note this is > just a > feed back and your ar efree to ignore it. > > > 2.5. SVCB records: AliasForm > > It seems strange to me to have a single RRset type associated to different > functionalities, i.e. Alias and Service. I suspect that it is more > convenient > to have the same RRtype while requesting among different administrative > domains, but I would be happy to know the rationals for this design. I > have the > impression that alias form is used to indicates the next RRtype (in our > case, > SVCB) while service form indicates a terminal request. > > """ > The SvcDomainName MUST point to a domain name that contains another > SVCB record, address (AAAA and/or A) records, or both address records > and a ServiceForm SVCB record. > """ > > I have some issue parsing the sentence with the AND and OR, but I also > suspect > that the first SVCB refers to an Alias form. > > The sentence above could be read as the owner of api.example.com pointing > to > svc4.example.net. need to check these conditions are met. I believe the > conditions need to be enforced by the owner of the SvcDomainName. The > confusion > may be due to the fact that SvcDomainName is both a key and an RDATA. > > I have the impression "." or the owner domain MUST NOT be used, but I do > not > see this being mentioned, though I see it later. > > """ > The AliasForm's primary purpose is to allow aliasing at the zone > apex, where CNAME is not allowed. For example, if an operator of > https://example.com wanted to point HTTPS requests to a service > operating at svc.example.net, they would publish a record such as: > > example.com. 3600 IN SVCB 0 svc.example.net. > > """ > > My understanding is that SVCB "solves" the apex issue by splitting the > query in > two parts with different RRtypes and a specific resolution. I have the > impression that SRV would have achieved this as well. I would suggest to > have > one annex section dedicated to this apex issue/discussion.. The main > reason is > that it is recurrently being mentioned without really exposing the > problem. In > addition, I don't see this as the main motivation for SVCB. > > > """ > Note that the SVCB record's owner name MAY be the canonical name of a > CNAME record, and the SvcDomainName MAY be the owner of a CNAME > record. Clients and recursive resolvers MUST follow CNAMEs as > normal. > """ > > I am not sure this is should be mentioned in the main part of the document > and > maybe annex would be more appropriated. > > > 2.6.1. Special handling of "." for SvcDomainName in ServiceForm > > """ > (The SvcDomainName of an SVCB RR in AliasForm MUST > NOT have this value.) > """ > > It seems to me that section 2.5 is more adapted for this normative text. > > This section is the first time HTTPSSVC is mentionned. My interpretation of > HTTPSSVC is that HTTPS is mentiond in the RRtype because that information > is > not contained into the QNAME. My understanding is that using RRTypes was > discouraged though I might misinterpret 8556. > > > 2.6.2. SvcFieldPriority > > This field is also part of the AliasForm and a specific description may > also be > described in the aliasform as to specify how to handle SVCB RRsets with 0 > and > non 0 SvcFieldPriority. > > 3. Client behavior > > """ > > 1. Issue parallel AAAA/A and SVCB queries for the name HOST. The > answers for these may or may not include CNAME pointers before > reaching one or more of these records. > """ > > While AAAA/A is well understood, I believe that AAAA and A is more > accurate. > > I believe he sentence "The answers... is not necessary, but I made that > comment > earlier. > > I have the impression that the behavior considers that either alias forms > or > service form are returned, but not necessarily when both forms are > returned. > Such scenario does not seems to me realistic for example to perform load > sharing/offload the traffic. It could also happen due to misconfiguration. > The > current text seems to state that as long as alias form are found,look for > the > alias form (transition from 2) to 3)). It probably end up in having all > different possibilities, but I am wondering if this is what we always > want. It > is likely that 2) and 3) can be processed in parallel. > > """ > If the > connection fails, the client MAY try to connect using values from > a lower-priority record. If none of the options succeed, the > client SHOULD connect to the origin server directly. > """ > > This seems to me more like an application policy rather than a DNS > resolution. > > """ > Some important optimizations are discussed in Section 5 to avoid > additional latency in comparison to ordinary AAAA/A lookups. > """ > > I think that reduced is more accurate than avoided as, if I understood > correctly, when an alias is returned most likely another request follows. > > """ > When responding to a query that includes the DNSSEC OK bit > ([RFC3225]), DNSSEC-capable recursive and authoritative DNS servers > MUST accompany each RRSet in the Additional section with the same > DNSSEC-related records that it would send when providing that RRSet > as an Answer. > """ > > This seems like the normal processing. > > With DNSSEC and parameters that includes keys, it might happen that > response > may be large and that the server may select some responses to put in the > additional data. Some selection algorithms could be provided and DNSSEC > protected RRsets should be given a preference - though this won't be the > only > criteria. > > > """ > If none of the SVCB records are consistent with any active or in- > progress connection, clients must proceed as described in Step 3 of > the procedure in Section 3. > """ > > I think a normative MUST woudl be more accurate. > > > 7. Using SVCB with HTTPS and HTTP > > """ > Note that none of these forms alter the HTTPS origin or authority. > For example, clients MUST continue to validate TLS certificate > hostnames based on the origin host. > """ > > Just to clarify for myself, the TLS certificate on svc4.example.net will > use > example.com. > > > 7.4. HTTP Strict Transport Security > > I am wondering if that would be possible to make https the default scheme > and > considering http scheme as https with alpn set to null. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
