Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-httpssvc-02.txt

[Patrick McManus <[e-mail]>]

another positive feature of ports in this record is that it provides some
address space independent of the origin security model of the URI. By this
I mean that https://www.foo.com(implicit :443) and https://www.foo.com:555
are different origins with different web security boundaries. While two
different httpssvc records for 443 and 555 (both for  https:// www.foo.com)
are in the same origin.. this level of indirection can be used for A/B
testing or even for encoding load balancing information in a IP constrained
space. Just like the address is distinct from the URL, the port separates
the 'what' from the 'how' and that's good.

On Mon, Mar 9, 2020 at 10:42 PM Erik Nygren <[e-mail]> wrote:

> On Mon, Mar 9, 2020 at 10:32 PM Paul Vixie <[e-mail]> wrote:
>
>> On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote:
>> > It occurs to me that I hit "publish" on this draft without updating the
>> > release notes, so I'll mention some of the many changes since -01 here
>> > instead:
>> >
>> >  ...
>> >
>> > As always, please review and send comments.  We also expect to do a
>> > presentation on this draft (remotely) in the DNSOP session.
>>
>> i propose that section 6.2 for "port", and all references to same, be
>> removed.
>>
>
> We discussed this some on one of our authors' calls following
> my seeing you allude to this a few weeks ago.
>
> The rationale for keeping port is that HTTPS is not just about the "web"
> use-case.
> While for Web use-cases it is common for most things to always tcp/443,
> there
> are plenty of non-"Web" use-cases (such as API calls in data centers,
> service meshes, etc.)
> where non-standard ports are commonly used.  I know that Tim keeps
> highlighting
> a desire to make sure we consider these use-cases.
>
> There's a default when port is left out (perhaps that should be clarified
> better?)
> but there are cases when being able to switch to an alternate port has
> value.
> Another case where this applies is QUIC/UDP where udp/443 is commonly
> used but where operators may wish to situationally use different ports.
>
> Adding a warning that the use of non-default ports could have
> operational challenges might be warranted.  (There are also
> some confused deputy risks around non-default ports for servers
> that don't validate the port in the Host header, but others convinced
> me that that's a problem for another day.)
>
> A closely related issue is this one:
>
> https://github.com/MikeBishop/dns-alt-svc/issues/111
>
> (regarding clarifying the default port.)
>
> Does this help address the concern?
> It's helpful to know the historical context.
>
>        Erik
>
>
>
>
>
>
>> this is:
>>
>> ---
>>
>> 6.2.  "port"
>>
>>    The "port" SvcParamKey defines the TCP or UDP port that should be
>>    used to contact this alternative service.
>>
>>    The presentation format of the SvcParamValue is a numeric value
>>    between 0 and 65535 inclusive.  Any other values (e.g. the empty
>>    value) are syntax errors.
>>
>>    The wire format of the SvcParamValue is the corresponding 2 octet
>>    numeric value in network byte order.
>>
>> ===
>>
>> in the SRV RR (from RFC 2782) we specified a port number as part of the
>> RData
>> because a client would otherwise have to have an up-to-date /etc/services
>> file
>> (or local equivalent) to know what (TCP) port number a listener would
>> listen
>> on, and this seemed archaic.
>>
>> for HTTPSSVC and SVCB, the service is a constant (HTTPS) and its
>> transport
>> layer port number (443) is known. inviting listener operators to specify
>> a
>> different port number will result in unpredictable (other than
>> wide-spread)
>> failures for those accessors behind NAT, firewalls, or ALG's.
>>
>> please leave out this legacy from DNS SRV as you go forward with HTTPSSVC.
>>
>> --
>> Paul
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>