Re: [DNSOP] [Ext] DS glue for NS draft

[Ben Schwartz <[e-mail]>]

On Mon, Aug 16, 2021 at 2:05 PM Brian Dickson <[e-mail]>
wrote:
...

> I'm arguing against the parent ever putting SVCB records in any delegation
> response, regardless of whether the data is signed, or whether the parent
> is capable of doing so. The data model for doing so is IMNSHO incorrect.
>
> The parent is responsible for signaling the delegation, and everything
> else is necessary for resolution, but not authoritative.
>

I think we can and should view the server configuration hint (e.g. SVCB) as
"necessary for resolution".  Otherwise, we would be asking resolvers to add
a round-trip delay (a "synchronous binding check") to every single DNS
delegation, in order to check whether a SVCB record exists before
proceeding.  I believe this is untenable: our first deployment step can't
be to slow down the whole internet.  The resolver operators I've spoken to
have made it clear that they will not implement any behavior with that kind
of impact.

Even if we can somehow limit this "synchronous binding check" to domains
that have opted-in, we would still be adding a round-trip delay to all
delegations in the long term, when encryption is widely deployed.  I don't
see any operational concern here that could outweigh the cost of making the
whole internet slower.

...

> To avoid misunderstanding: SVCB itself does not alter the nameserver name
>> used for TLS.  The nameserver name is the name in the NS record, regardless
>> of what SVCB says.  ("TLS clients MUST continue to validate TLS
>> certificates for the original service name",
>> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07#section-2.3
>> )
>>
>
> At issue is not whether the name is changed, it is who is authoritative
> for the data at the owner name, which is the child zone.
>

I agree.  That's why I think it's wisest to require that any records
provided by the parent are only used for delegation, and never returned to
the stub.


> The SVCB also is controlling the transport and potentially other
> parameters.
>

These parameters are thoroughly analogous to the IP addresses in glue A
records today.  In both cases, we are discussing information that is used
to connect to the nameserver, not information that will be returned to the
stub as zone contents.


> Absent a discussion on how to securely get that data into the parent, it
> cannot be accurately asserted as having the same security properties as
> when the SVCB record is published in a signed child zone.
>
>
>>
>>
>>> The resolver talking TLS will be talking to the name server, to make
>>> encrypted queries about a domain served by the name server.
>>> (The domain served that is being queried is presumed to not have an
>>> in-bailiwick name server, since that particular corner case is a
>>> chicken/egg problem.)
>>>
>>> The alternative (to requiring the SVCB record in the child, signed by
>>> the child domain) might be an SVCB-like thing in the parent which contains
>>> data signed by the child. Specifically:
>>>
>>>    - A DNSKEY algorithm, or component of the draft-schwartz encoding,
>>>    which contains (SVCB + RRSIG_name_server_child_ksk(SVCB))
>>>    - This would be signed by the parent too, but the critical component
>>>    the provides the data integrity from the child is the
>>>    RRSIG_name_server_child_ksk element
>>>    - Only the operator of the name server's name's domain (which
>>>    possesses the name_server_child_ksk) can generate this signature
>>>
>>> Yes, but the parent controls the choice of nameserver name, so this does
>> not create an effective defense against a hostile parent, which is
>> impossible under standard DNSSEC assumptions.
>>
>
> None of this has anything to do with a potential hostile parent, not sure
> why you are raising that.
>

Security is defined by a threat model.  if the parent is excluded from the
threat model, as we seem to agree, then anything signed by the parent is
fully secure by definition.

But I think it is probably a moot point to discuss any other method of
> encoding SVCB in the parent.
>
> There are a lot of other reasons why SVCB in the parent has
> characteristics that are not suitable.
>
>    - TTL on the parent side is controlled by the parent, not the child
>       - This has operational impacts, particularly if problems occur and
>       a roll-back is necessary
>
>  I don't see a difference here from the status quo with NS, A, and AAAA
glue records.

>
>    - TTL on the child side is controlled by the child (which is likely to
>    be important when rolling out new features, or making changes)
>       - TTL can be adjusted up/down as needed for planned maintenance work
>    - Frequency of updates for current DS records, is basically "when KSK
>    rolls", which is on the order of year(s)
>       - Encoding glue via DS, involves updates whose frequency aligns
>       with changes to that glue, also typically stable for years at a time
>
> There is no reason to expect frequent changes to any of the relevant
records.  Even TLSA records would not be rotated more than a few times a
year.

>
>    - Changes to SVCB would require regenerating RRSIGs.
>       - Doing that imposes impact to the signing zone (signature
>       frequency is typically bound by hardware, and upping the former requires
>       more of the latter)
>       - That also presupposes that the proposed frequency can even be
>       supported
>       - If the signing is done by the child, the cost is borne by the
>       party making the changes
>       - If the signing is done by the parent, the cost is not borne by
>       the party making the changes
>    - The SVCB RDATA is not actually authoritative on the parent side
>    (bears repeating, this has a lot of implications, including infosec issues)
>
> Yes, but there is no need for it to be authoritative, because it would
never be returned as zone contents.  We already use non-authoritative data
to establish a connection to a nameserver, so that's nothing new.

Also, it is not clear from the discussion thus far, on which record(s)
> would have that SVCB record included:
>
>    - The registrant's zone name (delegation from the parent to the DNS
>    Operator's server)
>    - The DNS Operator's zone name (possibly glue-less XOR possibly having
>    in-bailiwick glue required)
>    - The Zone serving the name server names (referenced in the NS records
>    of the registrant's zone)
>
> The first one would not be reasonable at all, since presumably the
> registrant would have the ability to submit SVCB records even if the
> registrant did not operate the authoritative DNS server.
>

SVCB records would only be accepted on in-bailiwick delegations, i.e. the
same delegations that include A/AAAA glue today.  I believe this is your
third case, although there can technically be multiple in-bailiwick
delegation steps in the course of a single iterative resolution.

>
>>>    - This is much stronger than being able to push data over an EPP
>>>    channel, which is the mechanism available to a Registrar that polls the
>>>    Registrant's domain for CDS records
>>>    - EPP does not have a mechanism currently for validation of supplied
>>>    DS records
>>>
>>> I don't understand.  When using CDS, the CDS records are validated by
>> DNSSEC from the current DS.  Otherwise, the DS records are authenticated by
>> the registrar's usual login procedure.  Either way, any adversary who could
>> forge DS records could also forge RRSIGs or any other RR type.
>>
>
> This is a "chain of custody/control" thing. If the Registry is not doing
> CDS directly, the CDS model has failed to protect the DS update end-to-end.
> While another party (Registrar) polling and validating CDS would be
> _necessary_, it would not be _sufficient_.
>

It sounds like you are saying that a compromised or hostile Registrar
should be part of our threat model.  I do not think this is necessary or
practical.  A compromised Registrar can always replace the entire child
zone contents, so nothing we place in the child zone can defend against it.

There are only a handful of CCTLDs doing CDS, and I am not aware of any
> significant plans beyond those currently.
> CDS _by the Registry_ is incompatible with the RRR model, i.e. the gTLD
> mechanism controlled by ICANN contracts.
> That is highly unlikely to change in a timeframe faster than multiple
> years, if ever.
>
> Basically, I don't foresee CDS done by Registries being relevant to any
> proposals for securing the glue data.
>

Perhaps, but some Registrars have already implemented support, e.g.
https://glauca.digital/blog/2020/08/10/cds-at-the-registrar-level.html.
Domain owners that wish to publish via CDS can already choose such a
Registrar, and use CDS for automated maintenance with any Registry.

...

> Also, optimizing for cold cache vs warm cache should be explicitly called
> out. It looks to me like "SVCB in parent" is only valuable in the cold
> cache scenario.
>

I agree!


> Stats are probably available showing how often queries are made for DNS
> operator's zones that indicate a cold cache is being used. Absent a
> compelling case for the cold cache, it does not seem to be worth any effort.
>

Perhaps we can find some stats, but I think the "cold cache" case is worth
optimizing for reasons of tail latency and consolidation pressure.  Cold
cache delegations already resolve slower, so making them even slower is
likely to have a disproportionate impact on tail latency.  Low-traffic
nameservers are much more likely to be cold in cache, so increasing the
latency penalty for a cache miss would increase pressure to migrate to
centralized nameservers.

>