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

[Benjamin Kaduk <[e-mail]>]

Hi Sara,

On Wed, May 05, 2021 at 04:09:55PM +0100, Sara Dickinson wrote:
> 
> 
> > On 5 May 2021, at 05:44, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ———————————————————————————————————
> 
> Hi Ben, 
> 
> Thanks for the review. I’m addressing just the DISCUSS points in this mail and will follow up separately on the COMMENTS:

Sounds good.

> > 
> > My understanding is that this point is essentially overtaken by events,
> > as a similar concern was raised already by Martin D, John, and Roman,
> > and there is a commitment to update the text already made.  I'm putting
> > it in at the Discuss level to make sure that I follow-up on the revised
> > text when it appears.
> 
> As Allison already stated in reply to Martin, the authors agree that the `dot` ALPN should be used here, in light of the recent discussions. 
> 
> In terms of updating the text, I believe what is required is to add a new section at the start of section 8:
> 
> "8.1 Connection establishment
> 
> During connection establishment the ALPN token “dot” [ref] MUST be selected in the crypto handshake.”

(I'd s/crypto/TLS/, myself, but that's hardly critical.)

> I believe the later text relating to XoT vs ADoT in section 8.6 is still fully applicable, unless you see something you believe also needs updating? 

I also think that part looks fine.

> I will also update the first paragraph of Appendix A to reflect that the main reason for not using a separate ALPN (as originally proposed) is actually because XoT is DNS and so should share the `dot` ALPN. 

Good catch; thanks!

> > 
> > But, for concreteness: the text in Sections 8.4, 10.4, and 11 treat
> > cryptographic mTLS, TSIG, and SIG(0) authentication as providing an
> > equivalent level of protection to the (non-cryptographic) IP ACL.  My
> > understanding is that IETF consensus is to prefer cryptographic
> > mechanisms for authentication and authorization, when available.
> 
> That wasn’t the intention at all, and we are happy to add text to clarify that. 
> 
> To address this I would propose the following updates:
> 
> 
> 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.

> Section 10.4 (similar to text already proposed to Martin Duke). Add at the end of the second paragraph:
> 
> “mTLS provides a stronger authentication of the client than an IP ACL because it is based directly on a cryptographically verified identity.”
> 
> 
> Section 11:
> 
> OLD:
> “The following table summarizes the properties of a selection of the mechanisms discussed in Section 10."
> NEW:
> "The following table summarizes the high level properties of a selection of the mechanisms discussed in Section 10 (it does not, however, imply that methods that share the same basic property provide equivalent protection.)
> 
> OLD:
> “ * Using just Mutual TLS can be considered a standalone solution since both end points are cryptographically authenticated.
>   * Using Strict TLS and an IP based ACL on the primary also provides authentication of both end points”
> NEW:
> “  * Using Mutual TLS is a standalone solution since both end points are cryptographically authenticated. This is the preferred mode because it provides the strongest protection.
>    * Using Strict TLS and an IP based ACL on the primary also provides authentication of both end points, although here only the server is authenticated cryptographically.”

This seems fine, thanks.

> > 
> > 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.

TSIG of course does allow more than one proxy in a chaing, which does
introduce questions of transitive trust, but I believe that an attacker
that is capable of compromising strict TLS + TSIG is also capable of
compromising mutual TLS.

> the client can be sure the response hasn’t been tampered with and so it
> has a valid XFR response before applying the update, but in practice it
> is also widely used today in combination with IP ACLs to limit the
> sending of XFR responses). 
>
> I think we could improve the text to clarify this. How about:
> 
> Section 8.4
> OLD:
> “The server MAY also require a valid TSIG/SIG(0) signature, but this
>   alone is not sufficient to authenticate the client or server.”
> NEW:
> “The server MAY also require a valid TSIG/SIG(0) signature, but this
>   alone is not sufficient to authenticate that the TLS client is authorised to receive a XoT transfer (e.g., is not an on-path attacker forwarding TSIG/SIG(0) signed DNS message payload.)”

In light of my above remark, while this seems to be an improvement over the
old text, I'm not sure that it's the right end-state.  If we consider
sending XFR+TSIG to an authenticated proxy as a delegation of
authorization, then the TLS client in this case would actually be
authorized to receive the transfer.

> And then in section 10 I’ll make clear that only the DNS message payload is signed with TSIG (it currently says ‘message/DNS message’, which is unclear). 

(This is worth doing regardless of the previous stuff.)

Thanks,

Ben