Subject: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

From: Martin Duke via Datatracker <[email-masked]>
Date: Fri, 23 Apr 2021 13:54:58 -0700

Martin Duke has entered the following ballot position for
draft-ietf-dprive-xfr-over-tls-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

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/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Please explicitly state that, IIUC, these XoT connections use the DoT ALPN.

- There ought to be a warning somewhere that mTLS verifies that the CA has
verified identity, while IP ACLs merely prove that the bearer can observe the
path to the address. The former is much stronger than the latter, unless there
are more mechanisms built into the ACL than are obvious from the text here.

- Please educate me: from my skim of the RFCs AXFR has message IDs, but IFXR
does not. So how would a client demux IFXR responses?

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 28 Apr 2021 11:27:35 +0100

> On 23 Apr 2021, at 21:54, Martin Duke via Datatracker <[email-masked]> wrote:
> 
> ———————————————————————————————————

Martin, 

Many thanks for the review.

> - Please explicitly state that, IIUC, these XoT connections use the DoT ALPN.

That is not actually the case, but even so, we should probably add text to clarify the matter. 

An early version of this specification proposed a XoT specific ALPN in order to distinguish this from a connection intended to perform recursive to authoritative DoT (often called ADoT). ADoT is not yet specified, but is the subject of ongoing discussions in DPRIVE. The working group rejected this idea for XoT and switched to the current spec which does not use an ALPN at all. Note that one of the proposals for how DoT support by authoritatives for ADoT would be signalled does use the DoT ALPN. 

> are more mechanisms built into the ACL than are obvious from the text here.

Agreed, and this follows up on a previous similar comment. We could add text to section 10.4 at the end of the second paragraph along the lines:

“Is should also be noted that mTLS provides a stronger authentication of the client than an IP ACL because the former is based directly on a verified identity.”

We could also add something to the security considerations but I struggled to find a good reference for the issues with IP address validation?

> does not. So how would a client demux IFXR responses?

IXFRs do use message IDs - they are defined as just ’normal’ DNS messages with the IXFR query type in RFC1995 and so inherit that requirement (although on re-reading it isn’t _explicitly_ described there).  In that original specification IXFRs can use UDP (or TCP) and so would definitely require message IDs for UDP. I’m not aware of any implementation that omits message IDs for IXFRs. Is there something else you saw that lead you to think otherwise?

I think the confusion could arise because in RFC1034/1035 only AXFR was defined and was required to use TCP, in contrast to other DNS queries at that time. The description of message exchange is vague and apparently lead to some implementations doing only a single AXFR transaction per TCP connection and therefore omitting the transaction ID.  The 2010 update to the AXFR specification (RFC5936) notes and corrects this confusion in section 4.1. 

Best regards

Sara.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 29 Apr 2021 10:09:05 +1000

On Wed, Apr 28, 2021, at 20:27, Sara Dickinson wrote:
> An early version of this specification proposed a XoT specific ALPN in 
> order to distinguish this from a connection intended to perform 
> recursive to authoritative DoT (often called ADoT). ADoT is not yet 
> specified, but is the subject of ongoing discussions in DPRIVE. The 
> working group rejected this idea for XoT and switched to the current 
> spec which does not use an ALPN at all. 

No new protocol should use TLS without ALPN.  It only opens space for cross-protocol attacks.  Did the working group consider this possibility in their discussions?

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 29 Apr 2021 13:51:29 +0100

> On 29 Apr 2021, at 01:09, Martin Thomson <[email-masked]> wrote:
> 

What the working group asked for following the ALPN discussion was that the document contain a description of the options an authoritative nameserver that supports XoT can use to manage TLS connections and the queries received on those connections  - that is provided in Appendix A: https://tools.ietf.org/html/draft-ietf-dprive-xfr-over-tls-11#appendix-A

As more context, the document also covers various existing mechanisms that can be used to manage zone transfers (including IP ACLs and TSIG) and how they combine with Strict and Mutual TLS authentication. The document specifies that the server MUST use either an IP ACL or mTLS to authenticate the XoT client. 

Regards

Sara.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 29 Apr 2021 13:10:04 +0000

Martin,

The IETF Last Call on this document has completed on the 20th of April 2021 but it is never too late of course.

I just added our security Area Directors in the loop so that know your question for their ballot due for next week.

Regards

-éric

-----Original Message-----
From: dns-privacy <[email-masked]> on behalf of Sara Dickinson <[email-masked]>
Date: Thursday, 29 April 2021 at 14:52
To: Martin Thomson <[email-masked]>
Cc: DNS Privacy Working Group <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

    Regards

    Sara. 

    _______________________________________________
    dns-privacy mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Apr 2021 14:26:36 +0000

>    No new protocol should use TLS without ALPN.  It only opens space for cross-protocol attacks.  Did the working group consider this possibility in their discussions?

I don't believe that message has been made as public as it should be.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Apr 2021 11:24:06 -0700

Probably not, but I agree with MT.

The general idea here is that any given protocol trace should only be
interpretable in one way. So, either you need the interior protocol to be
self-describing or you need to separate the domains with ALPN. I don't
believe that either the IP ACL or mTLS addresses this issue, and in fact
arguably mTLS makes the problem worse because it provides authenticated
protocol traces which might be usable for cross-protocol attacks.

-Ekr

On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> >    No new protocol should use TLS without ALPN.  It only opens space for
> cross-protocol attacks.  Did the working group consider this possibility in
> their discussions?
>

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Apr 2021 18:28:45 +0000

To make it obvious (I thought it was): I agree, and think we need to make that fact more widely known.

From: Eric Rescorla <[email-masked]>
Date: Thursday, April 29, 2021 at 2:24 PM
To: Rich Salz <[email-masked]>
Cc: Martin Thomson <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [dns-privacy] [TLS] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

The general idea here is that any given protocol trace should only be interpretable in one way. So, either you need the interior protocol to be self-describing or you need to separate the domains with ALPN. I don't believe that either the IP ACL or mTLS addresses this issue, and in fact arguably mTLS makes the problem worse because it provides authenticated protocol traces which might be usable for cross-protocol attacks.

-Ekr

_______________________________________________
dns-privacy mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dns-privacy<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dns-privacy__;!!GjvTz_vk!EtJaCTiH36U_bsA5vP82lZpBELKgq8908Dnb9MmdFc9M0FfjBeJMg3QwgwSs$>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Apr 2021 19:38:01 +0100

> make that fact more widely known.

I think I agree but seems like ECH may add a subtlety - maybe
what we need to promote is the idea that new protocols should
define new ALPN strings, but also that intermediaries can't
depend on those to route connections as the inner and outer
ALPN values can be independent in the case of ECH (use of
which might not that visible to the application if a library
were to default to use of ECH where possible).

Cheers,
S.

> 
> From: Eric Rescorla <[email-masked]> Date: Thursday, April 29, 2021 at
> 2:24 PM To: Rich Salz <[email-masked]> Cc: Martin Thomson
> <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]> Subject: Re: [dns-privacy] [TLS] Martin
> Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with
> COMMENT)
> 
> interpretable in one way. So, either you need the interior protocol
> to be self-describing or you need to separate the domains with ALPN.
> I don't believe that either the IP ACL or mTLS addresses this issue,
> and in fact arguably mTLS makes the problem worse because it provides
> authenticated protocol traces which might be usable for
> cross-protocol attacks.
> 
> -Ekr
> 
> 
> On Thu, Apr 29, 2021 at 7:26 AM Salz, Rich
> <rsalz=[email-masked]<mailto:[email-masked]>>
> wrote:
>> No new protocol should use TLS without ALPN.  It only opens space
>> for cross-protocol attacks.  Did the working group consider this
>> possibility in their discussions?
> 
> _______________________________________________ dns-privacy mailing
> list [email-masked]<mailto:[email-masked]> 
> _______________________________________________ TLS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/tls
>

---

From: Allison Mankin <[email-masked]>
Date: Thu, 29 Apr 2021 14:49:40 -0400

Hi Ekr,

As Sara wrote, the spec had ALPN. The WG consensus during the IETF 108
meeting was very strong to take it out, including quite strong statements
from you along the lines that distinguishing between XoT and DOT was an
incorrect usage of ALPN.

I understand that the perspective changed since IETF108 (that WG discussion
was at the end of July 2020) and that communications were not wide enough
for us to know about it in March when the WG moved the draft to WGLC,
Directorates Review, and IETF LC

On Thu, Apr 29, 2021 at 14:25 Eric Rescorla <[email-masked]> wrote:

> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Apr 2021 12:02:06 -0700

> from you along the lines that distinguishing between XoT and DOT was an

I don't have the message you are referring to at hand, so I'm not able to
respond to that. However, I don't believe that an ALPN is needed to
distinguish XoT from DoT because there is no confusion between the protocol
traces of XoT and DoT. However there should be an ALPN to distinguish XoT
and DoT from HTTP, SMTP, etc.IOW, this protocol should use ALPN="dot".

> Directorates Review, and IETF LC

I don't think anyone is saying that the WG somehow did something wrong
procedurally, merely that this is a defect that ought to be corrected prior
to publication.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 29 Apr 2021 12:03:31 -0700

> were to default to use of ECH where possible).

Correct. The purpose of ALPN in this context is to avoid cross-protocol
attacks on the endpoints. Reliance on them by intermediaries is difficult
absent some fairly strong assumptions about the endpoints.

-Ekr

> > https://www.ietf.org/mailman/listinfo/dns-privacy<
> https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dns-privacy__;!!GjvTz_vk!EtJaCTiH36U_bsA5vP82lZpBELKgq8908Dnb9MmdFc9M0FfjBeJMg3QwgwSs$
> >
> >
> >
> >

---

From: Martin Duke <[email-masked]>
Date: Thu, 29 Apr 2021 16:28:56 -0700

Hi Sara,

> order to distinguish this from a connection intended to perform recursive
> to authoritative DoT (often called ADoT). ADoT is not yet specified, but is
> the subject of ongoing discussions in DPRIVE. The working group rejected
> this idea for XoT and switched to the current spec which does not use an
> ALPN at all. Note that one of the proposals for how DoT support by
> authoritatives for ADoT would be signalled does use the DoT ALPN.
>

Then I guess I'm not sure how you're going to demultiplex with other
traffic. Are you totally reliant on the port?

> Agreed, and this follows up on a previous similar comment. We could add
> text to section 10.4 at the end of the second paragraph along the lines:
>
> “Is should also be noted that mTLS provides a stronger authentication of
> the client than an IP ACL because the former is based directly on a
> verified identity.”
>
> We could also add something to the security considerations but I struggled
> to find a good reference for the issues with IP address validation?
>

I don't have a reference, but something like your proposal is good enough
for me.

> IXFRs do use message IDs - they are defined as just ’normal’ DNS messages
> with the IXFR query type in RFC1995 and so inherit that requirement
> (although on re-reading it isn’t _explicitly_ described there).  In that
> original specification IXFRs can use UDP (or TCP) and so would definitely
> require message IDs for UDP. I’m not aware of any implementation that omits
> message IDs for IXFRs. Is there something else you saw that lead you to
> think otherwise?
>
> I think the confusion could arise because in RFC1034/1035 only AXFR was
> defined and was required to use TCP, in contrast to other DNS queries at
> that time. The description of message exchange is vague and apparently lead
> to some implementations doing only a single AXFR transaction per TCP
> connection and therefore omitting the transaction ID.  The 2010 update to
> the AXFR specification (RFC5936) notes and corrects this confusion in
> section 4.1.
>

This is as simple as me grepping for "message ID" in the IFXR spec. But if
these do exist, what protections do you need against ID collisions in
Section 7.3.2?

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 30 Apr 2021 10:05:48 +1000

(dprive to bcc, because this is getting further afield)

> I don't believe that message has been made as public as it should be.

I see that UTA is working on a revision of RFC 7525.  Is text on this something that would be in scope.  I only just searched for "ALPN", finding nothing, so maybe it is not in the original scope and maybe there are things that might prevent expansion of scope.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 30 Apr 2021 10:30:18 +1000

> On 30 Apr 2021, at 09:28, Martin Duke <[email-masked]> wrote:
> 
> Hi Sara,
> 
> > 
> Then I guess I'm not sure how you're going to demultiplex with other traffic. Are you totally reliant on the port?
>  
> 
> > 
> I don't have a reference, but something like your proposal is good enough for me.
>  
> 
> > 
> This is as simple as me grepping for "message ID" in the IFXR spec. But if these do exist, what protections do you need against ID collisions in Section 7.3.2?

On stream connections the client chooses a xid which is not currently in use.  If you need more than 2^16 outstanding transactions at once you open a new stream.  This has implications when forwarding signed UPDATE requests over a stream.  For TSIG the xid of the forwarded request is independent of the incoming request.  For SIG(0) you need to choose a stream where the xid is not currently in use.

For UDP you do similar by choosing source ports.

> _____________________________________________
> dns-privacy mailing list
> [email-masked]

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]