On 7/28/26 15:27, Stephane Bortzmeyer wrote:
On Mon, Jul 27, 2026 at 11:57:08AM -0700,
Wes Hardaker <[email protected]> wrote
a message of 34 lines which said:
I don't actually think that a particular security mechanism should
be demanded, but rather (since this already requires operator
agreement and configuration) that the needed attributes of
communication (authentication/encryption) be specified instead and
list some examples like TSIG, TLS, etc.
Yes, for configuration, since it is in a closed group, there is no
pressing need of standardization.
However, it is not for the case for the implementation in
software. Imagine Unbound implementing only TSIG and BIND implementing
only DoT.
I'd would expect the document to start with high level motivations,
noting that even within a given administration realm that different
implementations might be used and this work standardizes cache
sharing across implementations.
OK. (I even wondered at a time if it is a good idea to design a
standard protocol since it is only for closed environments but, yes,
even inside an organisation, you can have different software.)
The document states that all the entities must be within the same
organizational domain, which may or may not be true if organizations
or collaborations exist. Why is this particular stipulation
necessary? If two organizations wish to share data, so be it (with
privacy considerations discussed of course).
Right, we should write "group of organisations where there is mutual
trust" instead of just "organisation".
I wonder whether or not the usage of the TSIG secret key is a sufficient
internal mechanism within codebases to easily determine the intent of
the message.
Good point but I don't know. Opinions from implementers?
Normally a TSIG signed response includes the request MAC (in the data to
be signed, see https://www.rfc-editor.org/info/rfc8945/#section-5.3 ),
but since there was no request, the response is TSIG signed as if it
were a request, without including earlier MACs. I think this already
uniquely identifies this as a message with the intent described in the
protocol.
There could also be additional access control, such as IP addresses
allowed, (mutually) authenticated DoT etc. But only with TSIG, it can be
determined from the message alone.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
