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

Martin Duke <martin.h.duke@gmail.com> Mon, 03 May 2021 18:31 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813053A1FA2; Mon, 3 May 2021 11:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVl3EpohCU8Z; Mon, 3 May 2021 11:31:49 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BCF3A1FA4; Mon, 3 May 2021 11:31:48 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id y10so4415581ilv.0; Mon, 03 May 2021 11:31:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=195vaWuYSQw59JU9X0KMGegFUVWVX1c3noOhUht5uTE=; b=NUPVQLTHL9a544M0TZ4s3NierL9eZdZKDHrGxqc39oOkwkN30VO6OHt/6u1lHBIEpP rLXMWPAA95gyONX1I/d86ZomWECvdQ2CSSEaFPJ9tymqT7lIi3QYyqGKPn9FNcG4vbcm q+3k0i6pICblRpYdVKx9VducsOidvVteP6WvrPHnJhVHjJPjj/qROMDfPIpX9tz34nWi 67YTWwr2bSHI2V7rVw8NqjSC9NXe4kwxBidm2SHSAPHBzGKf0+h2AB286Qm6YErCLv26 cZW0NF72aqLAwmGO+mXo4+qiiv+P9VtBD/0+zS7HbIjpmG+wURtuwP+oRfaptc9M/33q sTnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=195vaWuYSQw59JU9X0KMGegFUVWVX1c3noOhUht5uTE=; b=dH5w3xJSdfWEQohxHpXOnAbzxvxAFSZNXfqe/SfganAMo6t4DUT45GKFhhUHFbGBpo p0b6iudamIz1OVZ6fzhahX10rdd6/2GMcp1ngYcGnJLK3mJYml2rlHNfgz0YR75aUGZe YN2PpWmRmXlhCM4i4SMUnA5G3jHggYqTXGf3bkWSa5OKyCnkJEzGUEZW/6ZpOC4J5Z8a tV+ykr9hAZJN8vEJE96fzbTrknoA2CfzKosDh5a8pya9neREvABNHUyDKbdfnNvHm/CZ X4eEBf7TaV8VdxXNV8f/VjnvxechXQr3M2vvWsYvg7ju9eTU+gIwNayR+79f1rod2lGv 0MiQ==
X-Gm-Message-State: AOAM530LgFy+8wvNSCSJC/6DkhbhJQOvM3rAXpauRXptSMuXfO9J599L 25E3+wGpvwDOJq31EdgGxs3wDV0+I1UUbeML4+c=
X-Google-Smtp-Source: ABdhPJyP2R61BHEqrcPB1iwx/eEQg5D6hEbmTV2kfYU+trYxWVU8t+xDC8E6oKbaRiaNkLuVg8UH9Jzo2u0v02FVGbk=
X-Received: by 2002:a92:c78b:: with SMTP id c11mr17215256ilk.249.1620066707181; Mon, 03 May 2021 11:31:47 -0700 (PDT)
MIME-Version: 1.0
References: <161921129877.20343.10624609154750488813@ietfa.amsl.com> <034F6C49-0195-4FAF-9EF2-1E39E809F902@sinodun.com> <CAM4esxQrTNT+Pc1OAp5jpFgJNL1Tr3Wa4KbS7URR6zr3EwLQ8w@mail.gmail.com> <8527AA59-12FE-4CA7-A87D-AAA4BF3C2CC4@isc.org>
In-Reply-To: <8527AA59-12FE-4CA7-A87D-AAA4BF3C2CC4@isc.org>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 3 May 2021 11:31:44 -0700
Message-ID: <CAM4esxR5kj-L1Z=Ltr6cq=JpqKu-DFS5dJ_-kTWe+eN-kKW8-A@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Cc: Sara Dickinson <sara@sinodun.com>, Tim Wicinski <tjw.ietf@gmail.com>, dns-privacy@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-dprive-xfr-over-tls@ietf.org, dprive-chairs@ietf.org
Content-Type: multipart/alternative; boundary="00000000000098167f05c1712ccc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/dT-FbPjbPFU9UH3IKeeVj_jXX7Y>
Subject: Re: [dns-privacy] Martin Duke's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 May 2021 18:31:54 -0000

Ah OK, now that I see that the Message ID is a field in the DNS header,
it's clear to me these won't collide.

Regarding ALPN: I gather that IFXR/AFXR is distinguishable from regular DoT
on the wire, so that it would be sufficient (and preferred) to simply use
the DoT ALPN.

On Thu, Apr 29, 2021 at 5:30 PM Mark Andrews <marka@isc.org> wrote:

>
>
> > On 30 Apr 2021, at 09:28, Martin Duke <martin.h.duke@gmail.com> wrote:
> >
> > Hi Sara,
> >
> > >
> > > - 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.
> >
> > Then I guess I'm not sure how you're going to demultiplex with other
> traffic. Are you totally reliant on the port?
> >
> >
> > >
> > > - 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.
> >
> > 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.
> >
> >
> > >
> > > - 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?
> >
> > 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?
>
> 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
> > dns-privacy@ietf.org
> > https://www.ietf.org/mailman/listinfo/dns-privacy
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>
>