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

John Scudder <jgs@juniper.net> Thu, 06 May 2021 20:04 UTC

Return-Path: <jgs@juniper.net>
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 02FD33A2EDF; Thu, 6 May 2021 13:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=nUYaPFow; dkim=pass (1024-bit key) header.d=juniper.net header.b=KjpdDpvI
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 iCkn-zLKhunR; Thu, 6 May 2021 13:04:03 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15F43A2FA8; Thu, 6 May 2021 13:04:03 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 146JxT5G029320; Thu, 6 May 2021 13:03:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=w9xiTthaaEh9XzvK21Bb9tGGZKqb1tAx0tQnfTk5koM=; b=nUYaPFow7MU2pBkeYL4ECBH56oORhe9cTaqlDU3Xt0ffhenWz6CZRsfyJGQXdqs4zhcf CD//cwDKcV/+p9vdW0CU/PmNPiZRvJDAcG5vC9GImmvVWimWIvl8GOxFtMUstug8DCgD 60udxzHjsjT9PSnLH8JJWHVaYvmfXtaztlM3Sc3u3MtNsknmp7vtYnyuoY4xAjuw5Oxe ZpvTkHMwYbaMFvdIou80B4tHjoBQAWSaKfnGaqmzZbofxMA0d0g2uQoqvFRQFwIKlPoz V/ySJkSDogvZ9x7i/XloUB3pAtwtXNXguyHWq/T+Esi4Skv3PCCTraPrcv+QfDH3p7zz MQ==
Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2177.outbound.protection.outlook.com [104.47.58.177]) by mx0a-00273201.pphosted.com with ESMTP id 38cjjv0h62-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 May 2021 13:03:56 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RU2+fdGwP+ID30/J4d4d/Q6/8YIZ4g0mMb1Je72keV8PlCWiSfgWvTn6UnhV6gEs/jbgVP+ah0kD0EJooQm9JQ1D25bu75tr3wp32JQzl5aavAtkke38Ha1Zl4Zzoms8jYowCeZjfODqQBznh5mdc5mSVRvr066/wNC1/z1EWgdZqPF3pyC1ZO6f8y+V9wEnWISqtfNcbuerq3oAftP9Q9aBiyWr4HdjcTlilPFxvmbBtqSDY2OOL780HQPkiKMvuktU7SBysrYw0Aecb8er0OWIfkmk4qeFjLufo0KjPwVbCGSJ13nrRN9JbvSFm27lmni7v15laDEcDcD7YDjJdQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w9xiTthaaEh9XzvK21Bb9tGGZKqb1tAx0tQnfTk5koM=; b=D54vkQLO8HsDBaCEjKz0Vq0SYo/Ks5YzVT1RQ8FpPriLoJQ/j7cPg06J0zclTl9D4kY3yIcZN6PINhJLJWKIh9ER9xH4FxLWSv5bfD4w/bumTxkL1EjP2vzRDfKunlGKyRwrvtWbonjHjTPhCSJBZVlp9A35+UeIDScCyrjrkpOippINIRr88foZYuqszq06lmkxtw76wn3EH2hUR12ULx8BOVcHqrGnmDA/wxaTR36u5nH01oHubwhAe9hVZuCxFj0ZwJ1tQkgYmv1mNGKo6TPMAK3ki5I8p7PHGFHYO9jzN7qkaPgogTOzd/dSxzOfnSOEZEVElvBBzZLIF0myNw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w9xiTthaaEh9XzvK21Bb9tGGZKqb1tAx0tQnfTk5koM=; b=KjpdDpvIoA3sLVU7GMnHCAxYY+GCvH+foVMRC4WAt8nIHUmF32FA1zCE20lLIweunvz8pyys1T//lK0XOIJ7G15C+NQZSu4pNXD6EHKw9UNEaM5wKQ+GZCGZZIvYsYK86lPS8rpued8cJPKx/Xuo+yfH87sSVeBOPhu1Lavl4eA=
Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6062.namprd05.prod.outlook.com (2603:10b6:208:c5::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4129.9; Thu, 6 May 2021 20:03:52 +0000
Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1%5]) with mapi id 15.20.4108.028; Thu, 6 May 2021 20:03:52 +0000
From: John Scudder <jgs@juniper.net>
To: Sara Dickinson <sara@sinodun.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-dprive-xfr-over-tls@ietf.org" <draft-ietf-dprive-xfr-over-tls@ietf.org>, "dprive-chairs@ietf.org" <dprive-chairs@ietf.org>, DNS Privacy Working Group <dns-privacy@ietf.org>, "tjw.ietf@gmail.com" <tjw.ietf@gmail.com>
Thread-Topic: John Scudder's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)
Thread-Index: AQHXQSB9DHCNH62/dU6l5xdWsxmAOarWPpmAgAClBAA=
Date: Thu, 6 May 2021 20:03:52 +0000
Message-ID: <5BE1530C-8DA4-4434-B27F-3EFDC0669705@juniper.net>
References: <162015857648.17895.7104332787108510127@ietfa.amsl.com> <677892E5-D12B-4212-82C0-0ADC60C3D4AE@sinodun.com>
In-Reply-To: <677892E5-D12B-4212-82C0-0ADC60C3D4AE@sinodun.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.6)
authentication-results: sinodun.com; dkim=none (message not signed) header.d=none;sinodun.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [162.225.191.192]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 34929a7a-c992-4f81-c6bb-08d910ca1258
x-ms-traffictypediagnostic: MN2PR05MB6062:
x-microsoft-antispam-prvs: <MN2PR05MB60629D3F553DB84249D8755DAA589@MN2PR05MB6062.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:5516;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: sLYbJJIN04BhwJ9omFEDurYFbJZF1RNpmW+yk3GKm+eepjaKn2AQMXmudlwqTinW9VypxMOxY1nF3OvwEw/bzhku+3G9gaGKurFb+LoQqnVkVi+hQEuDLhYawoX0IYmTDqfTe+3ocAkVZy+Sp8eHUXgoGVxcCNvTuSV8oxygGOga5/v7wCqBUytL++HKCqcGnU+Bce+KQGRMivZUqfsS+4b9rLTkWEcLNgBn2YcRfIhMlot4ljWCf91CybS2vMDHvYnf91mSP8QlWM7e9fNMI/GVdaUT7vM2xByvoBCskadOSrrQlblFEdLWpywKYoMTcqegRwbInsOmoHCa3ALPxiKlMBTDXSh4p5MA7d7AUy6qneBsVwPREZWfHLoppACl+4atrkJ8asDIY6WMZw0zz0hZItnipB2w0Iorevo+0aYy7gGZtrewDQNvRgoXuNj7Q7hn5NnF43LuToFP0g4iidDxiG1Mz1Djt2eK7W27XJqfoVm+IEwDdGZRlEcpUJwKOiTOfpIxlwWzunLrWy3LY3/L+v/8+d3DZTq2LZBy0BB+ZGFpQqaFRmyxLvJTj9yUh5coX0++jT0W9DvN6eQEXvcKe9PBY0ZTyC1hqyE46CSsC17g+M/aEUtsvGBSO3uSRzJUpv0/U/uU2ij+iMgBl80nLkUlbWCbnTzZ02gFJriajxztvgXq1a9ASQmY63XynYufECb8wI2XqkBIY1SR48UmwI0gJSQ51QTmVbcxyKc=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(346002)(376002)(366004)(396003)(2616005)(966005)(6506007)(66946007)(71200400001)(8676002)(91956017)(166002)(53546011)(2906002)(186003)(8936002)(36756003)(26005)(6486002)(83380400001)(33656002)(4326008)(316002)(66446008)(64756008)(76116006)(6916009)(122000001)(5660300002)(86362001)(38100700002)(66476007)(478600001)(66556008)(54906003)(6512007)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?ZGV4VkJNZ3ZNQ25UK1JnazNHUTZNdTB3c2hGT05kK3FEVm5PNDRUMEw4SG1E?= =?utf-8?B?N0pFY1JTTG1DMjhBeHFpTEsrdGVHbFFQTk1JSUdsM1dCMmlwejZDQUEvMjUv?= =?utf-8?B?YTdxQzFKbzQvVmhZbFhEdFEyZWpQWVdzQ3JPNVlKUWl0aU94Y3NjOXlmNTBW?= =?utf-8?B?SERPWjdUeExHazI4QlJLQVYraGtCRkI1a09tVmZ5bXV3a0luUkxiYTBGbnRY?= =?utf-8?B?dWIvMDkxbVUwVVVCbFFndzE4dGFuTDNRY0F4dkYrSXQ0UG1wcTlFcjBoMTB3?= =?utf-8?B?cENHbUpuRjVUM2x1ajA0S3dSZXJ6K1FkVzdlNVo3MW9rbEFOWFl5TmhnbVA0?= =?utf-8?B?MGtocTJOZC9iQ0NYWHlHaVpRNEN1c3VDOTZVTUZ6SlV6amJwd2FTM2lqSXZW?= =?utf-8?B?VUxsdyt3WmozVGp3cElHcXB4OWZ0aW5sNW5kdE1BVjlDREoyM1RhSDJNSk5F?= =?utf-8?B?ZmxmL2VBK0p3b25HTW1yQmg3azVEcC9zSXkzN0d0Q1czRFNHanU4a2wxTFZO?= =?utf-8?B?N2NuZE5GNEdmakZYVm5tUlhxdVhrNTl5QTVpVzNQdm50N0ZzcHpYZTZCN3Ja?= =?utf-8?B?clMzWGJ1NjJCaW5Wa1dRWFNTUGpWTkRCQ2E2ci84NDVQSEpZY3JmYXNZVUJ4?= =?utf-8?B?Q0JURkxFWTlxZHN5cFYyU0JTbjc2U0pNSkljdGlCR29ZQmlGaUdkUTdkcllP?= =?utf-8?B?aElwWHFmTFd5dzA0OFNNYmNmRm1qd3BCWlJRQTBWY2FsRWVReFZRdlhkeElX?= =?utf-8?B?MVJUWDJRSlZSdmZzd3A5R3NGWks5ODhhRTRjSzRocUVBR0FGVitYTjcwNUw3?= =?utf-8?B?VUV4cTZiWFpISVlxY3duR0F2TmNZZGc2MzVrUW9lTU4wSldXL0RHV2FLd1pz?= =?utf-8?B?U0hETlVhZnJUcHdCNlU0bGNidUR1N2RaaG5uUjdOeW1UOXZoUXVURzdsblpx?= =?utf-8?B?QzhwOEJSL0JhNXZnYWwremszR3pIcUdBNnVWbVF2QXI0RENtY01UQVZZek9X?= =?utf-8?B?aDU1N0ZhVEY2aVdzaGlqT2hXZ1RsalBETVpyVndOVTBqNHJSSFgvNmRYM2gv?= =?utf-8?B?U1BEb0l1YmhWaGRaaDZxTERaRjZUTDhUWUNPKzlsUjYzSGRiOXlJbXQrZUNM?= =?utf-8?B?bTJjdHJCMGdSQk9KWmwxdElTT2VxaHdWQ2UwcGlSYU5ycHpqTWptY1NGQ09S?= =?utf-8?B?eEcyQ0Myd1pvUzVZamYvR3RaVEo3SEpKU1pEb2R5MmI5OFV3QS9STXcwSTRw?= =?utf-8?B?S2FTMWVmcjR6c1o4ZmRYamZmK2lPSzk4N2Foc2hpdFpUMmRGdTV6R3A4R0Fl?= =?utf-8?B?U2k4ZFlCNXFsQS9FNlZzelZNY0ZuNVM4R3kvS3hxSFVVSXVBRVpXSVA3WVh1?= =?utf-8?B?a2ZxdnZ2NFY1WnpPTlE2UGRSK3hWbzJpWElUVzhVcHgzaXZHWW9sSVpja3di?= =?utf-8?B?OGlIYSswVkUvb2xpK2dxYWJxS2NGeFhPbjhGUGlYMEM1dHFhbkl6QnNPQ2RK?= =?utf-8?B?WnlBcUVnaHRDckhxc0U0SXVNb2JMNnZRRisrbFllNGZOcVFSazQ5c0RxZDF3?= =?utf-8?B?RjIrek1MdWpaK3FLWEVnNUhMUEhxaExrQlYwL0I5RmNNWEF1dXhLN29LeWZB?= =?utf-8?B?aUwxNGhKaDZ2eUVFdk1Kb0VjUmZsRVNJQktoTERqR1BRZkNoUm9JVXJscnl2?= =?utf-8?B?ODRsWWttd04xU2Nkc1dKZU1ydFpDaUJDSFk2bFlOSlFtYmxtbVZ4bDlEa2kw?= =?utf-8?B?ZjlieVExYTRLbXYzWUoxdVROcklGTjNNbi9acGY1cTQ4cXpna2NNRTQxQXcx?= =?utf-8?B?NEF1SXhrSFJHdHVIZko3UT09?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_5BE1530C8DA44434B27F3EFDC0669705junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 34929a7a-c992-4f81-c6bb-08d910ca1258
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 May 2021 20:03:52.5172 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CHpTnGzw72QCsANdXg+QrHG/lywBrU9ypztze1gfcyYxFVjyEWn1LCcpKEgI66oT
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6062
X-Proofpoint-ORIG-GUID: mNwfvyPVvWSsvmsC3YFl-xBHkhXmXOEc
X-Proofpoint-GUID: mNwfvyPVvWSsvmsC3YFl-xBHkhXmXOEc
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-06_10:2021-05-06, 2021-05-06 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 spamscore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 phishscore=0 suspectscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2105060138
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/bQMkhGIIPylUYtLCIb0vllQvVLw>
Subject: Re: [dns-privacy] John Scudder'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: Thu, 06 May 2021 20:04:10 -0000

Hi Sara,

Thanks for your prompt reply. In short: that all sounds good. I’ll move further discussion, if any, of point 9 (IP ACLs) to Ben’s thread.

Regards,

—John

On May 6, 2021, at 6:13 AM, Sara Dickinson <sara@sinodun.com<mailto:sara@sinodun.com>> wrote:


On 4 May 2021, at 21:02, John Scudder via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:

John Scudder 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!RSdMPZScekk0Bl8Y_uEy97Zb7mgbnIzs_Eyz8fNRTHPux5ABrf-whrGWP5iqug$
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/__;!!NEt6yMaO-gk!RSdMPZScekk0Bl8Y_uEy97Zb7mgbnIzs_Eyz8fNRTHPux5ABrf-whrGzhqb-PA$



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

Thanks for the well-written and easy to follow spec. Below are some comments
you may want to take into consideration.

1. Abstract

 XFR-over-TLS (XoT).  Additionally, this specification updates
 RFC1995, RFC5936 and RFC7766.

Please say a few words about how the spec updates those RFCs, don’t make the
reader go digging for it.

Propose:
"Additionally, this specification updates RFC1995 and RFC5936 with respect to efficient use of TCP connections, and RFC7766 with respect to the recommended number of connections between a client and server for each transport.


2. Section 1

 transfers (this draft) is orthogonal to preventing zone enumeration,
 though they aim to protect the same information.

s/this draft/this document/


3. Sections 6.1, 6.2

 3.  If the primary serial is higher than the secondaries serial

s/secondaries/secondary’s/


4. Section 6.3

 This section attempts to presents a rationale for considering

“Attempts to present”. But really, why not just “presents”?

5. Section 6.3

 Since the SOA of the published zone can be trivially discovered by
 simply querying the publicly available authoritative servers leakage

Comma between “servers” and “leakage”.

Ack to all the above corrections.


6. Section 6.3.2

 For hidden primaries or secondaries the SOA response leaks only the
 degree of SOA serial number lag of any downstream secondary.

I don’t understand. This either means the sentence would make sense if only I
had the right domain knowledge (which is OK then), or it means the sentence
doesn’t make sense (which isn’t).

Probably better written as:

“For hidden XFR servers (either primaries of secondaries) an SOA response directly from that server only additionally leaks the degree of SOA serial number lag of any downstream secondary of that server.”

Does that help?


7. Section 7

 The following sections include detailed clarifications on the updates
 to XFR behavior implied in [RFC7766] and how the use of [RFC7828]
 applies specifically to XFR exchanges.  It also discusses how IXFR
 and AXFR can reuse the same TCP connection.

“They also discuss” — agreement in number with “the following sections”.

8. Section 7.4

 This specification for XoT updates the guidance in [RFC7766] to
 provide the same separation of connection purpose (regular queries
 and zone transfers) for all transports being used on top of TCP.

The “for XoT” confuses this sentence, making it sound a bit like the advice is
restricted to XoT. I think those two words should be struck, it would be just
fine as “this specification updates…”

Ack to both.


9. Section 8.1

 For improved security all implementations of this specification MUST
 use only TLS 1.3 [RFC8446] or later.

Improved compared to what? I think the first three words could go, then the
question wouldn’t come up.

Ah - compared to stub to recursive DoT which was specified in 2015 and only required to use TLS 1.2 or later….but I’ll update as suggested


9. Section 8.4 (also 10.4)

 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)

The former is weaker, surely? I see Martin also raised this in his comments, I
agree with what he wrote. It’s odd to see these two authorization methods, with
very different security properties, presented as equivalent with no discussion
anywhere of their relative (de)merits.

Please see the thread in response to Ben’s DISCUSS on this.


10. Section 8.8.1 (also 8.9.3)

 The goal of padding AXoT responses would be two fold:

“Is”, not “would be” (also 893)

11. Section 10.2

 SIG(0) [RFC2931] similarly also provides a mechanism to digitally

Similarly, or also — pick one.

12. Section 11

 The XoT authentication requirement specified in Section 8.4 addresses
 the issue of ensuring that the transfers is encrypted between the two

“Transfers are” or “transfer is”.

13. Section 11

 endpoints directly involved in the current transfers.  The following
 table summarized the properties of a selection of the mechanisms

“Summarizes”

14. Appendix A

 For completeness, it is noted that an earlier version of the
 specification suggested using a XoT specific ALPN to negotiate TLS

Please define APLN on first use

Yup to all the above.


15. A.4

 As an aside, whilst [RFC7766] makes a general purpose distinction to
 clients in the usage of connections (between regular queries and zone

Do you mean “general purpose distinction between clients“? The use of “to”
doesn’t make sense to me.

The advice referred to is advice for clients about how many connections they should open. Suggest:

“makes a general purpose distinction in the advice to clients about their usage of connections"


16. A.4

 Client behavior to REFUSED response is not clearly defined (see
 below).

I do not see anything relevant below.

Good catch - this text used to be in the body of the document. It should reference section 8.7.

Thanks and regards

Sara.