Re: [dns-privacy] New Version Notification for draft-zatda-dprive-xfr-using-dso-00.txt

Tom Pusateri <pusateri@bangj.com> Tue, 09 July 2019 22:29 UTC

Return-Path: <pusateri@bangj.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 CDF7312006D for <dns-privacy@ietfa.amsl.com>; Tue, 9 Jul 2019 15:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 W71R6YwMzyXb for <dns-privacy@ietfa.amsl.com>; Tue, 9 Jul 2019 15:29:07 -0700 (PDT)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8741200B1 for <dns-privacy@ietf.org>; Tue, 9 Jul 2019 15:29:06 -0700 (PDT)
Received: from [192.168.1.82] (71-15-24-35.dhcp.hlrg.nc.charter.com [71.15.24.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id BD8193448B; Tue, 9 Jul 2019 18:29:05 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Tom Pusateri <pusateri@bangj.com>
X-Mailer: iPad Mail (16F203)
In-Reply-To: <E2CC956E-C409-46CC-881A-0C9D900C6EFC@sinodun.com>
Date: Tue, 09 Jul 2019 18:29:04 -0400
Cc: dns-privacy@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <067DCFB0-2549-4C0F-BE84-CEE85D32F5A8@bangj.com>
References: <156260792242.808.508025353392512987.idtracker@ietfa.amsl.com> <E2CC956E-C409-46CC-881A-0C9D900C6EFC@sinodun.com>
To: Sara Dickinson <sara@sinodun.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/2W79qvnPCYxI3KIRqLkPO73JHHo>
Subject: Re: [dns-privacy] New Version Notification for draft-zatda-dprive-xfr-using-dso-00.txt
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: Tue, 09 Jul 2019 22:29:10 -0000

This is a great use of DSO and pub/sub. I support this work and I like the new acronym XuD in the spirit of DoT and DoH, etc.

Some minor comments:

In the Abstract is NOTITY/SOA instead of NOTIFY/SOA.

In the Terminology section, XuD is defined using DOS instead of DSO.

In the Overview, you mention clients should only subscribe for zones they are authorised to transfer. This needs a little more context. Who authorises a client? How does a client know it is authorised?

In 7.1, in a note, you mention TSIG can be used by the client to demonstrate that it is authorised so maybe this is what is meant earlier in the overview but it should be more explicit but also, it would be neat if SIG(0) certificate verification could be used for authorisation as well to obviate the need for out of band secret exchange.

In 7.1.1.1, there is mention of efficiently packing stream data into TCP segments. This is also in the PUSH draft but I think it should be removed from there and from here as well because once the data is encoded in a TLS session, it’s much more difficult for the sender to have control over the size of TCP segments sent.

In 7.3.1, you ask the question if the equivalent of a RECONFIRM message is needed. The answer is no. This is specific to the way service discovery currently works and it is not applicable in the XFR case.

Thanks,
Tom

> On Jul 9, 2019, at 5:03 AM, Sara Dickinson <sara@sinodun.com> wrote:
> 
> Hi All, 
> 
> A new draft has been submitted that outlines the basics of a DSO based mechanism for zone transfers requiring TLS. 
> 
> There is much more work to do on the details and potentially additional messaging to define but hopefully this includes information to get some initial feedback on this proposal.
> 
> Best regards
> 
> Sara. 
> 
>> On 8 Jul 2019, at 18:45, internet-drafts@ietf.org wrote:
>> 
>> 
>> A new version of I-D, draft-zatda-dprive-xfr-using-dso-00.txt
>> has been successfully submitted by Sara Dickinson and posted to the
>> IETF repository.
>> 
>> Name:        draft-zatda-dprive-xfr-using-dso
>> Revision:    00
>> Title:        DNS Zone Transfer using DNS Stateful Operations
>> Document date:    2019-07-08
>> Group:        Individual Submission
>> Pages:        21
>> URL:            https://www.ietf.org/internet-drafts/draft-zatda-dprive-xfr-using-dso-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-zatda-dprive-xfr-using-dso/
>> Htmlized:       https://tools.ietf.org/html/draft-zatda-dprive-xfr-using-dso-00
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-zatda-dprive-xfr-using-dso
>> 
>> 
>> Abstract:
>>  DNS zone transfers are transmitted in clear text, which gives
>>  attackers the opportunity to collect the content of a zone by
>>  eavesdropping on network connections.  This document specifies use of
>>  DNS Stateful Operations to enable a subscribe/publish mechanism for
>>  zone transfers reducing the over head introduced by NOTITY/SOA
>>  interactions prior to zone transfer request.  This additionally
>>  prevents zone contents collection via passive monitoring of zone
>>  transfers by restricting XFR using DSO to require TLS.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
> 
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy