From: Wes Hardaker <wjh...@hardakers.net>
Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> writes:
A few comments:
1. the MUST NOT in the first paragraph in 5.2 really feels like it should
be a SHOULD NOT. Though its not wise, there could be scenarios where
someone really wants to do it and if they feel it's operationally
possible then they should be allowed to.
In general, my view is that compliance with the mandatory requirements should
be sufficient for interoperability. If this requirement is not mandatory, that
creates an interoperability problem with the next paragraph's rule that
"service operators MAY reject TLS connections whose SNI does not correspond to
an approved TLSA base domain".
[I had a really hard time
writing this, as I think you're right about the importance, but we do
try to opt for SHOULD NOTs unless it always breaks something]
Personally, I tend to think that things that reliably break in some visible way
don't really need normative language, because implementors will figure out that
it's broken. "MUST NOT" is most important when the problem is subtle,
systemic, or delayed, as in this case.
Also, note that there is an escape hatch here ("unless they have an explicit
arrangement ..."), so this is really not a technical requirement, and what
constitutes such an arrangement is open to interpretation.
2. in the security considerations, the first sentence in the second
paragraph seems like it should have a solid requirement in it. Maybe
"The SVCB and associated TLSA records MUST be validated by DNSSEC." And
this is one of those cases where the MUST feels right as it
significantly degrades the security of the protocol if only a SHOULD is
used. As such, I'd drop the rest of the paragraph.
We avoided this requirement for two reasons, both somewhat related to ADoT:
1. Unsigned TLSA records do exist (e.g.
dns:_853._tcp.a.ns.facebook.com?type=TLSA) and provide some security benefit in
situations where (a) full authentication is not well-defined or widely deployed
and (b) the attacker is on the application path but not on the DNS path.
2. There have been some Authenticated ADoT proposals that rely at least in
part on transport security rather than DNSSEC. We used the phrase "resolved
securely" to avoid prejudging that discussion.
--Ben
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
