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

Ted Lemon <mellon@fugue.com> Sat, 15 June 2019 17:43 UTC

Return-Path: <mellon@fugue.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 D83A91200D6 for <dnssd@ietfa.amsl.com>; Sat, 15 Jun 2019 10:43:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 jIbeA68kf_qY for <dnssd@ietfa.amsl.com>; Sat, 15 Jun 2019 10:43:23 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 EAD2B12008B for <dnssd@ietf.org>; Sat, 15 Jun 2019 10:43:22 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id s22so3752858qkj.12 for <dnssd@ietf.org>; Sat, 15 Jun 2019 10:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L6JkDM0c7cg50KHUlIW4+W16hKht+6/B0J+vQbTEtuE=; b=dfnJa9AQchq4U9iZfyZ0DTKJjEola7ve+M6XMzsuqYmmC4BzOvZCdKxJIsw0SYQXzF ksUeHqYjD/ZhuFbxBOaMr0c6gS87alfiTRxauazhqhnYyiDSfDxI+DfV3U1JvXryYO2u o/R+x5qGqTl7psayYRgGZu+yBTlvIJB0OYf6XOX75n+9jxFd9gMjeXXIK5SS/NDiCjCx JgEJYsufJ0Fu5INC0pixgf1OwzAgIobWCB8MQipholYNhbvTCtD7z5V4S8ItEJe+90Ql 8/mlRbRp7iXwSSZXFW6N489KjyOfk2mfLJ3bY0AsnV4R8H0gqOaUvitMIne+de9xEUhq F0KQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L6JkDM0c7cg50KHUlIW4+W16hKht+6/B0J+vQbTEtuE=; b=FT/tkQ13nHOymj+YiaucVOhINpagVFucjzK98GEEyoPw3lGfoi/oj3AJ8LdYag5tI5 BuKgoQWCRbBRhcf1HrLKqEribZ7c5iqYkyE4CarP7L/suDjG973ewj4JdMxebVeonMuG wdiLN+SdLMCXhx0H486hFRB8vJ9Ws05KYrU+EkGZurdtQFsC0NwCH1BCUVOMDkeiFT5S bstOsc/hGauiO953Vq/Uf0JWeETOvAbt73vjRM0NpCmkCss4R+sE42OjXyX6KqHeFOia NMCWPWZr/duTTAi4QoZb/AAHUEbA5DItvwhL2/xwzEY85KiS+9oFdkYMM8qs9icxqREW 1Ddw==
X-Gm-Message-State: APjAAAWTI52/0kwEYiE/YKC7t/hM8ts4G9fFU4tGTRqiSUCztMZrwKTu 6WOVAm9K1GKBStz6qVOVP8LB1A==
X-Google-Smtp-Source: APXvYqxduMz/F4VLBvCq/u8InKOsH++SzrIXasMbWzAYZHKqluiJ/Q5CviuyBsxyY6z7rDIGQCKxIg==
X-Received: by 2002:a05:620a:124c:: with SMTP id a12mr82150473qkl.336.1560620601971; Sat, 15 Jun 2019 10:43:21 -0700 (PDT)
Received: from [10.0.30.11] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id k7sm2766294qth.88.2019.06.15.10.43.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jun 2019 10:43:21 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Ted Lemon <mellon@fugue.com>
X-Mailer: iPhone Mail (16G48)
In-Reply-To: <BEC890CD-FA7E-4734-A441-682D6C7BECB9@bangj.com>
Date: Sat, 15 Jun 2019 13:43:20 -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: <B1BEAFAC-14BD-4850-A641-E965B421C70C@fugue.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> <BEC890CD-FA7E-4734-A441-682D6C7BECB9@bangj.com>
To: Tom Pusateri <pusateri@bangj.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/Thx4RlwjtGiZ9j673TbJbwLVLF8>
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:43:26 -0000

No, just chiming in. This was something I had to think about during the implementation, so it’s familiar territory. 

Sent from my iPhone

> On Jun 15, 2019, at 1:34 PM, Tom Pusateri <pusateri@bangj.com> wrote:
> 
> 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
>