On Mon, Aug 16, 2021 at 11:16 AM Ben Schwartz <bem...@google.com> wrote:
>
>
> On Sat, Aug 14, 2021 at 7:37 PM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> On Sat, Aug 14, 2021 at 3:47 PM Paul Hoffman <paul.hoff...@icann.org>
>> wrote:
>>
> ...
>
>> For the DRPIVE use cases, draft-schwartz-ds-glue allows a resolver to
>>> discover SVCB records in a response from the parent, even if that parent is
>>> not configured to put SVCB records in the Additional section.
>>>
>>
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.
The "glue is necessary" draft clarifies this.
Protecting that glue improves the security model of that glue, which is
essentially "where do I go to get the child zone"?
DNSSEC provides the necessary protection on the data integrity on the
zone(s), but not the name server(s).
The security model for name server names' zones mirrors that of
registrant's zones, since it uses the exact same standards (DNSSEC).
There is no DNSSEC model for avoiding a two-phase method for obtaining any
signed data from the name server names' zone(s).
The best that can be done without re-engineering DNSSEC, is the benefits of
caching the first phase (getting the validated DNSKEY(s) for the name
server names' zone(s), which are used to validate RRSIGs on data served in
those zone(s), needed for getting TLSA records if those are used.)
The larger discussion of strictly opportunistic vs downgrade-resistant TLS
to the authority server, needs to happen first, IMHO.
Those two models are fundamentally incompatible. You cannot have strictly
opportunistic (using WebPKI) and also have downgrade-resistant TLS.
The prior work by Viktor in the DANE SMTP has pretty much cemented that, as
well as having demonstrated that this is both feasible and scalable.
>
>> While this is technically accurate, it is (IMNSHO) problematically
>> insecure.
>> SVCB records in a signed child domain would be protected by a real DS
>> record (signed by parental RRSIG), and RRSIG in the child domain.
>> Any SVCB record added to the parent domain via the "ds-glue" mechanism
>> would NOT be signed by the child. The RRSIG of the new DS record would
>> prove that the new DS record was not tampered by an active attacker (etc),
>> but would not provide the data integrity offered by DNSSEC.
>>
>
> I don't agree with this characterization. In the DNSSEC security model,
> data signed by the parent has the same level of DNSSEC protection as data
> signed by the child.
>
In the DNSSEC security model, the only parental data that is signed is the
DS record (and obviously NSEC(3) records).
The security model on the DS record is that all of the following are part
of the secure delegation that get validated (by validating resolver):
- RRSIG on DS record is verified using ZSK (or CSK) of the parent domain
- Child domain apex is queried for matching KeyTag KSK with matching
DNSKEY algorithm
- Child domain RRSIG(s) over DNSKEY set verified (but the latter are not
yet part of the trust set)
- DS record is recreated from inputs, and compared to DS received
originally
You cannot take child data and place it in the parent, and sign it with the
parent's ZSK, and claim it has the same degree of protection as when it was
signed by the child ZSKs.
>
> I'm a strong advocate of discovery and use of SVCB records for both
>> opportunistic and downgrade-resistant (authenticated) use cases.
>>
>> SVCB in the child nameserver name domain is the right place to put SVCB
>> records, as the name server name is the association needed for TLS.
>>
>
> 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.
The SVCB also is controlling the transport and potentially other parameters.
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.
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
- 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
- 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)
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.
>
>> - 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_.
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.
Securing existing glue (no new data per se, but adding encoding and
signing) is something Registries could do, and pursuing that has potential.
Adding new data on the parent side is likely to be problematic.
Thus, the concept of using DS records to encode _existing_ data to enable
validation, is likely to not be controversial.
It is the difference between "letter of the law" and "intent of the law".
IMHO, at least.
So, TL;DR: CDS isn't going to happen outside of a handful of ccTLDs. DS
encoding would work fine for existing glue. Who does that and how it gets
added to the parent is a (the?) problem that needs to be solved. SVCB (or
similar) in the DNS operators' zones is adequate for downgrade-resistant
TLS.
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. 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.
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
