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

[Erik Nygren <[e-mail]>]

We should also look at how and where we want to separate operational
guidance from what mechanisms are available.  Ideally we'd minimize
foot-guns
(hence the inclusion of a default transport, at least for the HTTPS
use-cases)
and we should have safe defaults, but I'm not sure to what degree
we want to prohibit people from configuring things that may make
sense in particular operational contexts.

(I keep pondering if we need an "HTTPOPS" working group to provide guidance
on topics like this, but I'm not sure we want to tackle that problem in
this draft.  ;-)

   Erik





On Tue, Mar 10, 2020 at 2:26 PM Patrick McManus <[e-mail]>
wrote:

> alt-svc is quite robust to reachability failures of the alternative
> origins should some client find itself on a network that filters full
> transit.
>
> This process is already existing technology (rfc 7838). From that
> perspective the DNS record is just a way to bootstrap it over DNS rather
> than the default host/port for the URI.
>
> -Patrick
>
>
> On Tue, Mar 10, 2020 at 12:24 PM Paul Vixie <[e-mail]> wrote:
>
>> On Tuesday, 10 March 2020 13:30:53 UTC Patrick McManus wrote:
>> > another positive feature of ports in this record is that it provides
>> some
>> > address space independent of the origin security model of the URI. By
>> this
>> > I mean that https://www.foo.com(implicit :443) and
>> https://www.foo.com:555
>> > are different origins with different web security boundaries. While two
>> > different httpssvc records for 443 and 555 (both for  https://
>> www.foo.com)
>> > are in the same origin.. this level of indirection can be used for A/B
>> > testing or even for encoding load balancing information in a IP
>> constrained
>> > space. Just like the address is distinct from the URL, the port
>> separates
>> > the 'what' from the 'how' and that's good.
>>
>> your reply above precisely demonstrates the risk offered by allowing a
>> service
>> operator to select a non-default port. please read my down-thread
>> response to
>> erik nygren and consider the non-reachability impacts of such selection
>> on far
>> edge managed private networks, who will only build NAT, AGM, or firewall
>> flow
>> state for permitted (in-policy) flows.
>>
>> there's a separate problem on retermination, but i'll address that in
>> quic-wg.
>>
>> --
>> Paul
>>
>>
>>