Re: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19

Tom Pusateri <pusateri@bangj.com> Sat, 15 June 2019 17:34 UTC

Return-Path: <pusateri@bangj.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95611200B3; Sat, 15 Jun 2019 10:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CK_HELO_DYNAMIC_SPLIT_IP=0.001, CK_HELO_GENERIC=0.249, HELO_MISC_IP=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001] autolearn=no 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 WYAew6WLjhWL; Sat, 15 Jun 2019 10:34:40 -0700 (PDT)
Received: from 69-77-154-174.static.skybest.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 53571120075; Sat, 15 Jun 2019 10:34:40 -0700 (PDT)
Received: from [172.20.3.36] (66-50-27-132.prtc.net [66.50.27.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by 69-77-154-174.static.skybest.com (Postfix) with ESMTPSA id 191DA32415; Sat, 15 Jun 2019 13:34:39 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3554.18.2\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <E05EE006-BDFC-4EA9-993C-36ECC5A349F2@fugue.com>
Date: Sat, 15 Jun 2019 13:34:38 -0400
Cc: Liang Xia <frank.xialiang@huawei.com>, draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF <ietf@ietf.org>, secdir@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BEC890CD-FA7E-4734-A441-682D6C7BECB9@bangj.com>
References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> <E05EE006-BDFC-4EA9-993C-36ECC5A349F2@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3554.18.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/GhwhbRHcaT1P0jm38aP5ftr0FtM>
Subject: Re: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Jun 2019 17:34:42 -0000

I agree with your comments and think my additional text (in combination with what was already there) is also in the spirit of your comments and does not conflict. Are you suggesting there is a conflict?

Thanks,
Tom

> On Jun 15, 2019, at 1:21 PM, Ted Lemon <mellon@fugue.com> wrote:
> 
> The primary motivation for using tls is opportunistic security. Authentication would be interesting to add. SNI encryption would be interesting but I think is a separate topic. 
> 
> Client authorization might be useful in some cases, but generally is not done in DNS servers. To address these would require a security analysis of much broader scope than is appropriate for this document. We’ve talked about this in the context of homenet. 
> 
> Sent from my iPhone
> 
>> On Jun 15, 2019, at 12:47 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>> 
>> Does this address your concerns?
>> 
>>> On May 17, 2019, at 11:59 AM, Tom Pusateri <pusateri@bangj.com> wrote:
>>> 
>>> Will also address TLS comments.
>>> 
>>>> 3. In the section of Security Considerations:
>>>> 1) you should also mention that TLS provides the anti-replay protection
>>>> service for DNS Push;
>> 
>> I have added a 4th security service in the Security section:
>> 
>> Anti-replay protection:  TLS provides for the detection of and
>>     prevention against messages sent previously over a TLS connection
>>     (such as DNS Push Notifications).  Prior messages cannot be re-
>>     sent at a later time as a form of a man-in-the-middle attack.
>> 
>>>> 2) maybe you need to consider the client
>>>> authentication to achieve policy control and detect illegal client;
>> 
>> I have added a new paragraph in the Security section:
>> 
>> As a consequence of requiring TLS, client certificate authentication
>>  and verification may also be enforced by the server for stronger
>>  client-server security or end-to-end security.  However,
>>  recommendations for security in particular deployment scenarios are
>>  outside the scope of this document.
>> 
>>>> 3) TLS
>>>> WG are specifying the SNI encryption mechanism, will it influence your TLS
>>>> name authentication?
>> 
>> SNI encryption has no effect on our use of TLS name authentication.
>> 
>> Thanks,
>> Tom
>> 
>> 
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd