Re: [dns-privacy] Benjamin Kaduk's Discuss on draft-ietf-dprive-xfr-over-tls-11: (with DISCUSS and COMMENT)

[Sara Dickinson <[e-mail]>]

> On 19 May 2021, at 04:08, Benjamin Kaduk <[e-mail]> wrote:
> 
> Hi Sara,
> 
> On Thu, May 06, 2021 at 03:08:34PM +0100, Sara Dickinson wrote:

Hi Ben,

<snip>

>>>> 
>>>> 
>>>> Section 8.4:
>>>> 
>>>> OLD:
>>>> "  o  the server MUST validate the client is authorized to request or
>>>>    proxy a zone transfer by using one or both of the following:
>>>> 
>>>>    *  an IP based ACL (which can be either per-message or per-
>>>>       connection)
>>>> 
>>>>    *  Mutual TLS (mTLS)
>>>> 
>>>> NEW
>>>> 
>>>> "  o  the server MUST validate the client is authorized to request or
>>>>    proxy a zone transfer by using one or both of the following:
>>>> 
>>>>    *  Mutual TLS (mTLS)
>>>> 
>>>>    *  an IP based ACL (which can be either per-message or per-
>>>>       connection)
>>>> 
>>>> If only one method is selected then mTLS is preferred because it provides strong cryptographic protection."
>>>> 
>>> 
>>> I think in some sense even being listed as sibling bullet points can imply
>>> "equivalent" for some readers, and accordingly this is not what I see as an
>>> ideal change.  But the new text does acknowledge the qualitative difference
>>> and is something I would be able to accept, even if it is not my most
>>> preferred outcome.
>> 
>> One option here is to update the second bullet point to be a combination of IP ACL + TSIG to provide additional protection. As mentioned, this is what is done in practice today by anyone who wants to control TCP zone transfers. TSIG was earlier discounted as a standalone option (see my comment below) and with hindsight I’m surprised we didn’t propose the combination instead. 
> 
> The combination does seem much more powerful than either alone.  I'd be
> happy to see that change, if there's support from the WG for it.

I’ve chatted with a couple of the other authors and we suggest that we make this change (and any other changes needed for consistency) in the next version and discuss the level of review required with AD/chairs?

> 
> In light of the other topic (below), do we want to consider reformulating
> the requirement along the lines of "MUST validate the client is authorized
> to request or proxy a zone transfer.  The following methods are deemed
> sufficient, and implementations may also use other methods that provide
> equivalent or better protection”?

I would personally be reluctant to make that change (as would the other authors). The introduction discusses that there are a variety of other ways to protect zone transfers. I would argue we should clearly define exactly what constitutes ‘XoT’ as per this specification, rather than leave it open ended. 

> 
>> <snip>
>> 
>>>>> 
>>>>> Relatedly, the text in Section 8.4 says that TSIG/SIG(0) are "not
>>>>> sufficient to authenticate the client or server", which is technically
>>>>> true, but also seems misleading.  In XFR scenarios it's not clear that
>>>>> specific identification (authentication) of the counterparty is
>>>>> necessary for secure operation, if authorization to receive/send the
>>>>> zone can be established without specific identification.  My
>>>>> undersatnding is that, when combined with a strict TLS profile for
>>>>> server authentication and appropriate trust policy on TLS clients, TSIG
>>>>> and SIG(0) both serve to provide proof of authorization for the exchange
>>>>> even though they only provide authentication in the form of group
>>>>> membership (the relevant key material is typically available to multiple
>>>>> machines).  As such, don't they provide strong enough cryptographic
>>>>> protection (and end-to-end, no less!) to be a superior authorization
>>>>> mechanism than an IP ACL?  (Any resulting text changes may bleed into
>>>>> Sections 11 and 12 in addition to 8.4, per my COMMENT.)
>>>> 
>>>> So I _think_ your question here is why isn’t TSIG also considered a valid option in combination with Strict TLS?
>>> 
>>> Yes, that's a fair summary.
>>> 
>>>> The reason is that TSIG signed requests can be forwarded by a third
>>>> party. The signature is ONLY over the DNS message payload, so it doesn’t
>>>> cover the identity of the originator. That means that if only a TSIG is
>>> 
>>> Yes.  Part of my point is that the specific identity of the originator is
>>> not always needed, if authorization to receive a transfer can be determined
>>> without knowing the actual identity.
>>> 
>>>> required, the server cannot be sure that the client originating the TLS
>>>> connection is not an on-path attacker forwarding requests, and therefore
>>>> inspecting the zone transfer responses. (The real value of TSIG is that
>>> 
>>> Yes.  But in order to get into such an on-path position the attacker would
>>> have to compromise the strict TLS required by the original client. An
>>> attacker that can do that could also inject themself as on-path for a pure
>>> mutual TLS solution.  In this sense we could consider that, when an
>>> (authorized) client sends an XFR+TSIG to a proxy on a TLS connection where
>>> strict server certificate validation has succeeded, the client is
>>> delegating its authorization to receive the XFR to the proxy, and thus that
>>> the proxy is also authorized to receive the transfer.
>> 
>> One concern is that an attack or misconfiguration that resulted in the client sending the XFR request in clear text would allow the attacker to obtain the signed message for replay. Since this is a migration from a clear text protocol to a TLS based protocol that doesn’t seem impossible. Whereas compromising mTLS directly is somewhat more challenging? 
> 
> It's a valid concern in migration scenarios, yes.
> 
> My preference (as always) would be to get some text in the document that
> covers the properties that TSIG+strict-TLS provide, 

There are a couple of places that need tweaks for the move to the combined IP+TSIG model - I think the required update to the bullet points in section 11 Section (describing the properties of the combined mechanisms) should address this.

> as well as the
> perception of risk in the migration scenario that TISG migh be sent without
> (strict) TLS and the consequences should that happen.  That would be
> useful, IMO, regardless of whether it ends up being a recommended/permitted
> option or not.  I am sensitive to concerns about adding a lot of new text
> at a late stage without sufficient review, though, so I will ask if you
> think we can come up with such text and get it reviewed or not.

We do already give a general warning in section 12: 

“  An individual zone transfer is not considered protected by XoT unless
   both the client and server are configured to use only XoT, and the
   overall zone transfer is not considered protected until all members
   of the transfer group are configured to use only XoT with all other
   transfers servers (see Section 13).”

and later in the same section we touch on how to test/validate this. Section 14 highlights to use ‘migration mode’ with care. So assuming the IP+TSIG combination is a MUST, I’m not sure we need to add a specific call out for cleartext TSIG here? 


Best regards

Sara.