Apologies to anyone following this thread... these messages are getting
very large, necessarily.
(Paul H, you may want to skip down to an example I provided, look for
ORIGIN text.)
On Mon, Aug 16, 2021 at 9:15 PM Ben Schwartz <bem...@google.com> wrote:
>
>
> On Mon, Aug 16, 2021 at 7:40 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Mon, Aug 16, 2021 at 3:14 PM Ben Schwartz <bem...@google.com> wrote:
>>
>>>
>>>
>>> On Mon, Aug 16, 2021 at 2:05 PM Brian Dickson <
>>> brian.peter.dick...@gmail.com> 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.
>>>
>>
>> I think it is time to actually work through an example, as your assertion
>> ("every single DNS delegation") does not align with my understanding.
>>
> ...
>
> I think we agree: we are talking about an extra RTT for every in-bailiwick
> delegation that is not in cache. (And every iterative resolution sequence
> includes at least one in-bailiwick delegation step.)
>
You haven't responded to the worked example, only reiterated a tautological
statement (true by definition only) with very limited relevance.
If a domain is delegated to a name server that is in-bailiwick, clearly
that would require one RTT to obtain any information in that domain.
However, it is also the case that in the context of privacy, talking to
that name server directly reveals to any on-path observer that the resolver
is interested in records in that self-same domain. This is the use case
where it is literally impossible to bootstrap to a private connection
without doing one of two things: probing for a secure connection (e.g.
attempting a connection on port 853) AND having that connection being
subject to downgrade by an on-path attacker, or having the necessary
parameters provided by the delegating (TLD) name server, which is something
ONLY required in the case of the in-bailiwick name server for the
domain-of-interest.
In all other cases, the domain is delegated to a name server whose name is,
by definition, not in-bailiwick for the domain-of-interest.
Yes, the name server name itself may (or may not) be in-bailiwick, but the
privacy concerns on that initial connection are limited to inferred, rather
than directly observed, information.
So, the only impact on RTTs exists if the first domain-of-interest is
queried on a given non-bailiwick name server, for the first client query on
that domain-of-interest. All subsequent queries within THAT
domain-of-interest, or for any OTHER domain-of-interest served on the same
name server, do not have a multiple RTT penalty.
This is absolutely not the case initially asserted, about adding "a
round-trip delay (a "synchronous binding check") to *every single DNS
delegation*". (emphasis added).
>
> ...
>
>> 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.
>>>
>>
>> The parent can be trustworthy, but not the communications to the parent
>> (EPP). Those are not equivalent elements of the threat model.
>> This is especially true concerning the signing processes.
>> The signing itself can be super-safe with all kinds of practise
>> statements, but that does not mean there is not a weakness on the data
>> upload path.
>> The latter is input to the signed data, and is the weak point in the
>> overall system.
>>
>
> EPP controls the DS contents regardless, and hence the security anchor of
> the entire registered domain. If you have a security problem with EPP,
> you'll have to address it before we get to the point of resolvers reading
> the DS records. At that point, an attacker who controls EPP has already
> won the game.
>
>
>> 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.
>>>
>>
>> The NS records reference names (RDATA values), but the names may be
>> "glue-less", e.g.
>>
>> - The delegated domain and NS are not under the same TLD
>> - The NS domain is itself glueless (served by name servers not under
>> the same domain as the NS names)
>> - Example:
>> - foo.example NS ns1.out-of-bailiwick.example
>> - out-of-bailiwick.example NS ns1.dns-operator-domain.example
>> - ns1.dns-operator-domain.example A glue-A-record
>> - This is a counter-example, showing that there may not even be A
>> and AAAA glue records involved that correspond to SVCB records
>> - The SVCB record, if present, would be tied to
>> "ns1.out-of-bailiwick.example"
>>
>> I don't understand. In all of those cases, the TTLs of the NS, A, and
> AAAA records used during delegation are controlled by the various parent
> domains. Why is that OK for NS, A, and AAAA but not OK for SVCB?
>
Again, you are asserting facts not in evidence.
Not all delegations rely on A and AAAA records supplied as glue by the TLD.
Many do not.
In fact, I would assert that the opposite is the case: *most* do not.
Every delegation from every OTHER TLD to a name server whose name is in one
single TLD (such as "ns1.example.com") will be glueless.
And, a significant portion of same-TLD delegations are also glueless.
I know because we operate our name servers in a glueless manner, and those
by themselves represent a proportion close to the majority.
(If you want a count of records in a TLD, such as com, demonstrating
in-bailiwick counts vs glued non-in-bailiwick vs glueless non-in-bailiwick,
just ask, and I will try to get some. It might take a few days, though.)
This means that the TTLs on the A and AAAA records (plus any other possible
additional records) are under our direct control, not the control of the
parent TLDs. This would include SVCB (instantiated with some RRTYPE
specifically for this rather than using _NAME attrleaf), and TLSA 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.
>>>
>>
>> I think you are projecting from individual practices onto the entire
>> industry's operational practices.
>> Just because *some* TLSA records might not change often, does not mean
>> *all* TLSA records will not change often.
>> I can probably point to counter-examples.
>>
>
> Here's some text from draft-schwartz-ds-glue-01, Section 6.3:
>
> As an optimization, nameservers using DANE MAY place a TLSA record in
> the DSGLUE to avoid the latency of a TLSA lookup during delegation.
> However, child zones should be aware that this adds complexity and
> delay to the process of TLSA key rotation.
>
> So if you want to rotate your TLSA key so frequently that you hit rate
> limits on your DS updates, you should just omit it from the glue and pay
> the 1-RTT penalty.
>
Again, and you seem not to be getting it, that 1-RTT addition only exists
(a) on first use, and (b) on RTT expiry, and then *only* for the first
client querying a domain served on the name server serving that domain,
and *THEN* only if the resolver determines that it needs to perform the
query over TLS, including whether the authority server even offers TLS
resolution. If we can agree on the use of DNSSEC being mandated for this
ADoT stuff, a further short cut can be introduced by checking whether the
NS target is in a signed zone or not. This short cut is one argument in
favor of requiring DNSSEC for ADoT.
>
> Also, the frequency of changes is not the same as the impact of TTL on
>> changes (cached records in some resolvers' caches, vs newly queried records
>> in other resolvers' caches.
>>
>> There are other issues that you haven't discussed here yet:
>>
>> - There may be different anycast locations, topologies, and policies,
>> vis a vis TLSA records
>> - Different DNS Operator anycast instances may serve different
>> TLSA records (geographically aligned values)
>>
>> The DNS offers no guarantees about preserving cache geolocality, so this
> is a recipe for breakage regardless. Route flaps, for example, could cause
> a record from one location to be used in another.
>
You are arguing about someone else's infrastructure. Not your circus, not
your monkeys.
Also, ruling out someone else's operational practice as part of your
proposal for a standard, is not cool.
Your proposal is INCOMPATIBLE with this practice, so criticizing the
practice itself is using the "Wookie defence". Please don't do that.
> ...
>
>>
>>>> - 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.
>>>
>>
>> Except this is new,
>>
>
> Yes! That means that there is no rule here. It is up to us.
>
No! It means it is up to the Registry Operators, the ICANN, the relevant
liasons, the IAB, the IESG, and all of the implementers and operators of
the DNS, and all of the applications which rely on the DNS (which is,
basically, everyone in the IETF, plus everyone not in the IETF).
The philosophy of "It is better to ask forgiveness than ask permission",
isn't something that extends well to multi-stakeholder environments.
I feel okay using a "DS hack" in the manner I have proposed, specifically
because:
- It is proposed as a method to validate data ALREADY PUBLISHED AND USED
IN DELEGATIONS (NS/A/AAAA)
- The data proposed to be involved in validation IS ALREADY PRESENT, too
(e.g. hashes of NS records, A glue records, AAAA glue records)
- The mechanism could just as easily be implemented by Registries (doing
the hash of the aforementioned records, since the Registries already have
then on hand)
- The EPP update sent by the child is a work-around unless/until
Registries do this themselves
- This would allow there to not need to be a flag day
- Partial deployment of Registry-initiated DS records, would not
preclude use in TLDs where that does not yet happen
>
>
>> and is precisely the case where using non-authoritative data to establish
>> a connection to the name server would break the assumptions needed for
>> privacy.
>>
>
> No, I don't follow this at all. The assumption for privacy is that a
> network intermediary, i.e. an adversary with no access to relevant private
> key material, cannot capture the query contents. A signature by the parent
> is entirely sufficient for this.
>
The assumptions needed for privacy, are that an on-path attacker cannot
unilaterally downgrade the connection, or more specifically, that no party
without control of the private key of the domain serving the name of the
name server, has the ability to signal that an insecure connection is okay.
If the signal is served from a signed domain operated by the party running
the name server (by way of the domain serving the name of the name server),
there is cryptographic protection on this signal.
If the signal is served by the parent, based on data supplied by
password-protected but not cryptographically protected channels, this is a
much weaker scenario.
The privacy "bill of goods" being sold in DPRIVE is that the query/response
are completely protected by PKI. If that PKI relies on a signal that is not
itself strongly protected, this is not meeting the intended goals of DPRIVE.
Arguing that the initial step of securing a domain (first DS to parent)
means nothing else needs to be as strong as what is provided by DNSSEC
after that DS is published in the parent, is a logical fallacy.
Improving the initial DS, and subsequent DS updates, is a related but
separate issue.
>
> 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.
>>>
>>
>> See above. The second bullet being glueless and the third being
>> glue-full, would mean the SVCB record would not have associated glue and
>> thus no v4 or v6 hints.
>>
>
> No, I don't follow. SVCB records would appear in exactly the same places
> as A/AAAA glue, i.e. in-bailiwick delegations only.
>
What you don't follow is that there are non-in-bailiwick delegations, a lot
of them. The majority, possibly the vast majority.
Also, we are talking about DNS records for SVCB, i.e. "dot" with a
yet-to-be-specified binding analogous to HTTPS, with a default-alpn of
"port 53 UDP/TCP". The service name (owner name) can (and often will) exist
without corresponding A/AAAA records, and thus no *-hints parameters. In
fact, supplying hints would *break* resolution in many cases.
So, for purposes of providing a hypothetical concrete example, consider the
following records (at a TLD or at an authority server beneath that TLD):
In TLD "example"
foo.example NS ns1.dot-only.dns-operator.example
bar.example NS ns1.dot-allowed.dns-operator.example
blech.example NS ns1.no-dot.dns-operator.example
dns-operator.example NS ns1.dns-operator-server.example
In domain "dns-operator.example", served by ns1.dns-operator-server.example:
// SVCB type records with wildcards indicating what transports to
allow/offer:
$ORIGIN dns-operator.example.
*.dot-only DNS 1 "." no-default-alpn alpn="dot"
*.dot-allowed DNS 1 "." alpn="dot"
*.no-dot DNS 1 "."
* TLSA 2 1 1 ( fingerprint of intermediate signing cert for TLS certs used
on all DNS servers in this domain )
Given the use of DNSSEC, DANE, wildcard validation in DNSSEC, and
synthesized wildcard responses generated by resolvers, other than getting
the necessary A/AAAA records, all of the extra information required for
authenticated and downgrade-resistant ADoT (including signaling) is handled
by those four records.
The A/AAAA records were always needed for talking to the authoritative
servers, so the above are the only novel items.
All of these presume DNSSEC on the domain, and validation requires
obtaining the DS and DNSKEY records to bootstrap from a cold cache.
>
> ...
>
>> 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.
>>>
>>
>> It has nothing to do with whether the Registrar is hostile or not. If the
>> data is not authenticated by the TLD, the chain of custody has been broken.
>>
>
> If Registrar instructions are accepted by the Registry without
> authentication, then DNSSEC is broken because a network adversary can
> control the zone keys. If bugs of that kind are present in the wild that
> is a very serious matter, but it's entirely separate from this discussion,
> which starts from the assumption that DNSSEC is implemented securely. (The
> same would be true of any DNSSEC implementation bug.)
>
More accurately, DNSSEC is built on the assumption that how records are
conveyed to the parent are out-of-scope. DNSSEC uses a security model that
assumes everything from that point on (the trust anchors and conveyance of
DS records existing and being trustworthy).
It has to work from that assumption to be possible to implement. Subject to
that assumption, DNSSEC is, itself, secure.
Those are not bugs. They are design deficiencies in the protocols used for
that conveyance.
Out of scope for the purposes of understanding DNSSEC, but not for adding
more things into the mix that themselves rely on the security of those
conveyances.
This is why limiting the "DS glue protection" to data already provided (but
not protected) makes sense, but doing anything to add more data and
assuming that it is safe and secure to do so, is questionable.
>
>
>> This is a problem with lack of alignment in the security model between
>> Registrar polling (using CDS records, signed by the Registrant or the
>> Registrant's DNS Operator) and EPP submission (which uses Registrar
>> credentials, not Registrant credentials).
>>
>> An example of a trustworthy Registry and trustworth Registrar
>> communicating over TLS, still being potentially compromised:
>> If the Registry's TLS connection was MITM'd by an on-path adversary with
>> a valid TLS cert issued by a different CA, which was in the trusted CA set
>> for the Registrar, the DS update could be tampered with.
>>
>
> That is an attack to consider, but it doesn't qualify as "not
> authenticated". Rather, it represents a trusted party (a CA) becoming
> untrustworthy, compromising the security of the system.
>
> Strengthening the DNS against untrustworthy CAs could be an interesting
> project, but it is out of scope here.
>
Excluding CAs from the trust model of DNS is definitely in-scope for DNS.
The option of resolvers using WebPKI is very different from relying on
WebPKI for secure DNS resolution (i.e. DNSSEC).
Having DNSSEC-signed records conveyed removes the need to rely on WebPKI as
part of the security chain for updating DNSSEC records.
DNSSEC is already required, so including reliance on that is a sensible
next step.
Allowing non-validated records sent over any channel, no matter how secure,
is less secure than using only validated records.
(This mirrors 5011, which itself could do with a -bis honestly.)
>
>
>> If the DS record was signed, and the Registry validated the signed DS
>> record, this tampering would not be possible, and there would not be any
>> reliance on CAs or TLS certs.
>>
>
> Ultimately, some authority is needed for the Registry to know whether
> they are talking to an accredited Registrar. If this authority is
> delegated to a poorly chosen party, that is unfortunate, but we can't fix
> it here.
>
The Registrar is only a necessary intermediary. The source of truth is the
Registrant (or possibly a delegated trusted party, the DNS Operator).
The lack of validation of the Registrant is the problem, not whether the
Registrar is trustworthy.
>
>
>> Data integrity is different from channel integrity.
>>
>> The threat model is not relevant if there is a lower-trust component in
>> the update. CDS is cryptographically strong (CDS signed by existing DNSKEY
>> private key), while Registrar credentials are not (at least generally,
>> today).
>>
>
> That sounds like a TOFU model, on the assumption that the initial DNSKEY
> was not tampered with. However, the Registrar always needs the ability to
> override the child's claim to ownership, in order to rescind the
> registration (e.g. due to non-payment), so this cannot even offer full TOFU
> security.
>
Technically not true. Over-riding the NS is sufficient to break the
registration, and does not require any actions on the DS record itself.
(The EPP convention is that the Registrar can remove the DS, but that is a
different trust model than having the ability to change the DS.)
CDS provides a method for going insecure.
Multi-signer (being worked on) will likely need to address a number of
scenarios for allowing change-of-DNS-operator and change-of-Registrar
without going insecure.
Change of ownership of a secure domain absolutely will require going
insecure and doing a new bootstrap to secure, even if the old and new
owners use the same Registrar.
(Just stating facts.)
>
> It is a significant problem that I think needs to be addressed.
>>
>
> I would welcome a draft addressing it, but I don't think it has anything
> to do with this discussion about authenticating delegation information.
>
>
>> The interim mechanisms for protecting against these weaknesses do not
>> scale well - i.e. Registry Lock, which is incompatible with frequent DS
>> changes.
>>
>>
>>>
>>> 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.
>>>
>>
>> Even if every Registrar supported this, it does not change the RRR
>> security model that underlies everything, outside of the CCTLDs doing CDS.
>> They all rely on EPP, with no data integrity check on submitted DS
>> records associated with such CDS updates.
>>
>
> This does not seem like a fair description. The Registrar is identified
> by a certificate issued by some mutually trusted authority, which signs a
> transport (TLS) that includes data integrity protection.
>
TLS only provides channel integrity, not data origin integrity.
This is true for DoH/DoT as well, which is why most folks in DNSOP advocate
for DNSSEC validation even if the DNS queries are done over TLS.
>
>
>> The Registry can be completely trustworthy, but the weak link is
>> unchanged -- the Registrar-Registry update mechanism, which relies on
>> Registrar credentials.
>> Those credentials are applicable to use for updates to any/all Registrant
>> records (i.e. every Registrant that uses that Registrar).
>> It doesn't mean the Registrar isn't trustworthy either.
>> It only means the model is not as secure as would be the case if the data
>> required "proof of possession" of the private key, e.g. signing the DS.
>>
>
> Sounds good to me. You could write a draft for REGEXT.
>
I almost certainly will, or at least co-author such a draft.
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
