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

Ted Lemon <mellon@fugue.com> Sat, 15 June 2019 17:21 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 7CF6B12002F for <secdir@ietfa.amsl.com>; Sat, 15 Jun 2019 10:21:13 -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 AyPc8BEJJO-3 for <secdir@ietfa.amsl.com>; Sat, 15 Jun 2019 10:21:12 -0700 (PDT)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 E576D1200B5 for <secdir@ietf.org>; Sat, 15 Jun 2019 10:21:09 -0700 (PDT)
Received: by mail-qt1-x82b.google.com with SMTP id y57so6261342qtk.4 for <secdir@ietf.org>; Sat, 15 Jun 2019 10:21:09 -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=4dCaNZw1sxGBf0ruUELsCrt5oPhqAbeY0QtJLIYR8xU=; b=YCZ3TuVl9kFipgEavgeyJHo+hc65/hMRcaK/2wbOTw+Cy12eWg/8BDx+py16uPP9AT QLrfSXhe0u2/e7869fDvgTaPcE1L95g8wVcYZJc+ehzVQnTvZ4nD10yVTy410KM37RGB hfNQelZPEM3BLimAPCXKjVgcDWUwCEPjLZYZJoGWWHHQeqfqJcYdRKIungKiEr6OR92V By8ZA0MExpSnb8DVQEK20CspZyGOUik6i5p0vAtc0TncPw7wO327yrenFXPGKg1JyFZF sRwwVimpZDFgkQ0U9i6+Bl2hPbN4tBhfTJrxFzEb5jiGYUATlNOHNbUYJkyt3g+j5B9n aMSA==
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=4dCaNZw1sxGBf0ruUELsCrt5oPhqAbeY0QtJLIYR8xU=; b=myyg6r2MBh73suLrdQrOt+O8fdqDpYTk1aKNXE7Bx+g7pZ1XKRIpWfTxuyuF7/Qoq3 tIQ9h46rtTkQnSIdHNuKuFOjKYeZfGdrTb1ytmtFa3C8BtnXDpuKXnOPAWTaoAb8gjEB i4xMEZ7/bHU71TXcF5POr+Wt6pFuxkuZFqCmJIAykb+rNhloNKpWMW3J6MFnR3tktOGR tLWVNmUyCdZDf8uW9kZOcwsjMvwuP+O+9uQmVyMZbGBC/NC3UY5SLa3OI9ajLJE15mrU nf60+RcwxFU/lYsFS6wII0oQASKHOquEtIxb7kQwQ0tIDyIPRE4CxNPHxTFS7o00/ytM 2lkg==
X-Gm-Message-State: APjAAAXVnEvfrPAx2mFQ1oR/dqODG7880WOMjgmW9NDtFrsLLAiPASXR ykI8sm0KxXcIQBbY9N0NxoUeo08fu70=
X-Google-Smtp-Source: APXvYqzj3s+iK/1/f2K5OAaHI0LK38owYcR4+0t3KF5zxcZgCS0H7XNziqK6Q8Oa2jSAjLL39BV6Xw==
X-Received: by 2002:ac8:2809:: with SMTP id 9mr89368109qtq.4.1560619268852; Sat, 15 Jun 2019 10:21:08 -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 y24sm1089873qty.96.2019.06.15.10.21.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jun 2019 10:21:08 -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: <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com>
Date: Sat, 15 Jun 2019 13:21:06 -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: <E05EE006-BDFC-4EA9-993C-36ECC5A349F2@fugue.com>
References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com>
To: Tom Pusateri <pusateri@bangj.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/kCo_CveqwG03UUQ1rDNr35r6Exc>
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:21:14 -0000

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