Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Erik Nygren]

Bringing (hopeful) closure to this thread, we've published -11:

Diff of the changes:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-11.txt

The only things included are the two changes agreed on in this thread.
(We did not include the "hostname" => "domain name" clarification
mentioned above as there wasn't any feedback on it, so it wasn't
clear that we had consensus from the WG and were trying to minimize the
changes
as much as possible.)

Hopefully this puts us back on track.  Thank you to Warren for guiding
us through this exception process.

Best, Erik





On Thu, Sep 29, 2022 at 9:16 AM Erik Nygren  wrote:

> One item discussed above that the authors would like to clarify is to be
> consistent
> about whether the alternative endpoint name (TargetName) is a hostname
> or a domain name.  In all but one place in the doc we refer to it as a
> "domain name"
> but there is one reference that calls it a "hostname".
>
> In particular in these current sentences:
>
> 1) An "alternative endpoint" is a hostname, port number, and other
> associated
>
> 2) TargetName: The domain name of either the alias target (for AliasMode)
> or the alternative endpoint (for ServiceMode).
>
> 3) TargetName is a  ({{!RFC1035, Section 5.1}}),
>
> 4) In AliasMode, the TargetName will be the name of a domain that resolves
> to SVCB,
>
> We'd like to change the first of these to be:
>
> 1) An "alternative endpoint" is a domain name, port number, and other
> associated
>
> for consistency with the rest.
>
> As this isn't explicitly covered in Warren's summary we thought it worth
> checking here as well:
> https://mailarchive.ietf.org/arch/msg/dnsop/LhEufm0a8IjoXZ_ck0b9RTSkDTc/
>
> Best, Erik
>
>
>
>
>
>
>
>
> On Mon, Sep 12, 2022 at 9:51 AM Warren Kumari  wrote:
>
>>
>> Hi all,
>>
>> Firstly, and most importantly, thank y'all for keeping this civil,
>> friendly and productive; I really appreciate it.
>>
>> I've (informally) checked with the IESG on the proposed change in the
>> PR and also including Erik's proposed operational note ("Some
>> implementations may not allow A or  records on names starting with an
>> underscore due to various interpretations of RFCs. This could be an
>> operational issue when the TargetName contains an attrleaf label, as well
>> as using an TargetName of "." when the owner name contains an attrleaf
>> label.") and everyone seems fine with it.
>>
>> So, I'm ask the authors to cut a new version with these changes in
>> (basically, accept the PR and add the proposed text) and I will then email
>> the IESG with a diff to get "official" consensus on the change.
>>
>> Dealing with process exception handling is always stressful, so thanks
>> all again for keeping this moving along nicely.
>> Also, a reminder that while we *can* make changes after approval (and
>> before RFC publication) we really really avoid doing so, and so this should
>> only happen under exceptional circumstances[0].
>>
>> W
>>
>> [0]: I'm not convinced that this situation rose to the "exceptional
>> circumstances" bar, but seeing as I'd already paused it (not knowing what
>> all the issues were) and because the changes are clarifications, I'm
>> willing to accepting it.
>>
>> On Thu, Sep 08, 2022 at 12:34 PM, Erik Nygren 
>> wrote:
>>
>>> There seem to be two topics:
>>>
>>> 1) Victor's clarification makes sense, although the wording is a little
>>> awkward and perhaps we can improve that sentence.
>>> The section was already implying that meaning (ie, that the fallback
>>> addition of the QNAME was for the AliasMode case)
>>> but clarifying this in a more normative way seems worthwhile and not
>>> a technical change.
>>> I'd propose we refine this PR and incorporate it as the "clarifying
>>> sentence" that Warren was willing to accept.
>>>
>>> 2) There is the issue of whether attrleaf labels are valid owner names
>>> for A/ records.
>>> This document does not seem like the place to land that, and it
>>> seems like it may be open for interpretation
>>> as different implementations may have interpreted it differently.
>>> If anything, we might add a non-normative sentence like:
>>>
>>>"Some implementations may not allow A or  records on names
>>> starting with an underscore
>>> due to various interpretations of RFCs. This could be an
>>> operational issue when the TargetName contains an attrleaf label,
>>> as well as using an TargetName of "." when the owner name
>>> contains an attrleaf label."
>>>
>>>This wouldn't be a normative change but just an operational warning
>>> --- would this be acceptable to include at this stage?
>>>Further clarification of this seems worth a draft in its own right
>>> since the existing RFCs are inconsistent
>>>on this topic and there is room for multiple interpretations, as
>>> shown in some implementations.
>>>
>>>
>>>
>>> On Thu, Sep 8, 2022 at 12:05 PM Paul Hoffman 
>>> wrote:
>>>
 On Sep 8, 2022, at 8:35 AM, Viktor 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Erik Nygren]

One item discussed above that the authors would like to clarify is to be
consistent
about whether the alternative endpoint name (TargetName) is a hostname
or a domain name.  In all but one place in the doc we refer to it as a
"domain name"
but there is one reference that calls it a "hostname".

In particular in these current sentences:

1) An "alternative endpoint" is a hostname, port number, and other
associated

2) TargetName: The domain name of either the alias target (for AliasMode)
or the alternative endpoint (for ServiceMode).

3) TargetName is a  ({{!RFC1035, Section 5.1}}),

4) In AliasMode, the TargetName will be the name of a domain that resolves
to SVCB,

We'd like to change the first of these to be:

1) An "alternative endpoint" is a domain name, port number, and other
associated

for consistency with the rest.

As this isn't explicitly covered in Warren's summary we thought it worth
checking here as well:
https://mailarchive.ietf.org/arch/msg/dnsop/LhEufm0a8IjoXZ_ck0b9RTSkDTc/

Best, Erik








On Mon, Sep 12, 2022 at 9:51 AM Warren Kumari  wrote:

>
> Hi all,
>
> Firstly, and most importantly, thank y'all for keeping this civil,
> friendly and productive; I really appreciate it.
>
> I've (informally) checked with the IESG on the proposed change in the
> PR and also including Erik's proposed operational note ("Some
> implementations may not allow A or  records on names starting with an
> underscore due to various interpretations of RFCs. This could be an
> operational issue when the TargetName contains an attrleaf label, as well
> as using an TargetName of "." when the owner name contains an attrleaf
> label.") and everyone seems fine with it.
>
> So, I'm ask the authors to cut a new version with these changes in
> (basically, accept the PR and add the proposed text) and I will then email
> the IESG with a diff to get "official" consensus on the change.
>
> Dealing with process exception handling is always stressful, so thanks all
> again for keeping this moving along nicely.
> Also, a reminder that while we *can* make changes after approval (and
> before RFC publication) we really really avoid doing so, and so this should
> only happen under exceptional circumstances[0].
>
> W
>
> [0]: I'm not convinced that this situation rose to the "exceptional
> circumstances" bar, but seeing as I'd already paused it (not knowing what
> all the issues were) and because the changes are clarifications, I'm
> willing to accepting it.
>
> On Thu, Sep 08, 2022 at 12:34 PM, Erik Nygren 
> wrote:
>
>> There seem to be two topics:
>>
>> 1) Victor's clarification makes sense, although the wording is a little
>> awkward and perhaps we can improve that sentence.
>> The section was already implying that meaning (ie, that the fallback
>> addition of the QNAME was for the AliasMode case)
>> but clarifying this in a more normative way seems worthwhile and not
>> a technical change.
>> I'd propose we refine this PR and incorporate it as the "clarifying
>> sentence" that Warren was willing to accept.
>>
>> 2) There is the issue of whether attrleaf labels are valid owner names
>> for A/ records.
>> This document does not seem like the place to land that, and it seems
>> like it may be open for interpretation
>> as different implementations may have interpreted it differently.  If
>> anything, we might add a non-normative sentence like:
>>
>>"Some implementations may not allow A or  records on names
>> starting with an underscore
>> due to various interpretations of RFCs. This could be an
>> operational issue when the TargetName contains an attrleaf label,
>> as well as using an TargetName of "." when the owner name
>> contains an attrleaf label."
>>
>>This wouldn't be a normative change but just an operational warning
>> --- would this be acceptable to include at this stage?
>>Further clarification of this seems worth a draft in its own right
>> since the existing RFCs are inconsistent
>>on this topic and there is room for multiple interpretations, as shown
>> in some implementations.
>>
>>
>>
>> On Thu, Sep 8, 2022 at 12:05 PM Paul Hoffman 
>> wrote:
>>
>>> On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni 
>>> wrote:
>>> > This is a bug fix, the proposed behaviour makes no sense when $QNAME
>>> > is the unaltered (attrleaf prefixed) starting point.  The current
>>> > meaning was not intended.  If the edit can be made without any
>>> > major process, just a note to the RFC editor, it'll save errata,
>>> > and possible confusion later.
>>>
>>> A technical change made after the IESG review requires, at a minimum,
>>> another IESG review. The IESG could ask for another IETF review, if they
>>> want. It's up to Warren, the responsible AD, to decide if that's "major
>>> process".
>>>
>>> --Paul Hoffman
>>>
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>> 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Warren Kumari]

Hi all,

Firstly, and most importantly, thank y'all for keeping this civil, friendly
and productive; I really appreciate it.

I've (informally) checked with the IESG on the proposed change in the
PR and also including Erik's proposed operational note ("Some
implementations may not allow A or  records on names starting with an
underscore due to various interpretations of RFCs. This could be an
operational issue when the TargetName contains an attrleaf label, as well
as using an TargetName of "." when the owner name contains an attrleaf
label.") and everyone seems fine with it.

So, I'm ask the authors to cut a new version with these changes in
(basically, accept the PR and add the proposed text) and I will then email
the IESG with a diff to get "official" consensus on the change.

Dealing with process exception handling is always stressful, so thanks all
again for keeping this moving along nicely.
Also, a reminder that while we *can* make changes after approval (and
before RFC publication) we really really avoid doing so, and so this should
only happen under exceptional circumstances[0].

W

[0]: I'm not convinced that this situation rose to the "exceptional
circumstances" bar, but seeing as I'd already paused it (not knowing what
all the issues were) and because the changes are clarifications, I'm
willing to accepting it.

On Thu, Sep 08, 2022 at 12:34 PM, Erik Nygren  wrote:

> There seem to be two topics:
>
> 1) Victor's clarification makes sense, although the wording is a little
> awkward and perhaps we can improve that sentence.
> The section was already implying that meaning (ie, that the fallback
> addition of the QNAME was for the AliasMode case)
> but clarifying this in a more normative way seems worthwhile and not a
> technical change.
> I'd propose we refine this PR and incorporate it as the "clarifying
> sentence" that Warren was willing to accept.
>
> 2) There is the issue of whether attrleaf labels are valid owner names for
> A/ records.
> This document does not seem like the place to land that, and it seems
> like it may be open for interpretation
> as different implementations may have interpreted it differently.  If
> anything, we might add a non-normative sentence like:
>
>"Some implementations may not allow A or  records on names
> starting with an underscore
> due to various interpretations of RFCs. This could be an
> operational issue when the TargetName contains an attrleaf label,
> as well as using an TargetName of "." when the owner name contains
> an attrleaf label."
>
>This wouldn't be a normative change but just an operational warning ---
> would this be acceptable to include at this stage?
>Further clarification of this seems worth a draft in its own right
> since the existing RFCs are inconsistent
>on this topic and there is room for multiple interpretations, as shown
> in some implementations.
>
>
>
> On Thu, Sep 8, 2022 at 12:05 PM Paul Hoffman 
> wrote:
>
>> On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni 
>> wrote:
>> > This is a bug fix, the proposed behaviour makes no sense when $QNAME
>> > is the unaltered (attrleaf prefixed) starting point.  The current
>> > meaning was not intended.  If the edit can be made without any
>> > major process, just a note to the RFC editor, it'll save errata,
>> > and possible confusion later.
>>
>> A technical change made after the IESG review requires, at a minimum,
>> another IESG review. The IESG could ask for another IETF review, if they
>> want. It's up to Warren, the responsible AD, to decide if that's "major
>> process".
>>
>> --Paul Hoffman
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Erik Nygren]

There seem to be two topics:

1) Victor's clarification makes sense, although the wording is a little
awkward and perhaps we can improve that sentence.
The section was already implying that meaning (ie, that the fallback
addition of the QNAME was for the AliasMode case)
but clarifying this in a more normative way seems worthwhile and not a
technical change.
I'd propose we refine this PR and incorporate it as the "clarifying
sentence" that Warren was willing to accept.

2) There is the issue of whether attrleaf labels are valid owner names for
A/ records.
This document does not seem like the place to land that, and it seems
like it may be open for interpretation
as different implementations may have interpreted it differently.  If
anything, we might add a non-normative sentence like:

   "Some implementations may not allow A or  records on names
starting with an underscore
due to various interpretations of RFCs. This could be an
operational issue when the TargetName contains an attrleaf label,
as well as using an TargetName of "." when the owner name contains
an attrleaf label."

   This wouldn't be a normative change but just an operational warning ---
would this be acceptable to include at this stage?
   Further clarification of this seems worth a draft in its own right since
the existing RFCs are inconsistent
   on this topic and there is room for multiple interpretations, as shown
in some implementations.



On Thu, Sep 8, 2022 at 12:05 PM Paul Hoffman  wrote:

> On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni 
> wrote:
> > This is a bug fix, the proposed behaviour makes no sense when $QNAME
> > is the unaltered (attrleaf prefixed) starting point.  The current
> > meaning was not intended.  If the edit can be made without any
> > major process, just a note to the RFC editor, it'll save errata,
> > and possible confusion later.
>
> A technical change made after the IESG review requires, at a minimum,
> another IESG review. The IESG could ask for another IETF review, if they
> want. It's up to Warren, the responsible AD, to decide if that's "major
> process".
>
> --Paul Hoffman
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Paul Hoffman]

On Sep 8, 2022, at 8:35 AM, Viktor Dukhovni  wrote:
> This is a bug fix, the proposed behaviour makes no sense when $QNAME
> is the unaltered (attrleaf prefixed) starting point.  The current
> meaning was not intended.  If the edit can be made without any
> major process, just a note to the RFC editor, it'll save errata,
> and possible confusion later.

A technical change made after the IESG review requires, at a minimum, another 
IESG review. The IESG could ask for another IETF review, if they want. It's up 
to Warren, the responsible AD, to decide if that's "major process". 

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Thu, Sep 08, 2022 at 03:06:45PM +, Paul Hoffman wrote:

> > If no AliasMode record was processed, then $QNAME would be the
> > origin name PLUS the prefix(es) of type attrleaf ( underscore
> > thingies). Those won't be legitimate A/ owner names (and
> > shouldn't exist), and if a client did that it would be harmful (to
> > the client), at least a little bit harmful (trying something that
> > won't work.)
> 
> If this proposed change is only for something that is a bit harmful to
> the client (trying something that won't work), then I don't think this
> reaches the bar for making a change after IETF and IESG evaluation.
> The amount of process work that is necessary to make this technical
> change far outweighs the advantage to clients who are unaware of the
> problem that this thread has exposed.

This is a bug fix, the proposed behaviour makes no sense when $QNAME
is the unaltered (attrleaf prefixed) starting point.  The current
meaning was not intended.  If the edit can be made without any
major process, just a note to the RFC editor, it'll save errata,
and possible confusion later.

The document is on hold anyway, the fix is elementary and obvious.  I am
not a process wonk, I'm happy to let those who are go at it.  With the
suggested change made, I'm done.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Paul Hoffman]

On Sep 7, 2022, at 8:29 PM, Brian Dickson  wrote:
> > Once SVCB resolution has concluded, whether successful or not,
> > +if at least one AliasMode record was processed,
> > SVCB-optional clients SHALL append to the priority list an
> > endpoint consisting of the final value of $QNAME, the authority
> > endpoint's port number, and no SvcParams.  (This endpoint will be
> > attempted before falling back to non-SVCB connection modes.  This ensures 
> > that
> > SVCB-optional clients will make use of an AliasMode record whose TargetName 
> > has
> > A and/or  records but no SVCB records.)
> 
>> What happens under the current wording, before the addition above? That is, 
>> if no AliasMode record was processed, is the addition along the lines of 
>> "you can only add this if you have it, and if no AliasMode record was 
>> processed, you don't have it"? Or does the addition solve the problem "if no 
>> AliasMode record was processed, the thing you append will be harmful"?
>> 
> Yes.
> 
> If no AliasMode record was processed, then $QNAME would be the origin name 
> PLUS the prefix(es) of type attrleaf ( underscore thingies). Those won't be 
> legitimate A/ owner names (and shouldn't exist), and if a client did that 
> it would be harmful (to the client), at least a little bit harmful (trying 
> something that won't work.)

If this proposed change is only for something that is a bit harmful to the 
client (trying something that won't work), then I don't think this reaches the 
bar for making a change after IETF and IESG evaluation. The amount of process 
work that is necessary to make this technical change far outweighs the 
advantage to clients who are unaware of the problem that this thread has 
exposed.

A draft with a discussion of this one problem would go a long way to alerting 
client authors of this problem. The same draft could also talk about the other 
issues that sparked this larger thread. Such a draft is not limited to "change 
this sentence to that": it could have a discussion of the various things that 
client developers are discovering.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Thu, Sep 08, 2022 at 02:08:27PM +1000, Martin Thomson wrote:

> On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote:
> > If no AliasMode record was processed, then $QNAME would be the origin 
> > name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those 
> > won't be legitimate A/ owner names (and shouldn't exist), and if a 
> > client did that it would be harmful (to the client), at least a little 
> > bit harmful (trying something that won't work.)
> 
> (FWIW, I had trouble parsing this last bit.)
> 
> Can the AliasMode record reference a name that includes attrleaf
> labels, such that this could be as non-functional as using the
> attrleaf-laden original $QNAME?

It can, but that would be a bad idea in general, unless one was
absolutely sure that there's a ServiceMode record at the target,
and that's all that the AliasMode record is for.  And if A/
records for the qname fail to be discovered should a fallback
be attempted, all's well, since none were expected.

This touches on the RFC1123 question, which I think the WG did not want
to tackle (as too late for a substantive change) at this time.

But in any case, wheh there were no AliasMode records, and we're
using SVCB attrleaf prefixes for the original $QNAME, there really
was no intention to try that $QNAME as a fallback, as confirmed by
Ben (IIRC upthread at some point).

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Wed, Sep 7, 2022 at 9:09 PM Martin Thomson  wrote:

>
>
> On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote:
> > If no AliasMode record was processed, then $QNAME would be the origin
> > name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those
> > won't be legitimate A/ owner names (and shouldn't exist), and if a
> > client did that it would be harmful (to the client), at least a little
> > bit harmful (trying something that won't work.)
>
> (FWIW, I had trouble parsing this last bit.)
>
> Can the AliasMode record reference a name that includes attrleaf labels,
> such that this could be as non-functional as using the attrleaf-laden
> original $QNAME?
>

It can, but that's a different case than the original thing (which will
always have them). Changing the text to handle that would be more
words/sentences than what Warren wants.

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Martin Thomson]

On Thu, Sep 8, 2022, at 13:29, Brian Dickson wrote:
> If no AliasMode record was processed, then $QNAME would be the origin 
> name PLUS the prefix(es) of type attrleaf ( underscore thingies). Those 
> won't be legitimate A/ owner names (and shouldn't exist), and if a 
> client did that it would be harmful (to the client), at least a little 
> bit harmful (trying something that won't work.)

(FWIW, I had trouble parsing this last bit.)

Can the AliasMode record reference a name that includes attrleaf labels, such 
that this could be as non-functional as using the attrleaf-laden original 
$QNAME?

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Wed, Sep 7, 2022 at 7:41 PM Paul Hoffman  wrote:

> On Sep 7, 2022, at 5:48 PM, Viktor Dukhovni 
> wrote:
> > Once SVCB resolution has concluded, whether successful or not,
> > +if at least one AliasMode record was processed,
> > SVCB-optional clients SHALL append to the priority list an
> > endpoint consisting of the final value of $QNAME, the authority
> > endpoint's port number, and no SvcParams.  (This endpoint will be
> > attempted before falling back to non-SVCB connection modes.  This
> ensures that
> > SVCB-optional clients will make use of an AliasMode record whose
> TargetName has
> > A and/or  records but no SVCB records.)
>
> What happens under the current wording, before the addition above? That
> is, if no AliasMode record was processed, is the addition along the lines
> of "you can only add this if you have it, and if no AliasMode record was
> processed, you don't have it"? Or does the addition solve the problem "if
> no AliasMode record was processed, the thing you append will be harmful"?
>

Yes.

If no AliasMode record was processed, then $QNAME would be the origin name
PLUS the prefix(es) of type attrleaf ( underscore thingies). Those won't be
legitimate A/ owner names (and shouldn't exist), and if a client did
that it would be harmful (to the client), at least a little bit harmful
(trying something that won't work.)

If instead of the initial $QNAME, the origin name (and port) are added to
the end of the list, that is literally the exact same thing as non-SVCB
connection mode, so adding that to the list would be moot.

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Paul Hoffman]

On Sep 7, 2022, at 5:48 PM, Viktor Dukhovni  wrote:
> Once SVCB resolution has concluded, whether successful or not,
> +if at least one AliasMode record was processed,
> SVCB-optional clients SHALL append to the priority list an
> endpoint consisting of the final value of $QNAME, the authority
> endpoint's port number, and no SvcParams.  (This endpoint will be
> attempted before falling back to non-SVCB connection modes.  This ensures that
> SVCB-optional clients will make use of an AliasMode record whose TargetName 
> has
> A and/or  records but no SVCB records.)

What happens under the current wording, before the addition above? That is, if 
no AliasMode record was processed, is the addition along the lines of "you can 
only add this if you have it, and if no AliasMode record was processed, you 
don't have it"? Or does the addition solve the problem "if no AliasMode record 
was processed, the thing you append will be harmful"?

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

> Yes, and catching COVID on Friday didn't help.  Will attempt to send a
> pull request for just the $QNAME fix shortly.

Making a pull request does not preclude also Cc'ing the list.  Which
is what I'm doing now and was planning to do in any case:

https://github.com/MikeBishop/dns-alt-svc/pull/399/files

--- a/draft-ietf-dnsop-svcb-https.md
+++ b/draft-ietf-dnsop-svcb-https.md
@@ -532,12 +532,13 @@ noted in {{client-failures}} and {{ech-client-behavior}}).

 SVCB-optional clients SHOULD issue in parallel any other DNS queries that might
 be needed for connection establishment if the SVCB record is absent, in order 
to minimize delay
 in that case and enable the optimizations discussed in {{optimizations}}.

 Once SVCB resolution has concluded, whether successful or not,
+if at least one AliasMode record was processed,
 SVCB-optional clients SHALL append to the priority list an
 endpoint consisting of the final value of $QNAME, the authority
 endpoint's port number, and no SvcParams.  (This endpoint will be
 attempted before falling back to non-SVCB connection modes.  This ensures that
 SVCB-optional clients will make use of an AliasMode record whose TargetName has
 A and/or  records but no SVCB records.)

-- 
VIktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Wed, Sep 07, 2022 at 03:36:16PM -0700, Warren Kumari wrote:

> I chatted with Viktor Dukhovni late last week, and he promised us a
> sentence to solve all that ails us… or, at least, a simple, clear, concise
> sentence which only clarifies what appears to have been intended.
> 
> I suspect that US Labor day vacation got in the way, but I hope to
> have it soon.  If not, I think we just stick with the original - 'tis
> not perfect, but all can be fixed in a -bis[0].

Yes, and catching COVID on Friday didn't help.  Will attempt to send a
pull request for just the $QNAME fix shortly.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Warren Kumari]

I chatted with Viktor Dukhovni late last week, and he promised us a
sentence to solve all that ails us… or, at least, a simple, clear, concise
sentence which only clarifies what appears to have been intended.

I suspect that US Labor day vacation got in the way, but I hope to have it
soon.
If not, I think we just stick with the original - 'tis not perfect, but all
can be fixed in a -bis[0].

W
[0]: Quick, someone put that on a t-shirt…



On Wed, Sep 07, 2022 at 5:20 PM, Ben Schwartz  wrote:

> As I noted earlier, changing the non-SVCB fallback recommendation to "MAY"
> would nominally make HTTPS-record deployment riskier.  I'm inclined to take
> the current approach (encouraging fallback when it is safe) for now, and
> perhaps revisit this question in a few years if operational experience
> shows it to be unnecessary.
>
> On Wed, Aug 31, 2022 at 11:00 PM Tommy Pauly  wrote:
>
> I don’t personally find this proposal to be an improvement for clarity.
>
> The fact that a client is SVCB-optional means, somewhat by definition,
> that they allow not using the SVCB results. Saying that the client “MAY”
> doesn’t really help; it’s the very definition of what SVCB-optional is. If
> the client doesn’t use non-SVCB connection modes at that point, then it is
> SVCB-reliant.
>
> Listing out the details of what a non-SVCB connection does (not using the
> information from the SVCB record) also seems redundant. It is more accurate
> to just say “don’t use anything from SVCB if SVCB didn’t work” rather than
> trying to list out what all of those details might be.
>
> Tommy
>
> On Aug 31, 2022, at 4:13 PM, Brian Dickson 
> wrote:
>
> So, here is my suggestion, for "a sentence (or possibly two) which only
> clarify what is already written?":
>
> In section 3:
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
>
> becomes:
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client MAY attempt to use non-SVCB
>connection modes, using the origin name (without prefixes),
>
>the authority endpoint's port number, and no SvcParams.
>
> (The original didn't use RFC 2119 language, but the list of failure modes
> in 3.1 leads to "MAY" being the most appropriate choice.)
>
> Let me know if that is good enough.
> (The rest can go into a -bis... how soon are we allowed to start a -bis
> document? The day of RFC publication? I'd like to start that as soon as
> possible, while everything is still fresh.)
>
> Brian
>
> On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari  wrote:
>
>
>
>
>
> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson  com> wrote:
>
> Here are some proposed text changes, per Warren's invitation to send text:
>
>
>
> Um, no.  Warren said: "can we craft a sentence (or possibly two) which
> only clarify what is already written?". This is a significantly larger set
> of changes than that. The Section 3 changes in particular are (IMO) much
> more than a clarification.
>
> These may or may not be good changes, but anything approaching that level
> of change would have to be in a -bis document…
>
> W
>
>
>
> In section 1.2, change:
>
> 2.  TargetName: The domain name of either the alias target (for
>AliasMode) or the alternative endpoint (for ServiceMode).
>
> to:
>
> 2.  TargetName: Either the domain name of the alias target (for
>AliasMode) or the host name of the alternative endpoint (for
> ServiceMode).
>
> In section 2.4.2, change:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records alongside this
>SVCB record, although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
> to:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records at the service
> name,
>although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
>
> In section 2.4.3, change:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters.
>
> to:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters. The TargetName MUST be a host name
>(as defined in [DNSTerm].)
>
> In section 3, the following changes are proposed; they introduce a new
> term LASTNAME to be used to disambiguate the $QNAME reference so as to
> remove ATTRLEAF prefixes from the appended target:
>
>
>1.  Let $QNAME be the service name plus appropriate prefixes for the

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Tommy Pauly]

I don’t personally find this proposal to be an improvement for clarity.

The fact that a client is SVCB-optional means, somewhat by definition, that 
they allow not using the SVCB results. Saying that the client “MAY” doesn’t 
really help; it’s the very definition of what SVCB-optional is. If the client 
doesn’t use non-SVCB connection modes at that point, then it is SVCB-reliant.

Listing out the details of what a non-SVCB connection does (not using the 
information from the SVCB record) also seems redundant. It is more accurate to 
just say “don’t use anything from SVCB if SVCB didn’t work” rather than trying 
to list out what all of those details might be.

Tommy

> On Aug 31, 2022, at 4:13 PM, Brian Dickson  
> wrote:
> 
> So, here is my suggestion, for "a sentence (or possibly two) which only 
> clarify what is already written?":
> 
> In section 3:
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
> becomes:
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client MAY attempt to use non-SVCB
>connection modes, using the origin name (without prefixes),
>the authority endpoint's port number, and no SvcParams.
> 
> (The original didn't use RFC 2119 language, but the list of failure modes in 
> 3.1 leads to "MAY" being the most appropriate choice.)
> 
> Let me know if that is good enough.
> (The rest can go into a -bis... how soon are we allowed to start a -bis 
> document? The day of RFC publication? I'd like to start that as soon as 
> possible, while everything is still fresh.)
> 
> Brian
> 
> On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari  > wrote:
>> 
>> 
>> 
>> 
>> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson 
>> mailto:brian.peter.dick...@gmail.com>> wrote:
>>> Here are some proposed text changes, per Warren's invitation to send text:
>> 
>> 
>> 
>> Um, no.  Warren said: "can we craft a sentence (or possibly two) which only 
>> clarify what is already written?". This is a significantly larger set of 
>> changes than that. The Section 3 changes in particular are (IMO) much more 
>> than a clarification. 
>> 
>> These may or may not be good changes, but anything approaching that level of 
>> change would have to be in a -bis document…
>> 
>> W
>> 
>> 
>>> 
>>> In section 1.2, change:
>>> 2.  TargetName: The domain name of either the alias target (for
>>>AliasMode) or the alternative endpoint (for ServiceMode).
>>> to:
>>> 2.  TargetName: Either the domain name of the alias target (for
>>>AliasMode) or the host name of the alternative endpoint (for 
>>> ServiceMode).
>>> 
>>> In section 2.4.2, change:
>>>As legacy clients will not know to use this record, service operators
>>>will likely need to retain fallback  and A records alongside this
>>>SVCB record, although in a common case the target of the SVCB record
>>>might offer better performance, and therefore would be preferable for
>>>clients implementing this specification to use.
>>> to:
>>>As legacy clients will not know to use this record, service operators
>>>will likely need to retain fallback  and A records at the service 
>>> name,
>>>although in a common case the target of the SVCB record
>>>might offer better performance, and therefore would be preferable for
>>>clients implementing this specification to use.
>>> 
>>> In section 2.4.3, change:
>>>In ServiceMode, the TargetName and SvcParams within each resource
>>>record associate an alternative endpoint for the service with its
>>>connection parameters.
>>> to:
>>>In ServiceMode, the TargetName and SvcParams within each resource
>>>record associate an alternative endpoint for the service with its
>>>connection parameters. The TargetName MUST be a host name
>>>(as defined in [DNSTerm].)
>>> 
>>> In section 3, the following changes are proposed; they introduce a new term 
>>> LASTNAME to be used to disambiguate the $QNAME reference so as to remove 
>>> ATTRLEAF prefixes from the appended target:
>>> 
>>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>>scheme (see Section 2.3).
>>> becomes:
>>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>>scheme (see Section 2.3). Let $LASTNAME be the service name without 
>>> any prefixes.
>>> 
>>> 
>>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>>following CNAMEs as normal), set $QNAME to its TargetName
>>>(without additional prefixes) and loop back to step 2, subject to
>>>chain length limits and loop detection heuristics (see
>>>Section 3.1).
>>> becomes:
>>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>>following CNAMEs as normal), set $QNAME to its TargetName
>>>(without additional prefixes), set 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

So, here is my suggestion, for "a sentence (or possibly two) which only
clarify what is already written?":

In section 3:

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client now attempts to use non-SVCB
   connection modes.

becomes:

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client MAY attempt to use non-SVCB
   connection modes, using the origin name (without prefixes),

   the authority endpoint's port number, and no SvcParams.

(The original didn't use RFC 2119 language, but the list of failure modes
in 3.1 leads to "MAY" being the most appropriate choice.)

Let me know if that is good enough.
(The rest can go into a -bis... how soon are we allowed to start a -bis
document? The day of RFC publication? I'd like to start that as soon as
possible, while everything is still fresh.)

Brian

On Wed, Aug 31, 2022 at 6:25 AM Warren Kumari  wrote:

>
>
>
>
> On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>> Here are some proposed text changes, per Warren's invitation to send text:
>>
>
>
> Um, no.  Warren said: "can we craft a sentence (or possibly two) which
> only clarify what is already written?". This is a significantly larger set
> of changes than that. The Section 3 changes in particular are (IMO) much
> more than a clarification.
>
> These may or may not be good changes, but anything approaching that level
> of change would have to be in a -bis document…
>
> W
>
>
>
>> In section 1.2, change:
>>
>> 2.  TargetName: The domain name of either the alias target (for
>>AliasMode) or the alternative endpoint (for ServiceMode).
>>
>> to:
>>
>> 2.  TargetName: Either the domain name of the alias target (for
>>AliasMode) or the host name of the alternative endpoint (for
>> ServiceMode).
>>
>> In section 2.4.2, change:
>>
>>As legacy clients will not know to use this record, service operators
>>will likely need to retain fallback  and A records alongside this
>>SVCB record, although in a common case the target of the SVCB record
>>might offer better performance, and therefore would be preferable for
>>clients implementing this specification to use.
>>
>> to:
>>
>>As legacy clients will not know to use this record, service operators
>>will likely need to retain fallback  and A records at the service
>> name,
>>although in a common case the target of the SVCB record
>>might offer better performance, and therefore would be preferable for
>>clients implementing this specification to use.
>>
>>
>> In section 2.4.3, change:
>>
>>In ServiceMode, the TargetName and SvcParams within each resource
>>record associate an alternative endpoint for the service with its
>>connection parameters.
>>
>> to:
>>
>>In ServiceMode, the TargetName and SvcParams within each resource
>>record associate an alternative endpoint for the service with its
>>connection parameters. The TargetName MUST be a host name
>>(as defined in [DNSTerm].)
>>
>> In section 3, the following changes are proposed; they introduce a new
>> term LASTNAME to be used to disambiguate the $QNAME reference so as to
>> remove ATTRLEAF prefixes from the appended target:
>>
>>
>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>scheme (see Section 2.3).
>>
>> becomes:
>>
>>1.  Let $QNAME be the service name plus appropriate prefixes for the
>>scheme (see Section 2.3). Let $LASTNAME be the service name
>> without any prefixes.
>>
>>
>>
>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>following CNAMEs as normal), set $QNAME to its TargetName
>>(without additional prefixes) and loop back to step 2, subject to
>>chain length limits and loop detection heuristics (see
>>Section 3.1).
>>
>> becomes:
>>
>>3.  If an AliasMode SVCB record is returned for $QNAME (after
>>following CNAMEs as normal), set $QNAME to its TargetName
>>(without additional prefixes), set $LASTNAME to this new $QNAME
>> and loop back to step 2, subject to
>>chain length limits and loop detection heuristics (see
>>Section 3.1).
>>
>>
>>Once SVCB resolution has concluded, whether successful or not, SVCB-
>>optional clients SHALL append to the priority list an endpoint
>>consisting of the final value of $QNAME, the authority endpoint's
>>port number, and no SvcParams.  (This endpoint will be attempted
>>before falling back to non-SVCB connection modes.  This ensures that
>>SVCB-optional clients will make use of an AliasMode record whose
>>TargetName has A and/or  records but no SVCB records.)
>>
>> becomes:
>>
>>Once SVCB resolution has concluded, whether successful or not, SVCB-
>>optional clients SHALL append to the priority list an endpoint
>>consisting of the final value of $LASTNAME, the 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Paul Hoffman]

Off-list:

> Can we "rescue" just the clarifications/corrections?

Yes, with an Internet Draft that would become an RFC later. Brian pretty much 
refuses to do this kind of thing, so you should consider doing it yourself.

--Paul

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Warren Kumari]

On Wed, Aug 31, 2022 at 4:39 AM, Brian Dickson <
brian.peter.dick...@gmail.com> wrote:

> Here are some proposed text changes, per Warren's invitation to send text:
>


Um, no.  Warren said: "can we craft a sentence (or possibly two) which only
clarify what is already written?". This is a significantly larger set of
changes than that. The Section 3 changes in particular are (IMO) much more
than a clarification.

These may or may not be good changes, but anything approaching that level
of change would have to be in a -bis document…

W



> In section 1.2, change:
>
> 2.  TargetName: The domain name of either the alias target (for
>AliasMode) or the alternative endpoint (for ServiceMode).
>
> to:
>
> 2.  TargetName: Either the domain name of the alias target (for
>AliasMode) or the host name of the alternative endpoint (for
> ServiceMode).
>
> In section 2.4.2, change:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records alongside this
>SVCB record, although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
> to:
>
>As legacy clients will not know to use this record, service operators
>will likely need to retain fallback  and A records at the service
> name,
>although in a common case the target of the SVCB record
>might offer better performance, and therefore would be preferable for
>clients implementing this specification to use.
>
>
> In section 2.4.3, change:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters.
>
> to:
>
>In ServiceMode, the TargetName and SvcParams within each resource
>record associate an alternative endpoint for the service with its
>connection parameters. The TargetName MUST be a host name
>(as defined in [DNSTerm].)
>
> In section 3, the following changes are proposed; they introduce a new
> term LASTNAME to be used to disambiguate the $QNAME reference so as to
> remove ATTRLEAF prefixes from the appended target:
>
>
>1.  Let $QNAME be the service name plus appropriate prefixes for the
>scheme (see Section 2.3).
>
> becomes:
>
>1.  Let $QNAME be the service name plus appropriate prefixes for the
>scheme (see Section 2.3). Let $LASTNAME be the service name without
> any prefixes.
>
>
>
>3.  If an AliasMode SVCB record is returned for $QNAME (after
>following CNAMEs as normal), set $QNAME to its TargetName
>(without additional prefixes) and loop back to step 2, subject to
>chain length limits and loop detection heuristics (see
>Section 3.1).
>
> becomes:
>
>3.  If an AliasMode SVCB record is returned for $QNAME (after
>following CNAMEs as normal), set $QNAME to its TargetName
>(without additional prefixes), set $LASTNAME to this new $QNAME and
> loop back to step 2, subject to
>chain length limits and loop detection heuristics (see
>Section 3.1).
>
>
>Once SVCB resolution has concluded, whether successful or not, SVCB-
>optional clients SHALL append to the priority list an endpoint
>consisting of the final value of $QNAME, the authority endpoint's
>port number, and no SvcParams.  (This endpoint will be attempted
>before falling back to non-SVCB connection modes.  This ensures that
>SVCB-optional clients will make use of an AliasMode record whose
>TargetName has A and/or  records but no SVCB records.)
>
> becomes:
>
>Once SVCB resolution has concluded, whether successful or not, SVCB-
>optional clients SHALL append to the priority list an endpoint
>consisting of the final value of $LASTNAME, the authority endpoint's
>port number, and no SvcParams.  (This endpoint will be attempted
>before falling back to non-SVCB connection modes.  This ensures that
>SVCB-optional clients will make use of an AliasMode record whose
>TargetName has A and/or  records but no SVCB records.)
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
>
> becomes:
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client MAY attempt to use non-SVCB
>connection modes, using the origin name (without prefixes),
>
>the authority endpoint's port number, and no SvcParams.
>
>
> One additional suggested addition to the end of section 3.1 is:
>
>If DNS responses are cryptographically protected, and at least
>one HTTPS AliasMode record has been received successfully,
>clients MAY apply Section 9.5 (HSTS equivalent) restrictions
>even when reverting to non-SVCB connection modes. Clients
>
>also MAY 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

Here are some proposed text changes, per Warren's invitation to send text:

In section 1.2, change:

2.  TargetName: The domain name of either the alias target (for
   AliasMode) or the alternative endpoint (for ServiceMode).

to:

2.  TargetName: Either the domain name of the alias target (for
   AliasMode) or the host name of the alternative endpoint (for
ServiceMode).

In section 2.4.2, change:

   As legacy clients will not know to use this record, service operators
   will likely need to retain fallback  and A records alongside this
   SVCB record, although in a common case the target of the SVCB record
   might offer better performance, and therefore would be preferable for
   clients implementing this specification to use.

to:

   As legacy clients will not know to use this record, service operators
   will likely need to retain fallback  and A records at the service
name,
   although in a common case the target of the SVCB record
   might offer better performance, and therefore would be preferable for
   clients implementing this specification to use.


In section 2.4.3, change:

   In ServiceMode, the TargetName and SvcParams within each resource
   record associate an alternative endpoint for the service with its
   connection parameters.

to:

   In ServiceMode, the TargetName and SvcParams within each resource
   record associate an alternative endpoint for the service with its
   connection parameters. The TargetName MUST be a host name
   (as defined in [DNSTerm].)

In section 3, the following changes are proposed; they introduce a new term
LASTNAME to be used to disambiguate the $QNAME reference so as to remove
ATTRLEAF prefixes from the appended target:


   1.  Let $QNAME be the service name plus appropriate prefixes for the
   scheme (see Section 2.3).

becomes:

   1.  Let $QNAME be the service name plus appropriate prefixes for the
   scheme (see Section 2.3). Let $LASTNAME be the service name without
any prefixes.



   3.  If an AliasMode SVCB record is returned for $QNAME (after
   following CNAMEs as normal), set $QNAME to its TargetName
   (without additional prefixes) and loop back to step 2, subject to
   chain length limits and loop detection heuristics (see
   Section 3.1).

becomes:

   3.  If an AliasMode SVCB record is returned for $QNAME (after
   following CNAMEs as normal), set $QNAME to its TargetName
   (without additional prefixes), set $LASTNAME to this new $QNAME and
loop back to step 2, subject to
   chain length limits and loop detection heuristics (see
   Section 3.1).


   Once SVCB resolution has concluded, whether successful or not, SVCB-
   optional clients SHALL append to the priority list an endpoint
   consisting of the final value of $QNAME, the authority endpoint's
   port number, and no SvcParams.  (This endpoint will be attempted
   before falling back to non-SVCB connection modes.  This ensures that
   SVCB-optional clients will make use of an AliasMode record whose
   TargetName has A and/or  records but no SVCB records.)

becomes:

   Once SVCB resolution has concluded, whether successful or not, SVCB-
   optional clients SHALL append to the priority list an endpoint
   consisting of the final value of $LASTNAME, the authority endpoint's
   port number, and no SvcParams.  (This endpoint will be attempted
   before falling back to non-SVCB connection modes.  This ensures that
   SVCB-optional clients will make use of an AliasMode record whose
   TargetName has A and/or  records but no SVCB records.)

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client now attempts to use non-SVCB
   connection modes.

becomes:

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client MAY attempt to use non-SVCB
   connection modes, using the origin name (without prefixes),

   the authority endpoint's port number, and no SvcParams.


One additional suggested addition to the end of section 3.1 is:

   If DNS responses are cryptographically protected, and at least
   one HTTPS AliasMode record has been received successfully,
   clients MAY apply Section 9.5 (HSTS equivalent) restrictions
   even when reverting to non-SVCB connection modes. Clients

   also MAY treat resolution or connection failures subsequent

   to the initial cryptographically protected AliasMode record

   as fatal.

[Brian's note: this last would provide some guidance to implementers of
clients: a signed HTTPS AliasMode record is a strong signal that the DNS
operator is discouraging fallback, albeit at a "MAY" level.]

NB: The 2.4.3 change could be removed as it is mostly independent, as could
the last addition to 3.1.
The 1.2 change is very minor, is not too important but presents a succinct
clarification on the hostname vs domain name thing.
The 2.4.2 change and section 3 changes together are fixes for the
prefix/no-prefix issue 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Sat, Aug 27, 2022 at 3:00 PM Ben Schwartz  wrote:

>
>
> On Fri, Aug 26, 2022 at 10:49 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>  Fail fast may not be appealing, but in some (probably the majority of)
>> cases, it may be the most correct option.
>>
>> It may also be the case that the zone owner knows whether this is the
>> case.
>> I think it is much more likely that explicitly declaring the situation
>> (if known) is more useful than having several billion clients independently
>> attempting to infer whether the first option will even work, let alone
>> provide a useful alternative to the second or third.
>>
>
> In fact, there is one way for the zone owner to disable fallback: enable
> ECH.  Fallback is not compatible with ECH, so ECH-aware clients will
> disable fallback when the ServiceMode records contain ECH.
>
>
Wait, what?

This whole discussion was raised from the perspective of zone owners
publishing AliasMode apex records.
Those owners would not be operating the CDN, which is the whole point of
using a CNAME or AliasMode.
I.e., the zone owner would be the one wanting to disable fallback, but
would not be in a position to do what you suggest.

The domain's contents are served via a CDN, where the CDN requires
delegation of control, most often with CNAME (or AliasMode at the apex).
The ServiceMode records are placed on the CDN operated zone (in order to
avoid the first connection to establish the AltSvc stuff).

The AliasMode record cannot be combined with ECH, since no SvcParams are
allowed. The zone owner is not using ServiceMode, that is the declared
assumption.

If that (ECH) is the only way to disable fallback, that's what the focused
discussion needed to elicit, and I think some slight adjustments are needed
to at least facilitate zone owners preventing fallback. The mechanism
doesn't need to be added to the draft, but likely would get put into a
separate draft or a -bis document. However, there needs to be some daylight
between the fallback method and the mandatory SVCB/HTTPS components, in
order to allow for that development.

BTW, the concern is less about singleton zone owners than it is about large
scale integrated DNS management of zones in order to accommodate CDN usage.

Note also, this issue is not strictly limited to vertical integration among
products/services of the DNS operator; there are large scale inter-provider
(DNS and other services) open partnerships (controlled by their mutual
customers) that have need for the programmatic ability to assign CDNs and
enable/disable fallback (if fallback is part of the specification).
(For those interested, the not-yet-an-IETF standard for interoperability
between DNS and service providers is Domain Connect. The intent is to
revive the draft for that, which previously lived in the REGEXT WG.)

I think converting the fallback in the draft into MAY, and having active
discussions, dev, test, and deployment on a voluntary basis outside of the
scope of the current draft, is the fastest path to solving the "no
fallback" signaling issue, and to getting the draft published (with a few
minor tweaks).

I'll review the other comments, as well as Warren and Viktor's recent
messages, and see if I can come up with some proposed text to make very
limited changes to the draft.

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Mon, Aug 29, 2022 at 09:32:24PM +, Warren Kumari wrote:

> > * For the rfc1123 section 2 topic, it may make sense to clarify the text
> >  to say "domain name" rather than "hostname":
> >> An "alternative endpoint" is a hostname, port number, and other
> >> associated instructions to the client on how to reach an instance
> >> of service.
> >   Everywhere else in the normative sections such as 1.2 and 2.1 we
> >   say that the TargetName is a "domain name" (aligned with the
> > clarification in rfc8499
> >   on the difference between host and domain names).
> 
> I think that the current is clear enough. I agree that it would probably
> have been better as 'domain name' if we had caught that at WGLC / IETF LC,
> but I think it would be gratuitous / not rise to the level of 'futzing
> after approval'...

I still suspect that the document's multiple explicit suggestions that
IP addresses can be reliably associated with _leaf labels is a mistake.
As pointed out, these will run into various barriers, and changing the
text to make this clear is IMHO warranted.

* The initial $QNAME (with _leaf prefixes) should not be used as a
  potential "hostname" to connect to (this is an inadvertent error,
  the intent was to only use $QNAME after one or more AliasMode
  records).

* If the final AliasMode target is an _leaf name, then it is likely not
  a viable TCP endpoint, and can only be used for further chained SVCB
  lookups.

* The target names in non AliasMode records must be valid hostnames.

I don't correcting the above issues change the intent of the draft,
though they could be material enough to bring it back for a quick fix of
at least this issue.

Whether any clarifications of failover (without material changes) are
also warranted is not on my list of essential todos.  I'd have chosen
less fuzzy semantics, but clearly that's not the consensus, which is
just fine.  Thanks all for a very productive exploration of these
late to surface topics.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Warren Kumari]

On Mon, Aug 29, 2022 at 12:33 PM, Erik Nygren  wrote:

> Catching up on this thread, I agree with Ben Schwartz, Tommy Pauly, and
> Eric Orth
> that the current behavior makes sense and that no fundamental technical
> change is needed.
>


I've been watching this thread and following along - it has been a
fascinating discussion, but I agree that there are no fundamental technical
changes needed — there is nothing here that falling into the "OMG! That
clearly doesn't work, 1+1 doesn't equal 17…" camp.

With that said, the fact that we have had this robust of a discussion shows
that there is ambiguity / different interpretations possible.

No matter what we do, odd faults and misconfigurations will happen and
> Postel's law applies.
> Client implementers will try and be liberal with what they accept (as long
> as doing so doesn't introduce
> security issues, such as if you know you have bad data), and even then
> some client implementers
> may ignore this and still try to be robust.
>
> On the "how to sell this behavior", beyond giving client implementers the
> ability
> to be robust, there will be clients not implementing SVCB/HTTPS RRs
> behavior for
> a long time to come, so fallbacks will be needed for a long time.  HTTPS
> RR in particular
> is specified as SVCB-optional.
>
> I think some confusion keeps coming from a desire to think of AliasMode
> SVCB RRs
> as "CNAMEs that can live at the apex" which they are not, even if they can
> help solve
> that problem.
>

Yes, that desire / area does seem to be a significant part of the confusion
- but we did already discuss this topic in the WG before WGLC, and nothing
seems to have changed.

Brian, if I understand it right your 301 redirect approach seems like a
> reasonable
> way to address the fallback and legacy client case (and as clients pick
> this up the need
> for those redirects should decrease).
>
> On paths forward on the draft as it stands to clarify without making
> significant technical changes (which I don't think are necessary):
>
> * Are there particular clarifications we can/should add to help make the
> current
>   behavior more clear to readers?  For example, would having some examples
>   of the failure cases (without changing the semantics) help?
>   Note that since the fallback behavior is a SHOULD not a MUST for
> clients,
>   it can't necessarily be relied upon.
>


… and that's what I'm trying to figure out — can we craft a sentence (or
possibly two) which only clarify what is already written? Like "When we
said 'Call me a taxi' we mean "Please summon a taxi", not "Ok, you are a
taxi!" "...



> * This might be too much of a technical change at this point,
>   but would it make sense to change the SHOULD to a MAY on client
>   fallback behavior?  Clients implementations may choose to ignore the
> SHOULD
>   so this doesn't change the contract.
>

Yes, I think that that would be too large of a change. If there was very
strong and clear consensus from the WG that that is *obviously* the right
thing to do we *could* do another WGLC and IETF LC *only* on that point,
but I really really don't see anything approaching that level of consensus
(nor do I think it is needed — SHOULD is very close to MAY in this case).


> * For the rfc1123 section 2 topic, it may make sense to clarify the text
>  to say "domain name" rather than "hostname":
>> An "alternative endpoint" is a hostname, port number, and other
>> associated instructions to the client on how to reach an instance
>> of service.
>   Everywhere else in the normative sections such as 1.2 and 2.1 we
>   say that the TargetName is a "domain name" (aligned with the
> clarification in rfc8499
>   on the difference between host and domain names).
>

I think that the current is clear enough. I agree that it would probably
have been better as 'domain name' if we had caught that at WGLC / IETF LC,
but I think it would be gratuitous / not rise to the level of 'futzing
after approval'...


> On the rfc1123s2 front. a corner-case that might be encountered is that
> Proxies might be confused by "When connecting using a SVCB record,
> clients MUST provide the final TargetName and port to the proxy"
> in the case where proxies don't expect a domain name (eg, with an
> underscore prefix).
> I don't know if there is any warning we should provide about this
> corner-case,
> or cover that in the future if it turns out to be a problem?
>
>
> For the future, there are subsequent drafts that could be introduced:
>
> * We could add an optional "nofallback" SvcParam to AliasMode as Brian
> suggests,
>   but in a future draft. (This would be the first SvcParam on AliasMode,
> but they are allowed
>   and introducing them might help prevent ossification of this extension
> point.)
>


Yup, this seems like a fine thing to consider putting in a -bis / Updates:
document.

* Introducing an optional "Alt-Used" equivalent (eg, "Service-Used")
>   that provides information about the SVCB/HTTPS RR path 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Mon, Aug 29, 2022 at 12:33:55PM -0400, Erik Nygren wrote:

> On paths forward on the draft as it stands to clarify without making
> significant technical changes (which I don't think are necessary):
> 
> * Are there particular clarifications we can/should add to help make
> the current behavior more clear to readers?  For example, would having
> some examples of the failure cases (without changing the semantics)
> help?  Note that since the fallback behavior is a SHOULD not a MUST
> for clients, it can't necessarily be relied upon.


Likely so, especially to illustrate:

* SVCB/HTTPS lookup failure in the initial SVCB query (i.e. not 
NOERROR/NODATA
  or NXDOMAIN).

* SVCB/HTTPS lookup failure after some non-zero number of AliasMode records
  that result in a new target $QNAME.

* A/ lookup failure of the "final" target name (does this lookup still
  happen if SVCB/HTTPS lookup fails after a non-zero number of
  AliasMode records are processed?)

* Connection failure to some or all of the targets/ports resolved via 
SVCB/HTTPS
  records (should/may happy eyeballs probe the resolved SVCB/HTTPS
  targets in parallel with the fallback original name or $QNAME
  fallback?)

Clarify which $QNAME is appended to the target list as a fallback.


> * This might be too much of a technical change at this point,
>   but would it make sense to change the SHOULD to a MAY on client
>   fallback behavior?  Clients implementations may choose to ignore the
>   SHOULD so this doesn't change the contract.

Given the stated permissive stance (to quote Paul Vixie from another
forum/thread: browsers gonna browse), perhaps "MAY" is more appropriate.

> * For the rfc1123 section 2 topic, it may make sense to clarify the text
>  to say "domain name" rather than "hostname":
>
>> An "alternative endpoint" is a hostname, port number, and other
>> associated instructions to the client on how to reach an instance
>> of service.
>
>   Everywhere else in the normative sections such as 1.2 and 2.1 we say
>   that the TargetName is a "domain name" (aligned with the
>   clarification in rfc8499 on the difference between host and domain
>   names).
>
> On the rfc1123s2 front. a corner-case that might be encountered is
> that Proxies might be confused by "When connecting using a SVCB
> record, clients MUST provide the final TargetName and port to the
> proxy" in the case where proxies don't expect a domain name (eg, with
> an underscore prefix).  I don't know if there is any warning we should
> provide about this corner-case, or cover that in the future if it
> turns out to be a problem?

Just saying that it is a domain name does not fundamentally address the
issue, since the draft (almost RFC) in multiple places suggests that
even domain names adorned with attrleaf prefixes are potential owner
names of A/ records, which runs into conflict with 1123 (and as
you note potential issues with proxies, or other software that expects
"hostnames" as valid names for A/ records).

> For the future, there are subsequent drafts that could be introduced:
> 
> * We could add an optional "nofallback" SvcParam to AliasMode as Brian
> suggests, but in a future draft. (This would be the first SvcParam on
> AliasMode, but they are allowed and introducing them might help
> prevent ossification of this extension point.)

Sounds reasonable.

> * Introducing an optional "Alt-Used" equivalent (eg, "Service-Used")
>   that provides information about the SVCB/HTTPS RR path followed
>   would be very useful to service operators.  We got stuck on not
>   finding the right content vs privacy balance here, and experience
>   with Alt-Used is that not all clients will implement it regardless.
>   But if we had this and got enough clients to implement then it could
>   help address some of Brian's concerns about getting better
>   visibility in the fallback case.  (eg, "Service-Used: type=fallback"
>   as an HTTP header)

An interesting idea.  Certainly such signals can be helpful to operators
to detect problems and/or guage when infrastructure changes become
viable.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Erik Nygren]

Catching up on this thread, I agree with Ben Schwartz, Tommy Pauly, and
Eric Orth
that the current behavior makes sense and that no fundamental technical
change is needed.
No matter what we do, odd faults and misconfigurations will happen and
Postel's law applies.
Client implementers will try and be liberal with what they accept (as long
as doing so doesn't introduce
security issues, such as if you know you have bad data), and even then some
client implementers
may ignore this and still try to be robust.

On the "how to sell this behavior", beyond giving client implementers the
ability
to be robust, there will be clients not implementing SVCB/HTTPS RRs
behavior for
a long time to come, so fallbacks will be needed for a long time.  HTTPS RR
in particular
is specified as SVCB-optional.

I think some confusion keeps coming from a desire to think of AliasMode
SVCB RRs
as "CNAMEs that can live at the apex" which they are not, even if they can
help solve
that problem.  Brian, if I understand it right your 301 redirect approach
seems like a reasonable
way to address the fallback and legacy client case (and as clients pick
this up the need
for those redirects should decrease).

On paths forward on the draft as it stands to clarify without making
significant technical changes (which I don't think are necessary):

* Are there particular clarifications we can/should add to help make the
current
  behavior more clear to readers?  For example, would having some examples
  of the failure cases (without changing the semantics) help?
  Note that since the fallback behavior is a SHOULD not a MUST for clients,
  it can't necessarily be relied upon.

* This might be too much of a technical change at this point,
  but would it make sense to change the SHOULD to a MAY on client
  fallback behavior?  Clients implementations may choose to ignore the
SHOULD
  so this doesn't change the contract.

* For the rfc1123 section 2 topic, it may make sense to clarify the text
 to say "domain name" rather than "hostname":
   > An "alternative endpoint" is a hostname, port number, and other
   > associated instructions to the client on how to reach an instance
   > of service.
  Everywhere else in the normative sections such as 1.2 and 2.1 we
  say that the TargetName is a "domain name" (aligned with the
clarification in rfc8499
  on the difference between host and domain names).

On the rfc1123s2 front. a corner-case that might be encountered is that
Proxies might be confused by "When connecting using a SVCB record,
clients MUST provide the final TargetName and port to the proxy"
in the case where proxies don't expect a domain name (eg, with an
underscore prefix).
I don't know if there is any warning we should provide about this
corner-case,
or cover that in the future if it turns out to be a problem?


For the future, there are subsequent drafts that could be introduced:

* We could add an optional "nofallback" SvcParam to AliasMode as Brian
suggests,
  but in a future draft. (This would be the first SvcParam on AliasMode,
but they are allowed
  and introducing them might help prevent ossification of this extension
point.)

* Introducing an optional "Alt-Used" equivalent (eg, "Service-Used")
  that provides information about the SVCB/HTTPS RR path followed would
  be very useful to service operators.  We got stuck on not finding the
right
  content vs privacy balance here, and experience with Alt-Used is that
  not all clients will implement it regardless.  But if we had this and got
  enough clients to implement then it could help address some of Brian's
concerns
  about getting better visibility in the fallback case.
  (eg, "Service-Used: type=fallback" as an HTTP header)

 Erik
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Fri, Aug 26, 2022 at 11:54 AM Tommy Pauly  wrote:

>
>
> On Aug 26, 2022, at 4:29 AM, Ben Schwartz  40google@dmarc.ietf.org> wrote:
>
> 
>
>
> On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni 
> wrote:
>
>> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:
>>
>> > Relatedly, the results presented by EKR [1] at the most recent DNSOP
>> > meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
>> > records through their local resolver.  To me, this implies that
>> functional
>> > origin endpoints are likely to be required even if client software gains
>> > SVCB/HTTPS support.
>>
>> This is why my suggested client behaviour was cognisant of this
>> impediment.
>>
>> - If the client's *initial* SVCB lookup succeeds, *then* fallback is
>>   no longer an option.
>>
>> - If initial SVCB resolution fails (SERVFAIL, timeout, ...)
>>   then the client behaves as though the SVCB record does not exist.
>>
>> This results in more predictable behaviour, without optimising for
>> failure.
>
>
> I don't think "more predictable" is really a desirable or achievable
> outcome in this case.  Sophisticated clients (e.g. web browsers for HTTP,
> iterative resolvers for DNS) tend to develop highly tuned heuristics and
> state machines in pursuit of performance and reliability within their
> particular constraints.  I think an instruction not to fall back in this
> case would likely be ignored.
>
>
> I definitely agree with all the points that Ben is making here and
> elsewhere. The practical realities of dealing with new record types, and
> the evolving heuristics on clients, will determine how the records are
> used.
>
> It makes sense for informational documents to talk about techniques and
> best practices—like an updated Happy Eyeballs algorithm to include SVCB
> logic, but that shouldn’t block anything in the base specification or add
> overly restrictive requirements today.
>
> Tommy
>
>
I don't disagree with your comment about "overly restrictive requirements"..

However,  if you can take a look at one of my responses, I go into
how/why *fallback
is itself an overly restrictive requirement.*

This draft, with fallback, asserts/requires that apex A/ records, if
they exist, MUST be used to serve the same service and content as the
corresponding HTTPS record.
This assertion/requirement is also exclusive of other potential
SVCB-compatible apex records' potential requirement for their own fallback
to A/ records.
Legacy support really needs to be stated as a "MAY", explicitly, and zone
owners MUST be able to publish A/ records used for other purposes (as
indeed they may already be doing.)

Legacy support is good, but cannot be a strict requirement for deployment
of HTTPS, IMNSHO. (The current draft, with fallback, makes it a strict
conditional requirement.)

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz  wrote:

> For now, I think it's better to keep the current guidance, in order to
> minimize the risk of disruptions as these new RR types begin to be deployed.
>

I have a small favor to ask.

Could you try to "sell" the guidance from the hypothetical perspective of
it not having been part of the draft?
I.e. if it was not already in the draft, and you were proposing the
fallback (after successful AliasMode response), is there a short pitch that
makes it compelling?

Consider also that there are roughly 3 million resolvers (with vastly
varying client bases), hundreds of millions of zones, and billions of
clients. The cross product is probably sparse, but definitely not super
sparse.
There is no sharing of information between clients, and they are all
implementing the logic from local knowledge only, correct?
How does this scale if a large proportion of fallback lookups don't/can't
result in success if the primary lookup fails?
On the client, on the resolver, on the authority server, on the apex web
server (at the fallback address), on the CDN?

Thanks,
Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz  wrote:

>
> Brian proposes a use case of serving only a warning message on the origin
> endpoint, in order to minimize the load on IP addresses that are likely
> hardcoded into a customer's zone.
>

So, the major update to add to this is:

   - We (GoDaddy) have revisited this approach, and are now considering a
   much better design (summary follows below)


The design we are considering is deployment of Web redirect servers (via
apex A/ records) which do HTTP 301 permanent redirect responses.
These would respond to connections to the apex domain ("example.com") and
redirect the client to a non-apex name ("www.example.com").
The non-apex name would have a CNAME to redirect to the actual delegated
authority.
The RDATA on the CNAME would be identical to the RDATA on the apex HTTPS
record.

Note the following:

   - This will provide legacy clients the same eventual connectivity as the
   HTTPS record, including connecting to the correct (aka "best") target node
   at the CNAME/HTTPS target name, since both are resolved by the client's
   resolver
   - Legacy clients will have a one-time latency penalty for the HTTP 301
   connection and redirect. This penalty is once per domain only, per client.
   - The apex A/, HTTPS, and www CNAME records are all cacheable, and
   likely to have long TTLs
   - The target name is identical, and client-resolver caching provides
   benefits to both legacy and HTTPS-aware clients.

Note also, the following:

   - The target of both the HTTPS and CNAME records are the same
   - Resolution failures or connection failures will have a shared fate,
   between legacy and HTTPS-aware clients
   - An HTTPS-aware client, which attempts to do the fallback procedure,
   will experience the legacy-mode delay due to the HTTP 301 rewrite, but will
   still end up hitting the same issue that triggered the fallback
  - In other words, for this publication scheme, fallback will NEVER
  achieve its desired/expected goal
  - Individual instances of fallback working due to temporary issues,
  would have had the same success achieved by merely retrying the
connection
  or resolution (tautologically!)

If we do deploy this, we will do so on all our customer domains using HTTPS.
This means that for those domains (in the millions or tens of millions),
the fallback in the draft will only result in added overhead while never
actually achieving any successful connections (due to shared fate between
legacy and HTTPS).

We know this will be the case for these domains.
The logical approach would be to do one of the following things:

   - Allow the domain owner to signal that fallback will not work, e.g.:
  - An AliasMode SvcParam (e.g. example.com HTTPS 0 mycdn.example.net
  nofallback)
  - or a third HTTPS "mode" record, to signal no fallback (e.g.
  example.com HTTPS 65534 . where 65534 is the "no fallback" mode
  signal, and "." is simply a placeholder domain needed for RRDATA
structural
  consistency)
  - Both of these would require significant changes to the draft, to
  clients, and to authority servers..
  - Strongly not recommended
   - Allow the domain owner to only supply fallback addresses explicitly,
   and in the absence of those, not do the fallback (e.g. using an attrleaf
   prefix label)
  - This is the "presence/absence is the signal" (e.g. _
  https_fallback.example.com A 192.0.2.1 // chosen from one of the RFC
  5737 blocks )
  - This is also extensible, since the attrleaf prefix would be
  (presumably) SVCB-record specific
  - HTTPS would have its own attrleaf prefix, and each new
  SVCB-compatible record would have its own attrleaf prefix
  - Would require changes to the draft, to clients, and to authority
  server zone publication automation (but not to the authority server
  software)
  - Not recommended
   - Remove fallback from the draft
  - Signaling is only needed if fallback is included in the draft
  - Much less work; only clients would require changes, and only to
  remove code/logic
  - Fail fast
  - Deterministic and reliable behavior
  - Interoperable across client implementations and server
  implementations
  - Still requires changes to the draft
  - Least of three "evils"

Removing the language from the draft does not force implementers to not do
their own thing. Individual client implementations could still do the
fallback thing, but would not be required to do so.
It does, however, put more responsibility on the implementers to respond to
issues raised if adverse effects result. It might be advisable to be a
user-configurable option, possibly off-by-default.
Implementers would not be able to deflect blame for problems via the "it's
what the RFC says" response, if problems do occur.



> Instead, the draft attempts to ensure that deploying and implementing the
> HTTPS record "does 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Fri, Aug 26, 2022 at 4:29 AM Ben Schwartz  wrote:

>
>
> On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni 
> wrote:
>
>> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:
>>
> Indeed it is a possible position to say that the Internet is not yet
>> ready for semantically distinct services seen by SVCB-aware and legacy
>> clients.
>
>
> In addition to the deployment concerns I've mentioned earlier, a
> deployment of this kind would be intrinsically insecure: a hostile
> intermediary could override the choice of which semantically distinct
> service is seen by the client.  That's another reason why this
> configuration is not permitted.
>

I don't think it is the case that it is not permitted.

Note that many/most of the cases in 3.1 do not account for one specific
permutation:

   - An apex AliasMode HTTPS record, with no prior or subsequent CNAMEs,
   and no subsequent AliasMode records, in a DNSSEC signed zone, which also
   has apex A/ records. All the records in the zone are signed.
   - It is literally impossible for a hostile intermediary to selectively
   block service, without the client having the ability to detect this (if the
   client is doing DNSSEC validation itself, or if the client is asking the
   upstream DNS resolver to do DNSSEC validation and return data with the AD
   bit set).
   - If the client detects any failure (including SERVFAIL), and the Chain
   length is 1, and the DNS lookups are cryptographically protected, the
   client MUST hard-fail (per the current spec).

This particular case appears to me (and I'd argue is also proveably)
intrinsically secure.

NB: When GoDaddy begins publishing HTTPS records in customer-managed DNS
zones, it will do so only with DNSSEC signed zones, using AliasMode records
with Chain length of 1, with or without apex A/ records (mostly likely
with).
(The intent of making DNSSEC widely available has previously been
discussed, so this isn't really news per se, except in the context of HTTPS
and section 3.1)

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz  wrote:


> (Also, Brian's analysis indicates that the origin hostname's address
> record TTL would bias the endpoint selection, but this is not correct.)
>

This statement intrigues me, and I think is highly relevant to the
discussion.

Could you explain further?

Is this non-bias the result of logic embedded in the draft that I have
overlooked?

Or is what you are referring to an implementation artifact within Chrome?

For purposes of focusing on the draft, I would like to limit this to things
in the draft; if it isn't in the draft, but it addresses the concerns
raised, the obvious answer is: please add it to the draft

   - The goal is to standardize the behavior, by explicitly including
   everything authority servers, resolvers, and clients need to do to
   interoperate with the same characteristics
   - If only some of the clients have this good behavior, but others do
   not, that is not good for the usability of HTTPS records
   - If this is added to the draft, and addresses the concerns, I may
   withdraw my objection (which would clear the draft for publication).
   - If it is already in the draft, but not obvious, then cleaning up the
   text to make it obvious, is something I think would be in everyone's
   interest.

Thanks in advance,
Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Thu, Aug 25, 2022 at 1:35 PM Ben Schwartz  wrote:

> Thanks to Brian, Viktor, and others for the very close review, as always.
> While I disagree with many of the claims made here, it's clear that some of
> the text has proven confusing.  I'm not familiar with the process rules
> given the draft's current state, but perhaps we can improve clarity with
> some modest revisions.  I'll try to keep that discussion separate.
>
> The key text for this discussion is in Section 3:
>
>If the client is SVCB-optional, and connecting using this list of
>endpoints has failed, the client now attempts to use non-SVCB
>connection modes.
>
> I believe most reviewers correctly understood this to mean that, if all
> else fails, you can connect to https://www.example.com/ using the  or
> A records on www.example.com, as usual.
>

One of the problems here is that the term "connection mode" is somewhat
ambiguous.
Does that refer to the HTTP mode, or DNS queries?

It could mean, "connect via HTTP using no SvcParameter" elements, i.e.
connects using vanilla HTTPS, using the last $QNAME.
It does not explicitly identify the connection target address.
(e.g. if there was not a DNS resolution failure, the connection failure
should be "hard" rather than "soft", and only the final $QNAME should be
used, vs explicitly stating "non-SVCB connection to addresses found by
resolving A/ records at ").



> The logic is simple: this draft does not make "HTTPS Record" support
> mandatory for HTTP clients.
>

What the current version of the draft does, is it asserts HTTP ownership of
any apex A/ records, something that was not the case prior to this
draft.

   - The fallback logic assumes that A/ address records MUST serve the
   same content as the HTTPS record
   - This effectively forces the owner to choose between "no A/
   record", or "have A/ records that require maintenance (if the are the
   result of doing DNS resolution on the HTTPS target)", or "do some other
   thing that serves the same HTTP content".
   - This means that for as long as the current draft is published as-is,
   and until it is given a -bis treatment or is deprecated, no other use of
   apex A/ records is possible (without impacting HTTPS-aware clients)
  - This also means no OTHER SVCB-compatible apex RRTYPE can be used
  that also requires fallback to A/ records, as those would
conflict with
  the HTTPS usage

The "www" name under any given domain, is by convention the owner name of
HTTP and HTTPS services, but is not strictly required. The expectation that
"www" is a web server is reasonable, and that CNAME and AliasMode records
would be interchangeable. Other (non-HTTPS) SVCB-compatible records would
not be expected to co-exist at the "www" name.
The same is not true for the apex name, recent trends to the contrary
notwithstanding.


> Thus, HTTP servers are still required to publish functional address
> records on the origin hostname, as usual.
>

This is *only* true if the HTTPS record is added to a pre-existing address
record's origin hostname.
There is no requirement for a pre-existing address; it is possible (indeed
likely) that a significant proportion of HTTPS records are published where
no pre-existing address records existed.
There might be a simultaneous deployment of A/ records for the purposes
of serving (some kind of content) to legacy clients, which is a distinct
use case from the pre-existing same-content A/ use case.


> (Similar logic applies to any other pre-existing protocol that may be used
> with SVCB.)
>

I don't follow this logic, could you explain, please?

Suppose (at some future point) there are half a dozen SVCB-compatible
RRTYPEs, all published at a zone apex.
Which service (corresponding to which RRTYPE) is the pre-existing protocol
served at the apex A/ address(es)?
There can be ONLY one protocol attached to an address, unless the address
is forced to serve many protocols simultaneously (not an ideal situation at
all).


> Since these records are required to be present and working, we can hardly
> forbid clients from using them.
>

Except, they aren't *required* to be present and working, at least not
within the scope of this draft.
What is true, is that IF they are present, they are *expected* (not
required) to be working.
(The logic is backwards; it is B->A, not A->B. Plus, the negation of X->Y
is (!Y)->(!X), rather than (!X)->(!Y).)

This pre-existence assumption omits an entirely different logic branch:
green-field deployments using HTTPS (where no current records of any type
existed, or existed for other services, including "parking" generic pages,
"cash parking", etc.).

GoDaddy provides managed DNS hosting (which in some cases involves add-on
services that are provisioned into the customer's zone), for tens of
millions of domains. A significant portion of those will be updated to use
HTTPS in the near future, presuming what gets published will work correctly.

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Tommy Pauly]

On Aug 26, 2022, at 4:29 AM, Ben Schwartz  wrote:On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni  wrote:On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:

> Relatedly, the results presented by EKR [1] at the most recent DNSOP
> meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
> records through their local resolver.  To me, this implies that functional
> origin endpoints are likely to be required even if client software gains
> SVCB/HTTPS support.

This is why my suggested client behaviour was cognisant of this impediment.

    - If the client's *initial* SVCB lookup succeeds, *then* fallback is
      no longer an option.

    - If initial SVCB resolution fails (SERVFAIL, timeout, ...)
      then the client behaves as though the SVCB record does not exist.

This results in more predictable behaviour, without optimising for
failure.I don't think "more predictable" is really a desirable or achievable outcome in this case.  Sophisticated clients (e.g. web browsers for HTTP, iterative resolvers for DNS) tend to develop highly tuned heuristics and state machines in pursuit of performance and reliability within their particular constraints.  I think an instruction not to fall back in this case would likely be ignored.  I definitely agree with all the points that Ben is making here and elsewhere. The practical realities of dealing with new record types, and the evolving heuristics on clients, will determine how the records are used. It makes sense for informational documents to talk about techniques and best practices—like an updated Happy Eyeballs algorithm to include SVCB logic, but that shouldn’t block anything in the base specification or add overly restrictive requirements today. TommyIt also strikes me as questionable from a standards perspective: if SVCB itself is optional, surely the client always has the right to change its mind and disable its support for SVCB?   If the origin zone directs the service elsewhere, and there
are no last-mile DNS lookup roadblocks, then the protocol becomes
"reliable" (optimises for success and predictability, over fallback
recovery leading to potentially/eventually undesirable outcomes).


> I believe this balance could be revisited in several years' time, if "HTTPS
> Record" support becomes sufficiently universal.

Indeed it is a possible position to say that the Internet is not yet
ready for semantically distinct services seen by SVCB-aware and legacy
clients.In addition to the deployment concerns I've mentioned earlier, a deployment of this kind would be intrinsically insecure: a hostile intermediary could override the choice of which semantically distinct service is seen by the client.  That's another reason why this configuration is not permitted.  But I think that latching on success of the initial lookup
largely addresses the present impediments to reliance on SVCB.The same could have been said of EDNS0 fallback, but the IETF wisely did not attempt to leap straight to that configuration in the initial RFC.  Instead, we gave client implementors plenty of room to tune their own fallback behaviors, and came back to tighten the system up much later when it became safe to do so.
> Viktor notes with concern that AliasMode is a "non-deterministic
> redirect".  Instead, the draft attempts to model the client behavior as a
> preference ordered stack of endpoints:
> 

I also noted an issue around the initial $QNAME having prefix labels (in
the case of SVCB rather than HTTPS), and so this is likely not the name
you want appended as a fallback to the target list.Indeed, I think this is a clarity/precision problem that we should correct.  Specifically, this "final value of $QNAME" endpoint is only used if it is not the initial value of $QNAME (i.e. if an AliasMode record was found).
Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to
preclude publishing A/ records there, making some of the example
configurations in the draft impractical.I don't agree with this reading of RFC 1123.  There is no requirement that address records only be placed on hostnames, and there is no requirement that TargetName be a hostname.  If I were making an argument here, it might be about compatibility with RFC 8553 (Attrleaf), but hopefully this is mostly moot per the above.
___DNSOP mailing listDNSOP@ietf.orghttps://www.ietf.org/mailman/listinfo/dnsop___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Fri, Aug 26, 2022 at 07:29:06AM -0400, Ben Schwartz wrote:

> > I also noted an issue around the initial $QNAME having prefix labels (in
> > the case of SVCB rather than HTTPS), and so this is likely not the name
> > you want appended as a fallback to the target list.
> >
> 
> Indeed, I think this is a clarity/precision problem that we should
> correct.  Specifically, this "final value of $QNAME" endpoint is only used
> if it is not the initial value of $QNAME (i.e. if an AliasMode record was
> found).

Yes, and I think this was mostly an editorial omission, I seems unlikely
that this edge case was intentional.  This will I hope be corrected.

> > Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to
> > preclude publishing A/ records there, making some of the example
> > configurations in the draft impractical.
> 
> I don't agree with this reading of RFC 1123.  There is no requirement that
> address records only be placed on hostnames, and there is no requirement
> that TargetName be a hostname.  If I were making an argument here, it might
> be about compatibility with RFC 8553 (Attrleaf), but hopefully this is
> mostly moot per the above.

Well, the maintainers of BIND don't seem to take this more liberal
interpretation:


https://bind9.readthedocs.io/en/v9_18_6/reference.html#glossary-of-terms-used


check-names

Grammar zone (hint, mirror, primary, secondary, stub):

check-names ( fail | warn | ignore );

Grammar options, view:

check-names ( primary | master | secondary | slave | response )
( fail | warn | ignore ); // may occur multiple times

Blocks: options, view, zone (hint, mirror, primary, secondary,
stub)

Tags: server, query

Restricts the character set and syntax of certain domain names
in primary files and/or DNS responses received from the network.

This option is used to restrict the character set and syntax of
certain domain names in primary files and/or DNS responses
received from the network. The default varies according to usage
area. For type primary zones the default is fail. For type
secondary zones the default is warn. For answers received from
the network (response), the default is ignore.

The rules for legal hostnames and mail domains are derived from
RFC 952 and RFC 821 as modified by RFC 1123.

  -->   check-names applies to the owner names of A, , and MX
  -->   records. It also applies to the domain names in the RDATA of NS,
  -->   SOA, MX, and SRV records. It further applies to the RDATA of PTR
  -->   records where the owner name indicates that it is a reverse
  -->   lookup of a hostname (the owner name ends in IN-ADDR.ARPA,
  -->   IP6.ARPA, or IP6.INT).

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Ben Schwartz]

On Thu, Aug 25, 2022 at 7:19 PM Viktor Dukhovni 
wrote:

> On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:
>
> > Relatedly, the results presented by EKR [1] at the most recent DNSOP
> > meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
> > records through their local resolver.  To me, this implies that
> functional
> > origin endpoints are likely to be required even if client software gains
> > SVCB/HTTPS support.
>
> This is why my suggested client behaviour was cognisant of this impediment.
>
> - If the client's *initial* SVCB lookup succeeds, *then* fallback is
>   no longer an option.
>
> - If initial SVCB resolution fails (SERVFAIL, timeout, ...)
>   then the client behaves as though the SVCB record does not exist.
>
> This results in more predictable behaviour, without optimising for
> failure.


I don't think "more predictable" is really a desirable or achievable
outcome in this case.  Sophisticated clients (e.g. web browsers for HTTP,
iterative resolvers for DNS) tend to develop highly tuned heuristics and
state machines in pursuit of performance and reliability within their
particular constraints.  I think an instruction not to fall back in this
case would likely be ignored.  It also strikes me as questionable from a
standards perspective: if SVCB itself is optional, surely the client always
has the right to change its mind and disable its support for SVCB?


>   If the origin zone directs the service elsewhere, and there
> are no last-mile DNS lookup roadblocks, then the protocol becomes
> "reliable" (optimises for success and predictability, over fallback
> recovery leading to potentially/eventually undesirable outcomes).
>
>
> > I believe this balance could be revisited in several years' time, if
> "HTTPS
> > Record" support becomes sufficiently universal.
>
> Indeed it is a possible position to say that the Internet is not yet
> ready for semantically distinct services seen by SVCB-aware and legacy
> clients.


In addition to the deployment concerns I've mentioned earlier, a deployment
of this kind would be intrinsically insecure: a hostile intermediary could
override the choice of which semantically distinct service is seen by the
client.  That's another reason why this configuration is not permitted.

  But I think that latching on success of the initial lookup
> largely addresses the present impediments to reliance on SVCB.
>

The same could have been said of EDNS0 fallback, but the IETF wisely did
not attempt to leap straight to that configuration in the initial RFC.
Instead, we gave client implementors plenty of room to tune their own
fallback behaviors, and came back to tighten the system up much later when
it became safe to do so.

> Viktor notes with concern that AliasMode is a "non-deterministic
> > redirect".  Instead, the draft attempts to model the client behavior as a
> > preference ordered stack of endpoints:
> >
>
> I also noted an issue around the initial $QNAME having prefix labels (in
> the case of SVCB rather than HTTPS), and so this is likely not the name
> you want appended as a fallback to the target list.
>

Indeed, I think this is a clarity/precision problem that we should
correct.  Specifically, this "final value of $QNAME" endpoint is only used
if it is not the initial value of $QNAME (i.e. if an AliasMode record was
found).

Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to
> preclude publishing A/ records there, making some of the example
> configurations in the draft impractical.
>

I don't agree with this reading of RFC 1123.  There is no requirement that
address records only be placed on hostnames, and there is no requirement
that TargetName be a hostname.  If I were making an argument here, it might
be about compatibility with RFC 8553 (Attrleaf), but hopefully this is
mostly moot per the above.


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Viktor Dukhovni]

On Thu, Aug 25, 2022 at 04:35:39PM -0400, Ben Schwartz wrote:

> Relatedly, the results presented by EKR [1] at the most recent DNSOP
> meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
> records through their local resolver.  To me, this implies that functional
> origin endpoints are likely to be required even if client software gains
> SVCB/HTTPS support.

This is why my suggested client behaviour was cognisant of this impediment.

- If the client's *initial* SVCB lookup succeeds, *then* fallback is
  no longer an option.

- If initial SVCB resolution fails (SERVFAIL, timeout, ...)
  then the client behaves as though the SVCB record does not exist.

This results in more predictable behaviour, without optimising for
failure.  If the origin zone directs the service elsewhere, and there
are no last-mile DNS lookup roadblocks, then the protocol becomes
"reliable" (optimises for success and predictability, over fallback
recovery leading to potentially/eventually undesirable outcomes).


> I believe this balance could be revisited in several years' time, if "HTTPS
> Record" support becomes sufficiently universal.

Indeed it is a possible position to say that the Internet is not yet
ready for semantically distinct services seen by SVCB-aware and legacy
clients.  But I think that latching on success of the initial lookup
largely addresses the present impediments to reliance on SVCB.

> Viktor notes with concern that AliasMode is a "non-deterministic
> redirect".  Instead, the draft attempts to model the client behavior as a
> preference ordered stack of endpoints:
> 

I also noted an issue around the initial $QNAME having prefix labels (in
the case of SVCB rather than HTTPS), and so this is likely not the name
you want appended as a fallback to the target list.

Similarly, if an AliasMode target has attrleaf labels, RFC1123 seems to
preclude publishing A/ records there, making some of the example
configurations in the draft impractical.

-- 
Viktor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Ben Schwartz]

Thanks to Brian, Viktor, and others for the very close review, as always.
While I disagree with many of the claims made here, it's clear that some of
the text has proven confusing.  I'm not familiar with the process rules
given the draft's current state, but perhaps we can improve clarity with
some modest revisions.  I'll try to keep that discussion separate.

The key text for this discussion is in Section 3:

   If the client is SVCB-optional, and connecting using this list of
   endpoints has failed, the client now attempts to use non-SVCB
   connection modes.

I believe most reviewers correctly understood this to mean that, if all
else fails, you can connect to https://www.example.com/ using the  or A
records on www.example.com, as usual.  The logic is simple: this draft does
not make "HTTPS Record" support mandatory for HTTP clients.  Thus, HTTP
servers are still required to publish functional address records on the
origin hostname, as usual.  (Similar logic applies to any other
pre-existing protocol that may be used with SVCB.)  Since these records are
required to be present and working, we can hardly forbid clients from using
them.

Relatedly, the results presented by EKR [1] at the most recent DNSOP
meeting measure that 6.5% of Firefox users are unable to retrieve HTTPS
records through their local resolver.  To me, this implies that functional
origin endpoints are likely to be required even if client software gains
SVCB/HTTPS support.

Brian proposes a use case of serving only a warning message on the origin
endpoint, in order to minimize the load on IP addresses that are likely
hardcoded into a customer's zone.  I understand the appeal of this
configuration, but for the above reasons it is deliberately not supported
in this draft.  Instead, the draft attempts to ensure that deploying and
implementing the HTTPS record "does no harm", by giving participating
clients no worse reliability than legacy clients.  (Also, Brian's analysis
indicates that the origin hostname's address record TTL would bias the
endpoint selection, but this is not correct.)

I believe this balance could be revisited in several years' time, if "HTTPS
Record" support becomes sufficiently universal.  For example,
post-deployment data from browsers may show that we could eliminate the
final fallback without reducing reliability.  For now, I think it's better
to keep the current guidance, in order to minimize the risk of disruptions
as these new RR types begin to be deployed.

Viktor notes with concern that AliasMode is a "non-deterministic
redirect".  Instead, the draft attempts to model the client behavior as a
preference ordered stack of endpoints:

1. Basic: the origin endpoint (status quo ante)
2. Better: the endpoint at the end of the AliasMode chain
3. Best: the ServiceMode records

I think it's best to think of AliasMode as an alias that is optional when
SVCB is optional, and mandatory when SVCB is mandatory.  This seems natural
enough to me, and allows it to be used in environments like the web where
"fail fast" is not an appealing option.

--Ben Schwartz


smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Thu, Aug 25, 2022 at 7:58 AM Paul Hoffman  wrote:

> On Aug 24, 2022, at 7:14 PM, Brian Dickson 
> wrote:
>
> >> Are you saying that it was explicit after WG Last Call but changed? Or
> during IETF Last Call and was changed?
> >>
> > No, I'm saying that, as far as I can tell, the flow was never explicit,
> and that's a big part of the problem.
> >
> > And I'm saying that if it had been explicit, the concerns would have
> been raised at that time, rather than now.
>
> This WG has dealt with that exact issue many times with well-debated -bis
> documents.
>
> When Warren started this thread, he said "this is *not*  an opportunity to
> re-litigate existing  decisions, make non-required changes, etc." AliasMode
> was significantly discussed during the preparation of the document, and it
> appears that you don't like the conclusion. That's fine, but that's not a
> reason to change this document: it is a reason to create either a document
> that clarifies or updates it.
>
>
Warren also stated "I'd like to also thank the authors and WG in advance
for their time and for keeping this discussion focused".  I interpret that
as, "let's discuss the technical content of the draft."

To that end:
The issue I raised was with the process flow for the client, in section 3,
not the AliasMode section (2.4.2).
In the summary portion of my original email, I put it thusly:

   - Resurrecting ANAME behavior in corner cases is every bit as bad as
   choosing ANAME as the standard.

I.e. I am saying that, under certain conditions (either DNS resolution
problems, or HTTPS connection problems, after successfully resolving a
single AliasMode HTTPS record, and if there exists apex A/ records
[0]), that the prescribed behavior reverts to that of ANAME.
My assertion is that the ANAME behavior is "OMG! That clearly doesn't
work". [1]

My question to anyone responding who disagrees with this assessment is:
Which is it?

   - Is the behavior (in the corner cases) not ANAME-like (requiring that
   apex A/ records have the same values as would be resolved when
   following the HTTPS Alias)?
   - Or, "No, it always works" (even in those corner cases)?
   - Or, "The corner case ANAME behavior exists, but is not a big enough
   deal to make changes before publication."

*Having the opinion that "The corner case ANAME behavior exists, but is not
a big enough deal to make changes before publication", is a valid position.*
I would prefer that this *exact* language be used, if this is the position
being taken by anyone, please.
(E.g. Paul H, is this an accurate characterization of your position?)

BTW: the fall-back corner case is only indirectly related to AliasMode, and
is not related to any of the discussions on AliasMode that occurred, to the
best of my knowledge.
(I'd be happy to be corrected with any single pointer to an on-list thread,
if I'm wrong).

I am not proposing changes to AliasMode itself, nor do I have problems with
the current state of 2.4.2 (other than ambiguous language.)

The problematic bit from 2.4.2 was specifically:

   - The conflation is between "legacy clients", and "preferable for
   clients implementing the specification".
   - Legacy support is not "fallback", which is where the conflation is
   introduced.
   - If non-legacy fallback is a required element to advance the draft,
   let's update the draft accordingly
  - Including establishing a new owner label prefix for fallback
  records, distinct from legacy records, which by definition CANNOT have a
  different name than the origin (apex) name.
  - The conflation is IMHO browsers attempting to infer the intent of
  zone owners, rather than having zone owners explicitly publish
appropriate
  records to that effect (fallback target addresses).

Note also that 2.4.2 only defines AliasMode (what it is, how it is meant to
be used, rules about what the publisher should put in AliasMode records,
and the paragraph about "legacy clients" is not part of, nor is it
subsequently either incorporated by reference, restated, or directly
included in section 3 on Client behavior. (The only other place "legacy" is
referenced is in Appendix C, comparing the draft to the ANAME and HTTP
proposals that predate this draft.)

NB: Viktor Dukhovni had a laser-focused contribution to the discussion (on
Wed, Aug 24, 1:58 PM), which I believe does a much better job of
articulating the issue than my original message did. (Thanks, Viktor).
I would strongly suggest reading his message and replying/commenting there.

Brian

[0] Apex A/ records may exist for purposes other than publishing the
site whose delegation is performed via HTTPS record, including SMTP or
other non-web services, or for providing legacy clients with instructions
on obtaining HTTPS-aware clients.
[1] See the extensive WG ANAME discussions for why ANAME doesn't work
for everyone. AliasMode *does* work for everyone. Resurrecting the
ANAME behavior alongside AliasMode, is snatching defeat 

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Paul Hoffman]

On Aug 24, 2022, at 7:14 PM, Brian Dickson  
wrote:

>> Are you saying that it was explicit after WG Last Call but changed? Or 
>> during IETF Last Call and was changed?
>> 
> No, I'm saying that, as far as I can tell, the flow was never explicit, and 
> that's a big part of the problem.
> 
> And I'm saying that if it had been explicit, the concerns would have been 
> raised at that time, rather than now.

This WG has dealt with that exact issue many times with well-debated -bis 
documents.

When Warren started this thread, he said "this is *not*  an opportunity to 
re-litigate existing  decisions, make non-required changes, etc." AliasMode was 
significantly discussed during the preparation of the document, and it appears 
that you don't like the conclusion. That's fine, but that's not a reason to 
change this document: it is a reason to create either a document that clarifies 
or updates it.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Eric Orth]

I still disagree with the arguments for such a change being the ideal
behavior.  But rather than debating that further here, I will instead just
argue that I do not believe any of this rises to the level of necessity for
making technical changes at this late stage.  This is not a case of "OMG!
That clearly doesn't work", as evidenced by the fact that multiple parties
from different parts of the stack have already implemented the current
spec, and they are not overwhelmingly chiming into this thread to say it
doesn't work.

We should take the debate over this matter to a Bis proposal.

On Wed, Aug 24, 2022 at 10:14 PM Brian Dickson <
brian.peter.dick...@gmail.com> wrote:

>
>
> On Wed, Aug 24, 2022 at 6:19 PM Paul Hoffman 
> wrote:
>
>> On Aug 24, 2022, at 5:14 PM, Brian Dickson 
>> wrote:
>> > "at this stage" is only the case due to the draft not being explicit in
>> the flow.
>>
>> Are you saying that it was explicit after WG Last Call but changed? Or
>> during IETF Last Call and was changed?
>>
>
> No, I'm saying that, as far as I can tell, the flow was never explicit,
> and that's a big part of the problem.
>
> And I'm saying that if it had been explicit, the concerns would have been
> raised at that time, rather than now.
>
> (This is, IMNSHO, the poster child for why being as clear as possible for
> actual logic flows is really important, both to implementers, and to those
> involved in the process of reviewing documents and advancing standards.)
>
> I.e. I definitely apologise that this was not caught earlier. I also don't
> think it would have been possible to catch prior to doing interoperability
> tests and discussing with developers, which is exactly what the process was
> that lead to the request to the chairs and AD.
>
>
>
>>
>> > Yes, this is a non-editorial change.
>>
>> Also called a technical change.
>>
>
> Or a technical correction of a defect. It's a change, but not an arbitrary
> change.
>
>
>>
>> > If it were limited to an editorial change, it could be handled with an
>> Errata or via a -bis document.
>>
>> Technical changes require going back at least to IETF Last Call, if not
>> WG consideration again. Bis documents are for making technical changes.
>>
>
>  once the RFC is published. And yes, while this will require those
> things, those are good things. Clarification and scrutiny are the
> responsibility of the WG and the IETF.
>
> This is an exceptional case, given that the issues are central to
> interoperability and deployability (usability by zone administrators).
>
> It is an unavoidable risk that developers take in attempting to track an
> in-progress draft prior to publication as a standards-draft RFC.
> Any change made up until the RFC is published, is something developers
> that want to be RFC-compliant need to do.
> Yes, doing development while the standard isn't complete gets software
> deployed sooner.
> The standard necessarily dictates the implementation, not vice versa. The
> copyright assignment stuff when bringing things to the IETF basically says
> that once adopted by the WG, it's a WG doc, not the original author's.
>
> I believe that, for the most part, the needed changes are code deletions
> or branching logic pruning, and as a result, de minimis.
> I also believe that the resulting client performance will be faster, more
> reliable, and less risky.
> In particular, the speculative DNS queries made in parallel can benefit
> from early abandonment. If a client receives an AliasMode response,
> outstanding queries for A/ are no longer needed. This permits a client
> to proceed faster than if the client waited until it received responses, or
> worse waited until those queries timed out.
>
> Brian
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Brian Dickson]

On Wed, Aug 24, 2022 at 6:19 PM Paul Hoffman  wrote:

> On Aug 24, 2022, at 5:14 PM, Brian Dickson 
> wrote:
> > "at this stage" is only the case due to the draft not being explicit in
> the flow.
>
> Are you saying that it was explicit after WG Last Call but changed? Or
> during IETF Last Call and was changed?
>

No, I'm saying that, as far as I can tell, the flow was never explicit, and
that's a big part of the problem.

And I'm saying that if it had been explicit, the concerns would have been
raised at that time, rather than now.

(This is, IMNSHO, the poster child for why being as clear as possible for
actual logic flows is really important, both to implementers, and to those
involved in the process of reviewing documents and advancing standards.)

I.e. I definitely apologise that this was not caught earlier. I also don't
think it would have been possible to catch prior to doing interoperability
tests and discussing with developers, which is exactly what the process was
that lead to the request to the chairs and AD.



>
> > Yes, this is a non-editorial change.
>
> Also called a technical change.
>

Or a technical correction of a defect. It's a change, but not an arbitrary
change.


>
> > If it were limited to an editorial change, it could be handled with an
> Errata or via a -bis document.
>
> Technical changes require going back at least to IETF Last Call, if not WG
> consideration again. Bis documents are for making technical changes.
>

 once the RFC is published. And yes, while this will require those
things, those are good things. Clarification and scrutiny are the
responsibility of the WG and the IETF.

This is an exceptional case, given that the issues are central to
interoperability and deployability (usability by zone administrators).

It is an unavoidable risk that developers take in attempting to track an
in-progress draft prior to publication as a standards-draft RFC.
Any change made up until the RFC is published, is something developers that
want to be RFC-compliant need to do.
Yes, doing development while the standard isn't complete gets software
deployed sooner.
The standard necessarily dictates the implementation, not vice versa. The
copyright assignment stuff when bringing things to the IETF basically says
that once adopted by the WG, it's a WG doc, not the original author's.

I believe that, for the most part, the needed changes are code deletions or
branching logic pruning, and as a result, de minimis.
I also believe that the resulting client performance will be faster, more
reliable, and less risky.
In particular, the speculative DNS queries made in parallel can benefit
from early abandonment. If a client receives an AliasMode response,
outstanding queries for A/ are no longer needed. This permits a client
to proceed faster than if the client waited until it received responses, or
worse waited until those queries timed out.

Brian
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Paul Hoffman]

On Aug 24, 2022, at 5:14 PM, Brian Dickson  
wrote:
> "at this stage" is only the case due to the draft not being explicit in the 
> flow.

Are you saying that it was explicit after WG Last Call but changed? Or during 
IETF Last Call and was changed?

> Yes, this is a non-editorial change.

Also called a technical change.

> If it were limited to an editorial change, it could be handled with an Errata 
> or via a -bis document.

Technical changes require going back at least to IETF Last Call, if not WG 
consideration again. Bis documents are for making technical changes.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Warren Kumari]

On Sat, Aug 20, 2022 at 1:29 PM, Paul Hoffman 
wrote:

> On Aug 20, 2022, at 10:07 AM, Warren Kumari  wrote:
>
> Pausing publication is an unusual, but definitely not unprecedented, step.
> Although we are able to make changes until a document is published as an
> RFC, once it is approved and sent to the RFC Editor, we should only make
> (non-editorial) changes in exceptional circumstances…
>
> Isn't this *exactly* what update documents are for? The protocol in
> draft-ietf-dnsop-svcb-https is already a standard; it simply hasn't been
> published as an RFC yet. It is also already widely implemented and
> deployed.
>
> If there is a problem with the protocol specification, particularly one
> that is re-litigation of earlier arguments, anyone can offer a new draft
> that updates the protocol. In this particular case, AliasMode was heavily
> discussed in the WG and the document was revised based on those discussions
> before the protocol was standardized.
>
> It would be good to understand why this particular case of feature
> re-litigation is enough to cause a message such as this.
>

Yes, yes it would be — however, see: "... and I wasn't really able to parse
his issue with the document, so I ask him to clearly state the issue
on-list when he returns."

See also: "As the document was already extensively discussed and approved,
we should only make substantive changes if they are very clearly warranted
(e.g something that would otherwise be an errata, or "OMG! That clearly
doesn't work, 1+1 doesn't equal 17…") —  this is *not*  an opportunity to
re-litigate existing  decisions, make non-required changes, etc."


As for why this case:
1: Brian's email used phrases like "this is a catastrophic bug" and "it
cannot be used (because of web browser client ambiguities and different
interpretations by different implementers already)."  I cannot tell if his
concerns are valid (and am waiting for him to come back and clearly state
them), but erring on the side of caution seems the right thing to do.

2: "The IESG is expected to ensure that the documents are of a sufficient
quality for release as RFCs, that they describe their subject matter well,
and that there are no outstanding engineering issues that should be
addressed before publication." -
https://www.ietf.org/standards/process/role-iesg-standards-process/ . I
believe that if a participant raises a clear warning (see #1) that there
are significant issues with a document, and if we *can* address them before
publication, we really should. Publishing RFC9 and then having to
publish RFC9xxy saying "Oh, no, we made a mistakes, replace Section X with
Section Y" is inefficient, causes confusion, and undermines the RFC system.
If indeed Brian's concerns are valid and we find that the RFC is "wrong,"
publishing it as is not the right thing to do.

3: The document was stuck anyway - it is in MISREF waiting for another
document which has't been received yet.

4: One of the authors on the document is employed by Google, and Brian said
that he believes that Google Chrome's interpretation of the document is
incorrect. In addition to being OpsAD, I am also employed by Google, and so
I believe that I need to err on the side of caution and transparency to
ensure that there is no conflict or perception of conflict. This was very
much a secondary consideration though. Reasons 1 and 2 are more than enough
for me to say "Let's pause this while we make sure that we are not
publishing something with an error, especially in light of the fact that it
doesn't actually delay the RFC..."

W



> --Paul Hoffman
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Questions / concerns with draft-ietf-dnsop-svcb-https (in RFC Editor queue)

[Paul Hoffman]

On Aug 20, 2022, at 10:07 AM, Warren Kumari  wrote:
> Pausing publication is an unusual, but definitely not unprecedented, step. 
> Although we are able to make changes until a document is published as an RFC, 
> once it is approved and sent to the RFC Editor, we should only make 
> (non-editorial) changes in exceptional circumstances…

Isn't this *exactly* what update documents are for? The protocol in 
draft-ietf-dnsop-svcb-https is already a standard; it simply hasn't been 
published as an RFC yet. It is also already widely implemented and deployed.

If there is a problem with the protocol specification, particularly one that is 
re-litigation of earlier arguments, anyone can offer a new draft that updates 
the protocol. In this particular case, AliasMode was heavily discussed in the 
WG and the document was revised based on those discussions before the protocol 
was standardized.

It would be good to understand why this particular case of feature 
re-litigation is enough to cause a message such as this.

--Paul Hoffman



smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop