Re: [secdir] [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: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAF0120052 for <secdir@ietfa.amsl.com>; Sat, 15 Jun 2019 10:43:27 -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 0xhqGZpTcC0S for <secdir@ietfa.amsl.com>; Sat, 15 Jun 2019 10:43:25 -0700 (PDT)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 4E01D1200B9 for <secdir@ietf.org>; Sat, 15 Jun 2019 10:43:23 -0700 (PDT)
Received: by mail-qk1-x72b.google.com with SMTP id m14so3757926qka.10 for <secdir@ietf.org>; Sat, 15 Jun 2019 10:43:23 -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=fgM8yzTneruUmhU0YQ6FQrbZ1VsNLskp6tG0OcDuaSKIXOJGd2Z78hZrmZGD2/ixcF /kEjWwkAQqjMHlf9NBiVFV6lxGT3EDJDmAcAAu1rieEdQbYW8UN9WeXhDffqcadD0xp7 iGicqAv3EhxVDQVV3svlUl4gzGzBn4r3DsXsjMTKXyiPHFoBkon7jMQNo47VF+poBbT9 0oH9uYSVJsZTv2kbc5rcpTuDX2Y584/cOjRujjMVopCkAqihfNwX4uQbjWSzCwo9RqEm 7+3B/gepBWEnOCkHsQja3aw4aaJdIwcxqTjq02GrV4IhmnYNDJdmmmIBvTAgWL4V1479 DYNQ==
X-Gm-Message-State: APjAAAWFpyEjmNomBWZwGVck7ZEBtzvFLJPTTFJANRaZqkkd9L+UovZ6 Ei4XB08ZFG7zggO2WVCkG/q7Ifp6cbY=
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/secdir/mNNejYDWz9prckwbbJxVexJcmII>
Subject: Re: [secdir] [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Jun 2019 17:43:28 -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
>