From nobody Tue Jul 2 11:36:38 2019 Return-Path: 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 DF0A41206F3; Tue, 2 Jul 2019 11:36:20 -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 InnAP-bBJQI5; Tue, 2 Jul 2019 11:36:18 -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 20B9012010F; Tue, 2 Jul 2019 11:36:18 -0700 (PDT) Received: from [192.168.77.104] (199-255-11-3.static.celitofiber.net [199.255.11.3]) (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 B463333AC2; Tue, 2 Jul 2019 14:36:16 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3560.7\)) From: Tom Pusateri In-Reply-To: <156175221593.21875.9525138908968318905@ietfa.amsl.com> Date: Tue, 2 Jul 2019 14:36:16 -0400 Cc: gen-art@ietf.org, draft-ietf-dnssd-push.all@ietf.org, DNSSD , IETF Content-Transfer-Encoding: quoted-printable Message-Id: <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3560.7) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 18:36:21 -0000 > On Jun 28, 2019, at 4:03 PM, Robert Sparks via Datatracker = wrote: >=20 > Reviewer: Robert Sparks > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-dnssd-push-20 > Reviewer: Robert Sparks > Review Date: 2019-06-28 > IETF LC End Date: 2019-07-05 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Ready for publication as a Proposed Standard but with an = Issue to > consider before publication, >=20 > Issue: >=20 > The discussion of recursive resolvers in section 6.1 may need = additional > consideration. In particular, the recommendation to pass a received = error code > along to a client has, I think, some unintended consequences for the = client. If > the recursive server receives a NOTIMP, for example, passing that to = the client > tells the client the wrong thing about the server it is connected to. = Perhaps > it would be better for the recursive server to return SERVFAIL in this > circumstance? (Similar to what it would do if it couldn't connect to = the next > server as described at the bottom of page 10). Let me think about this some more before I respond. >=20 > Nits: >=20 > Page 5, Section 3, 3rd paragraph, last sentence: NOT REQUIRED is not a > 2119/8174 keyword. I suggest using lowercase 'not required' in this = sentence. Fixed. >=20 > Page 7, Section 4, 3rd paragraph: The first sentence alludes to = concerns about > anonymous subscriptions, saying TCP alleviates those concerns. As = written this > is pretty vague. Can you expand on what you mean by an anonymous = subscription > in this context? Now says: "Connection setup over TCP ensures return reachability and alleviates = concerns of state overload at the server which is a potential problem = with connection-less protocols using spoofed source addresses. All = subscribers are guaranteed to be reachable by the server by virtue of = the TCP three-way handshake.=E2=80=9D >=20 > Page 10, Section 6.1, first sentence: Suggest s/first step in DNS = Push/first > step in a DNS Push/ >=20 Fixed. > Page 15, last paragraph: Why MUST the server immediately terminate a = connection > in this situation? Just accepting the request seems safe - having = subscription > requests show up for the same name seems nearly idempotent, and only = one PUSH > would result from having multiple such subscriptions. Is this close an = attempt > to avoid resource denial attacks buy some node subscribing many times = to the > same thing? That feels extreme, especially since tearing down the = connection > would cancel other subscriptions the client already has established on = that > connection. The discussion about case insensitivity here is a side note. The main = point is that if you receive a subscription for something you already = have a subscription for, the two sides are out of sync. There is no = protocol mechanism built in to regain synchronization and the best way = is then to close the connection and try again. The most common reason = that the two ends are out of sync is likely software bugs and if this = keeps occurring, the administrator will begin to see a pattern of = connections closing and can report the problem. >=20 > Page 16, second paragraph: I suggest replacing the second sentence = with > something like "A name in a SUBSCRIBE message that matches only a = literal CNAME > in the zone will only receive notifications of changes to the CNAME = (assuming > the subscription asks for that type), and nothing else." >=20 The SUBSCRIBE contains the record type not just a name. The point is = that a subscription of a CNAME is only to the CNAME record and not to = the record it points to. How about: "Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message = matches only a literal CNAME record in the zone, and not to any records = referenced by the owner name." > Page 23, top of page: Since section 4 restricts this protocol to TLS = over TCP, > the "(or equivalent for other protocols)" phrase should be removed. Good catch. I removed all instances of "(or equivalent for other = protocols)=E2=80=9D Thanks! Tom From nobody Tue Jul 2 12:36:30 2019 Return-Path: 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 2ABEF1206F9; Tue, 2 Jul 2019 12:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Vv52KBjsgYTN; Tue, 2 Jul 2019 12:36:27 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 B608E120710; Tue, 2 Jul 2019 12:36:22 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id a21so18150716ljh.7; Tue, 02 Jul 2019 12:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sxIFgTiC1uZrBvAuogjtd1wNaSSkchUqKSvLZ3WSCoE=; b=JJrPvBeEjkzhq6iMnvhd5u2ZduqLMMoMoi5ROKmbyRNvfNIzl6IdWCOCCmWDDK0w3o vAMYb8uJe1bJbA57zufluS9bzJf9wqpLri6znOujO8A3SyxfR7ZEam77Xt33a4ynMn3c mxjFBOgWQDzyIPcUkIwPEa/cHP5WVGCqr0sKFdYEkLirtE9qm6CHC1TNDjrQNH7mWJV+ 73+TkoLnL7nxGGc7tQfXaZmJSQiTP4IE1Yn/lDOiAZgZdvypUEfjalQE75aDlDRe2mcZ cjy8coibzMGsXqlI962S+IzCVKvXvpAM9fSLEremccARSG8vFa86OlX5kEQM2mhS+ipe nQUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sxIFgTiC1uZrBvAuogjtd1wNaSSkchUqKSvLZ3WSCoE=; b=BX5bxzQYfhq4qxn0QK2SRRvkpd98tBykG2QE86LQWffaVgaYVD/FbgvgoHSW/COavQ 1EqRo3LKkmKuZu9ETFuUqaoPnQWnNGmhkJ0vUkGdTBJmBmHhckF4X+KzH1AiKDHup9jn kv0NLIziU8sTJ61iQxKC/59KUPKXwgzRm7AhaXBu2qYAAnk/iJ/stTTZ9jdoX8bkBchh gNOiVKiw7xV0R1RPEr6RfwZXumYoqbNmnkD1o/QjShycXfSWKifoBJY8qdUj4GFf+K9o nqJUIpX6NSJYOoW92HhGIW9VoNmZLsgjUqES1p5uvzGVws3O3fLyqjihW7Szc/hr4pF6 9TYA== X-Gm-Message-State: APjAAAVmQY9p/n+JMjA6DJys4bAe1khWo0OEsqS4P74iClfKnE10COrQ yz5wBCd4U48UJfF12JceA0CcIgI00vZ3p72VWFqajg== X-Google-Smtp-Source: APXvYqz5NtHM8YhJFmTITgazXN2dHLtC0MFELQ9hcEJWHYvpWU9+kiRNKDBw9WmruoxqJSac8YsVnlPXR2D1m2vvGyE= X-Received: by 2002:a2e:2d12:: with SMTP id t18mr6498066ljt.175.1562096180840; Tue, 02 Jul 2019 12:36:20 -0700 (PDT) MIME-Version: 1.0 References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> In-Reply-To: <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> From: David Schinazi Date: Tue, 2 Jul 2019 12:36:09 -0700 Message-ID: To: Tom Pusateri Cc: Robert Sparks , draft-ietf-dnssd-push.all@ietf.org, DNSSD Content-Type: multipart/alternative; boundary="000000000000f6ce01058cb7db55" Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 19:36:29 -0000 --000000000000f6ce01058cb7db55 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, If the protocol is restricted to TLS over TCP, it should send a TLS close_notify, not a TCP RST. TLS close_notify is cryptographically guaranteed to originate from the peer= , whereas TCP RST can be injected by an on-path entity to cause truncation attacks. Thanks, David > Page 23, top of page: Since section 4 restricts this protocol to TLS over > TCP, > > the "(or equivalent for other protocols)" phrase should be removed. > > Good catch. I removed all instances of "(or equivalent for other > protocols)=E2=80=9D > --000000000000f6ce01058cb7db55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

If the protocol is r= estricted to TLS over TCP, it should send a TLS close_notify, not a TCP RST= .
TLS close_notify is cryptographically guaranteed to originate f= rom the peer,
whereas TCP RST can be injected by an on-path entit= y to cause truncation attacks.

Thanks,
D= avid


> Page 23, top of page: Since section 4 restricts this protocol to TLS o= ver TCP,
> the "(or equivalent for other protocols)" phrase should be r= emoved.

Good catch. I removed all instances of "(or equivalent for other proto= cols)=E2=80=9D
--000000000000f6ce01058cb7db55-- From nobody Tue Jul 2 12:42:24 2019 Return-Path: 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 C258C12076B; Tue, 2 Jul 2019 12:42:16 -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, HTML_MESSAGE=0.001, SPF_PASS=-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 KVaiNEu25vNe; Tue, 2 Jul 2019 12:42:14 -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 C51F4120738; Tue, 2 Jul 2019 12:42:14 -0700 (PDT) Received: from [172.16.10.104] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (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 C7EE333ADE; Tue, 2 Jul 2019 15:42:13 -0400 (EDT) From: Tom Pusateri Message-Id: <886A4A9E-E986-477B-9681-2740E20EBAA2@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A415CF69-52F4-45F1-B5EE-262AF91680EB" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3560.7\)) Date: Tue, 2 Jul 2019 15:42:12 -0400 In-Reply-To: Cc: Robert Sparks , draft-ietf-dnssd-push.all@ietf.org, DNSSD To: David Schinazi References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> X-Mailer: Apple Mail (2.3560.7) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 19:42:23 -0000 --Apple-Mail=_A415CF69-52F4-45F1-B5EE-262AF91680EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks David. The only other transport I could see being relevant in the future is = QUIC. But there are lots of unknowns about DNS over QUIC at present so I = think we can safely assume that would require a new PUSH draft to = specify the behavior. So I think your suggestion is a good one. Tom > On Jul 2, 2019, at 3:36 PM, David Schinazi = wrote: >=20 > Hi Tom, >=20 > If the protocol is restricted to TLS over TCP, it should send a TLS = close_notify, not a TCP RST. > TLS close_notify is cryptographically guaranteed to originate from the = peer, > whereas TCP RST can be injected by an on-path entity to cause = truncation attacks. >=20 > Thanks, > David >=20 >=20 > > Page 23, top of page: Since section 4 restricts this protocol to TLS = over TCP, > > the "(or equivalent for other protocols)" phrase should be removed. >=20 > Good catch. I removed all instances of "(or equivalent for other = protocols)=E2=80=9D --Apple-Mail=_A415CF69-52F4-45F1-B5EE-262AF91680EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks David.

The only other transport I could see being relevant in the = future is QUIC. But there are lots of unknowns about DNS over QUIC at = present so I think we can safely assume that would require a new PUSH = draft to specify the behavior.

So I think your suggestion is a good = one.

Tom


On Jul 2, 2019, at 3:36 PM, David Schinazi <dschinazi.ietf@gmail.com> wrote:

Hi Tom,

If the protocol is restricted to TLS = over TCP, it should send a TLS close_notify, not a TCP RST.
TLS close_notify is cryptographically guaranteed to originate = from the peer,
whereas TCP RST can be injected by = an on-path entity to cause truncation attacks.

Thanks,
David


> Page 23, top of page: Since section 4 restricts this protocol to = TLS over TCP,
> the "(or equivalent for other protocols)" phrase should be = removed.

Good catch. I removed all instances of "(or equivalent for other = protocols)=E2=80=9D

= --Apple-Mail=_A415CF69-52F4-45F1-B5EE-262AF91680EB-- From nobody Tue Jul 2 12:56:05 2019 Return-Path: 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 46F9812016D; Tue, 2 Jul 2019 12:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 15qvtLIyxKYW; Tue, 2 Jul 2019 12:55:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 E05301206FA; Tue, 2 Jul 2019 12:55:45 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x62JtgQj025349 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Jul 2019 14:55:43 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562097343; bh=UU/e57U940VeQB2Ya23iUSzWAN2aFJb2HYhJ2bagxRA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=XZrQPF63dPXPPRugsBUp5jnguVqw4BD5CBG5Ak0s7NjMSztCIj3Ao6ks+g1P3xFGy WmQwuSpkn1TrRT7tvQS1SG89irDq+9Pl94icKzKZw1Z9ZxZIoL3EDbBb6M9Hj22yNx 1J6ET/42YUUA40zPAHkQ4iSFUSd5nyC1yf8KPvv0= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Tom Pusateri Cc: gen-art@ietf.org, draft-ietf-dnssd-push.all@ietf.org, DNSSD , IETF References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> From: Robert Sparks Message-ID: Date: Tue, 2 Jul 2019 14:55:42 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 19:55:49 -0000 inline On 7/2/19 1:36 PM, Tom Pusateri wrote: > >> On Jun 28, 2019, at 4:03 PM, Robert Sparks via Datatracker wrote: >> >> Reviewer: Robert Sparks >> Review result: Ready with Issues >> >> I am the assigned Gen-ART reviewer for this draft. The General Area >> Review Team (Gen-ART) reviews all IETF documents being processed >> by the IESG for the IETF Chair. Please treat these comments just >> like any other last call comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-dnssd-push-20 >> Reviewer: Robert Sparks >> Review Date: 2019-06-28 >> IETF LC End Date: 2019-07-05 >> IESG Telechat date: Not scheduled for a telechat >> >> Summary: Ready for publication as a Proposed Standard but with an Issue to >> consider before publication, >> >> Issue: >> >> The discussion of recursive resolvers in section 6.1 may need additional >> consideration. In particular, the recommendation to pass a received error code >> along to a client has, I think, some unintended consequences for the client. If >> the recursive server receives a NOTIMP, for example, passing that to the client >> tells the client the wrong thing about the server it is connected to. Perhaps >> it would be better for the recursive server to return SERVFAIL in this >> circumstance? (Similar to what it would do if it couldn't connect to the next >> server as described at the bottom of page 10). > Let me think about this some more before I respond. > >> Nits: >> >> Page 5, Section 3, 3rd paragraph, last sentence: NOT REQUIRED is not a >> 2119/8174 keyword. I suggest using lowercase 'not required' in this sentence. > Fixed. > >> Page 7, Section 4, 3rd paragraph: The first sentence alludes to concerns about >> anonymous subscriptions, saying TCP alleviates those concerns. As written this >> is pretty vague. Can you expand on what you mean by an anonymous subscription >> in this context? > Now says: > > "Connection setup over TCP ensures return reachability and alleviates concerns of state overload at the server which is a potential problem with connection-less protocols using spoofed source addresses. All subscribers are guaranteed to be reachable by the server by virtue of the TCP three-way handshake.” wfm > >> Page 10, Section 6.1, first sentence: Suggest s/first step in DNS Push/first >> step in a DNS Push/ >> > Fixed. > >> Page 15, last paragraph: Why MUST the server immediately terminate a connection >> in this situation? Just accepting the request seems safe - having subscription >> requests show up for the same name seems nearly idempotent, and only one PUSH >> would result from having multiple such subscriptions. Is this close an attempt >> to avoid resource denial attacks buy some node subscribing many times to the >> same thing? That feels extreme, especially since tearing down the connection >> would cancel other subscriptions the client already has established on that >> connection. > The discussion about case insensitivity here is a side note. The main point is that if you receive a subscription for something you already have a subscription for, the two sides are out of sync. There is no protocol mechanism built in to regain synchronization and the best way is then to close the connection and try again. The most common reason that the two ends are out of sync is likely software bugs and if this keeps occurring, the administrator will begin to see a pattern of connections closing and can report the problem. At a high level, we're talking about what to do when something violates protocol. I'm not going to argue for a change, but I find issuing an error when asked to make things like X when they are already like X suspect. The idea that you can treat this as a symptom of being out of sync and that a reset would fix it would be more compelling if you weren't basing this on TLS over TCP - I can only see it being a problem that must recur and you're choosing to have it be noisy and thrashy to expose the problem. I guess that's ok, though I worry about the intended deployment environments not really having an administrator to notice there's a problem. > >> Page 16, second paragraph: I suggest replacing the second sentence with >> something like "A name in a SUBSCRIBE message that matches only a literal CNAME >> in the zone will only receive notifications of changes to the CNAME (assuming >> the subscription asks for that type), and nothing else." >> > The SUBSCRIBE contains the record type not just a name. The point is that a subscription of a CNAME is only to the CNAME record and not to the record it points to. How about: > > "Aliasing is not supported. That is, a CNAME in a SUBSCRIBE message matches only a literal CNAME record in the zone, and not to any records referenced by the owner name." Sure > >> Page 23, top of page: Since section 4 restricts this protocol to TLS over TCP, >> the "(or equivalent for other protocols)" phrase should be removed. > Good catch. I removed all instances of "(or equivalent for other protocols)” > > Thanks! > > Tom > > From nobody Tue Jul 2 14:24:30 2019 Return-Path: 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 7FF2A1200E0; Tue, 2 Jul 2019 14:24:14 -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 hUcVFRiwQE7b; Tue, 2 Jul 2019 14:24:12 -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 60C321200D6; Tue, 2 Jul 2019 14:24:12 -0700 (PDT) Received: from [172.16.10.104] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (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 72C5533B02; Tue, 2 Jul 2019 17:24:11 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3560.7\)) From: Tom Pusateri In-Reply-To: <156175221593.21875.9525138908968318905@ietfa.amsl.com> Date: Tue, 2 Jul 2019 17:24:10 -0400 Cc: gen-art@ietf.org, draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF Content-Transfer-Encoding: quoted-printable Message-Id: <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> To: Robert Sparks X-Mailer: Apple Mail (2.3560.7) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 21:24:15 -0000 > On Jun 28, 2019, at 4:03 PM, Robert Sparks via Datatracker = wrote: >=20 > Issue: >=20 > The discussion of recursive resolvers in section 6.1 may need = additional > consideration. In particular, the recommendation to pass a received = error code > along to a client has, I think, some unintended consequences for the = client. If > the recursive server receives a NOTIMP, for example, passing that to = the client > tells the client the wrong thing about the server it is connected to. = Perhaps > it would be better for the recursive server to return SERVFAIL in this > circumstance? (Similar to what it would do if it couldn't connect to = the next > server as described at the bottom of page 10). The only time NOTIMP is returned is in the case where DSO stateful = operations (over which DNS PUSH runs) is not supported. This error code = is due to the fact that DSO uses a different Opcode than the standard = Query/Response Opcode. DSO defines a new opcode. The effect of this is = that NOTIMP is the correct response if a server doesn=E2=80=99t support = the new Opcode. Similarly, if DSO is supported but DNS Push TLV type is not supported, = we return a new RCODE for DSO type not implemented DSOTYPENI. These are both required by existing specifications. If a client begins the connection with a DSO Keepalive to a resolver and = the resolver accepts the connection, subsequent SUBSCRIBE operations = that return NOTIMP will be obvious that the authoritative server does = not support DSO. However, if the client begins with a SUBSCRIBE and receives NOTIMP from = the resolver, it=E2=80=99s not clear if the NOTIMP was originated by the = resolver or the authoritative server. Right now, we allow either DSO TLV to setup the state. In the case that = the client begins with a SUBSCRIBE and the resolver returns NOTIMP, the = client should attempt a connection with the authoritative server = directly as described in 6.1. If the authoritative server returns = NOTIMP, then PUSH notifications are not possible. While we could be more explicit about every error case, I don=E2=80=99t = think the document says anything wrong here. Thanks, Tom From nobody Tue Jul 2 17:07:20 2019 Return-Path: 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 55C171200E7; Tue, 2 Jul 2019 17:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pU_KbCmcW9s0; Tue, 2 Jul 2019 17:07:17 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 6F566120044; Tue, 2 Jul 2019 17:07:17 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id i21so424168ljj.3; Tue, 02 Jul 2019 17:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=X/9fCXWNQ7O4crkBdz0stSvQv4p41JcFYTv09wKKSOU=; b=V2m6dpji8k0bb6me46R8xE1aUSDSlEHUhGVzxF2UbnJPvHvrquiECZHSj36DyMmXUo 2Aus6g4RInQeFew18uvBGo+bcjDOw1AwY8CCypn02KFBSn1YjPxnJwsDZcdow2ScPrXt NxXkFl/0zFEcr771PkUoNjfFF14S7u3QUOq7I5enZo1tEW+VwR0QWhrKPoF7BV6exrYZ mTOeFZ2y/9KfuDIDQNUvhWDbTL0PX/X6wAigOKvvdftwj9vGgO2XJ5gtiGJVcb3FMaQl OJWpRlWsuPlgeN3erqm/DEf8yuDbeG9DoECkA4xK3iExS2R0gR69jtT1Q6MURIT7Jk05 LjNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=X/9fCXWNQ7O4crkBdz0stSvQv4p41JcFYTv09wKKSOU=; b=WGk5cWdDPoQiU5lc50LH4IUpbEd86xfcVFoiaP+iKd3b6Xkk1SKe4i+d4gBITrEZaP DDmuTbToV4Ft7xElZc2mNA/jfTNN0Vtn3ItMaee1KHLd8RQjjjxEq/PWx3Zi+fp6EK8M nnAP/9RNfypdUqlhaOnRcR3pTeCHHmncuv1948Ipx/0b+XYNz9+FX4jStjMlSjNMMBnn c+V8nv5yKEdyjptqADRuYcBo6ExZdKe6cMnNyRkS/Oi4FxYKmz6BOstjzHub0MdtqL4E f3P01OzsNlUIra+dJjIc+ZkdHRWJOJhklHZNNAc/voUPke3m1sse0KqGd9wpkzMxw5PO LSQg== X-Gm-Message-State: APjAAAVcGCju9U6dIbkPrTrBlwJV2H5XTOP8BlgOPfLNBIYKoR5hHiaW ZweJTRFL9uL1v0VR6sfhnr2L6wZXPilemITpw/8NOn1T X-Google-Smtp-Source: APXvYqwXFFNjh+RFC8kZQ9BQ6DVV3pBVHaHXAl+R01IwAi9htO7k6bpfXi7NmvJsAXfCYqMOSgl7JSh7ifP53UouXS0= X-Received: by 2002:a2e:2d12:: with SMTP id t18mr7077599ljt.175.1562112435391; Tue, 02 Jul 2019 17:07:15 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Tue, 2 Jul 2019 17:07:04 -0700 Message-ID: To: DNSSD Cc: dnssd-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000cf8ee9058cbba4d1" Archived-At: Subject: [dnssd] Call for agenda items: DNSSD at IETF 105 in Montreal 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 00:07:20 -0000 --000000000000cf8ee9058cbba4d1 Content-Type: text/plain; charset="UTF-8" Hello everyone, DNSSD has been scheduled on Thursday, 2019-07-25 at 13:30-15:30 EDT. If you would like to present, please reply to this thread, or email with: - title of presentation - related draft(s) if applicable - expected duration - name of presenter Please also let us know if you will be presenting remotely or have any specific requests or questions. Kindly note that your agenda request must be received before next Tuesday 2019-07-09 at 23:59 UTC so the chairs have sufficient time to upload the agenda before the datatracker deadline. Thanks, David & Barbara --000000000000cf8ee9058cbba4d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

DNSSD has been schedule= d on=C2=A0Thursday, 2019-07-25 at=C2=A013:30-15:30 EDT.

If you would like to present, please reply to this thread,
= or email <dnssd-chairs@ietf.org= > with:
- title of presentation
- related draft(= s) if applicable
- expected duration
- name of presente= r
Please also let us know if you will be presenting remotely
or have any specific requests or questions.

= Kindly note that your agenda request must be received before
next= Tuesday 2019-07-09 at 23:59 UTC so the chairs have
sufficient ti= me to upload the agenda before the datatracker deadline.

Thanks,
David & Barbara
--000000000000cf8ee9058cbba4d1-- From nobody Wed Jul 3 07:46:06 2019 Return-Path: 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 51D941202E1; Wed, 3 Jul 2019 07:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 2eQbsDOxrewZ; Wed, 3 Jul 2019 07:45:49 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 B260A1202E0; Wed, 3 Jul 2019 07:45:36 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x63EjXIx002170 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 3 Jul 2019 09:45:33 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562165134; bh=PVz9jStHdbwIBJX3nOPjU7Q6wHQQJLJP4x4bRHscPz4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=bkwVllZgO1ielA9biHplkOBU/BYmrtbVu/+LKEU/HjuEbXb4ofWaNgFigUxDnGsu8 UBIs+Eoqd1Sm8FlKGHI4z5sbeCvf2+zRqJjlXwh2kET1KyQWR147esHnGsLYrXfq/P vwlpJ7qgfPFupjsFBpl2rshiIMqrC9uMktrxAxFo= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Tom Pusateri Cc: gen-art@ietf.org, draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> From: Robert Sparks Message-ID: Date: Wed, 3 Jul 2019 09:45:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 14:45:52 -0000 On 7/2/19 4:24 PM, Tom Pusateri wrote: > >> On Jun 28, 2019, at 4:03 PM, Robert Sparks via Datatracker wrote: >> >> Issue: >> >> The discussion of recursive resolvers in section 6.1 may need additional >> consideration. In particular, the recommendation to pass a received error code >> along to a client has, I think, some unintended consequences for the client. If >> the recursive server receives a NOTIMP, for example, passing that to the client >> tells the client the wrong thing about the server it is connected to. Perhaps >> it would be better for the recursive server to return SERVFAIL in this >> circumstance? (Similar to what it would do if it couldn't connect to the next >> server as described at the bottom of page 10). > > The only time NOTIMP is returned is in the case where DSO stateful operations (over which DNS PUSH runs) is not supported. This error code is due to the fact that DSO uses a different Opcode than the standard Query/Response Opcode. DSO defines a new opcode. The effect of this is that NOTIMP is the correct response if a server doesn’t support the new Opcode. > > Similarly, if DSO is supported but DNS Push TLV type is not supported, we return a new RCODE for DSO type not implemented DSOTYPENI. > > These are both required by existing specifications. > > If a client begins the connection with a DSO Keepalive to a resolver and the resolver accepts the connection, subsequent SUBSCRIBE operations that return NOTIMP will be obvious that the authoritative server does not support DSO. > > However, if the client begins with a SUBSCRIBE and receives NOTIMP from the resolver, it’s not clear if the NOTIMP was originated by the resolver or the authoritative server. And I think that's a problem. What does a NOTIMP mean to the client? Most of the draft says "The server doesn't implement DSO". It doesn't say "doesn't implement DSO for this particular set of bits in this query". Section 6.2.2 says the client should assume a retry delay of 1 hour before talking to the server (the resolver) again. Now, other parts of the document imply "for this particular set of bits" - in the overview, near the bottom of page 5, it says to use NOTIMP (actually it says NOTIMPL, maybe those are different things and I'm confused?) if a message is received for a class other than "IN" and the server has only implemented push for "IN". Again, that "assume a retry delay" kicks in. > > Right now, we allow either DSO TLV to setup the state. In the case that the client begins with a SUBSCRIBE and the resolver returns NOTIMP, the client should attempt a connection with the authoritative server directly as described in 6.1. If the authoritative server returns NOTIMP, then PUSH notifications are not possible. But there's fate sharing, at least as I'm reading the document now. That resolver could have been authoritative (or could reach an authoritative server) for some other subscription. But you've told the client that it's not ok to talk to this resolver for any subscription (for an hour at least). > > While we could be more explicit about every error case, I don’t think the document says anything wrong here. And I used NOTIMP as an example. I think there may be fate sharing issues with other response codes as well. > > Thanks, > Tom > > > From nobody Wed Jul 3 08:12:39 2019 Return-Path: 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 788201204D1 for ; Wed, 3 Jul 2019 08:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 B0GkaCfz7aYI for ; Wed, 3 Jul 2019 08:12:19 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 182DA1204AC for ; Wed, 3 Jul 2019 08:12:16 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id i34so1566932qta.6 for ; Wed, 03 Jul 2019 08:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Lk6/Wzdy4cLroMht7AgIFVLm/NLGbevekn6ilCqoRRU=; b=WNVvu5L2lsxrgjHJ85U+OR3e+eyvQLIg7Jmpxwg/iyNrX9/vK9w7n25hm/9x9theyz 2yPjYFn8fK7wqRehfapzVBU/83uAz8bQrrXrqfRmIBGsA7Asts9WreegreXwpdEhZHzL GpAugPtxjP2Sqi076jPUkg5MNZzO+B+zqIESH+AF+ifFQ7KZ9raSjFM6VYozGdwR+icf Dbze1RAOCbpsnZxbWZswQLEsOPXQYrBk4fP6zWErFMwYA5c0efbzwLqDaUZFLQDg641a zcFRXipR66FFOMoH7gk3b8laIA4Rk+4D/brI6iVcy8bI+lHJ840hEXJ4gtLSKXRBg0rT w/6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Lk6/Wzdy4cLroMht7AgIFVLm/NLGbevekn6ilCqoRRU=; b=d6xmj/kXH1kecYr4wD2BbP63yc0SzEuZrG/ZIKFx66tu1yuse3zjt694IK7vhdQs87 6KSbDFZkX9e1n0CsQoJG1krIAvxXRG+1dpogHuCgxU1++9HJrA4aYkUpUH/NNQOJsC2/ 93Lre6Y6HdidfqnzzdWhjg9CQBQ4t7LVoX8N/2d5Mcz7TWzj2KbH2HrwiRCVIF47Nibg Q5BUH7EksgPk3XtHbCe5sSZscZ2J/Za8rux0cngHGl/ANVdfgsGWKbC0Vyh9zg/15M9x G1ApttH3JFoE7XKjJo4tGjvKBuyH1NX2spU32YYu3hAr6QQSxsql5DqRLI4qSs3i6Ryo 9u6w== X-Gm-Message-State: APjAAAWufklNOn3nGhSBhsYmzwFgAtNQhBlMjrignL0S2w4bU66OBzwk J2Ugsqga+DesFhHnSXLqfVc1rQ== X-Google-Smtp-Source: APXvYqwC8xhM70Hfd0I+Lus3jryX0zXisJk4kwLWGac2ONFa3X8TxAOuQylgPelc7JtNz6nk0pzCdA== X-Received: by 2002:ac8:234a:: with SMTP id b10mr31626756qtb.261.1562166735003; Wed, 03 Jul 2019 08:12:15 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:a062:1585:ff05:9bdc? ([2001:470:c1a2:1:a062:1585:ff05:9bdc]) by smtp.gmail.com with ESMTPSA id u4sm1036838qkb.16.2019.07.03.08.12.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2019 08:12:14 -0700 (PDT) From: Ted Lemon Message-Id: <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5AB41AA7-2B57-4BE3-9B27-0532B5E9133A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 3 Jul 2019 11:12:11 -0400 In-Reply-To: Cc: Tom Pusateri , draft-ietf-dnssd-push.all@ietf.org, gen-art@ietf.org, dnssd@ietf.org, IETF To: Robert Sparks References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2019 15:12:26 -0000 --Apple-Mail=_5AB41AA7-2B57-4BE3-9B27-0532B5E9133A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 3, 2019, at 10:45 AM, Robert Sparks wrote: > And I think that's a problem. >=20 > What does a NOTIMP mean to the client? Most of the draft says "The = server doesn't implement DSO". It doesn't say "doesn't implement DSO for = this particular set of bits in this query". Section 6.2.2 says the = client should assume a retry delay of 1 hour before talking to the = server (the resolver) again. >=20 > Now, other parts of the document imply "for this particular set of = bits" - in the overview, near the bottom of page 5, it says to use = NOTIMP (actually it says NOTIMPL, maybe those are different things and = I'm confused?) if a message is received for a class other than "IN" and = the server has only implemented push for "IN". Again, that "assume a = retry delay" kicks in. Robert, first, thanks for doing a really thorough review of this = document. This is much appreciated. This particular insight is one = that I think is really important. I think your initial take on this is = correct: if a resolver receives NOTIMP or DSONI from upstream, what this = means is =E2=80=9Cfail,=E2=80=9D not =E2=80=9Cnot implemented,=E2=80=9D = from the perspective of the resolver. The resolver knows what the = client is asking, and can=E2=80=99t do it. That=E2=80=99s SERVFAIL, not = NOTIMP or DSONI. I think your subsequent point about terminating connections is also = correct: we do not want a billion broken clients hammering on servers. = However, the DSO document actually specifies how to deal with this: the = server can tell the client to shut up for a period of time, and this is = explicitly recommended for situations like this. The advantage of = failing in cases like this is that it causes the implementation to not = work, which then motivates the implementor to fix it. And thanks for the advice about how to terminate TLS connections=E2=80=94I= had missed that nuance. Are TLS implementations actually able to do = this (to reject RST packets)? --Apple-Mail=_5AB41AA7-2B57-4BE3-9B27-0532B5E9133A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 3, 2019, at 10:45 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
And I think that's a problem.

What does a NOTIMP mean to the client? Most of the draft says = "The server doesn't implement DSO". It doesn't say "doesn't implement = DSO for this particular set of bits in this query". Section 6.2.2 says = the client should assume a retry delay of 1 hour before talking to the = server (the resolver) again.

Now, other parts of the document imply "for this particular = set of bits" - in the overview, near the bottom of page 5, it says to = use NOTIMP (actually it says NOTIMPL, maybe those are different things = and I'm confused?) if a message is received for a class other than "IN" = and the server has only implemented push for "IN". Again, that "assume a = retry delay" kicks in.

Robert, first, thanks for doing a really thorough review of = this document.  This is much appreciated.   This particular = insight is one that I think is really important.   I think your = initial take on this is correct: if a resolver receives NOTIMP or DSONI = from upstream, what this means is =E2=80=9Cfail,=E2=80=9D not =E2=80=9Cnot= implemented,=E2=80=9D from the perspective of the resolver.   The = resolver knows what the client is asking, and can=E2=80=99t do it. =  That=E2=80=99s SERVFAIL, not NOTIMP or DSONI.

I think your subsequent = point about terminating connections is also correct: we do not want a = billion broken clients hammering on servers.  However, the DSO = document actually specifies how to deal with this: the server can tell = the client to shut up for a period of time, and this is explicitly = recommended for situations like this.   The advantage of failing in = cases like this is that it causes the implementation to not work, which = then motivates the implementor to fix it.

And thanks for the advice about how to = terminate TLS connections=E2=80=94I had missed that nuance.  Are = TLS implementations actually able to do this (to reject RST = packets)?

= --Apple-Mail=_5AB41AA7-2B57-4BE3-9B27-0532B5E9133A-- From nobody Thu Jul 4 09:52:33 2019 Return-Path: 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 15262120091; Thu, 4 Jul 2019 09:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 hc8iBmpJ7eQv; Thu, 4 Jul 2019 09:52:28 -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 1C24212000E; Thu, 4 Jul 2019 09:52:27 -0700 (PDT) Received: from [172.16.10.104] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (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 8BA3C33D61; Thu, 4 Jul 2019 12:52:26 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_46456897-3773-4E84-8E07-6864F68217CE" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Date: Thu, 4 Jul 2019 12:52:25 -0400 In-Reply-To: <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com> Cc: Robert Sparks , draft-ietf-dnssd-push.all@ietf.org, gen-art@ietf.org, dnssd@ietf.org, IETF To: Ted Lemon References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com> X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 16:52:31 -0000 --Apple-Mail=_46456897-3773-4E84-8E07-6864F68217CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 3, 2019, at 11:12 AM, Ted Lemon wrote: >=20 > On Jul 3, 2019, at 10:45 AM, Robert Sparks > wrote: >> And I think that's a problem. >>=20 >> What does a NOTIMP mean to the client? Most of the draft says "The = server doesn't implement DSO". It doesn't say "doesn't implement DSO for = this particular set of bits in this query". Section 6.2.2 says the = client should assume a retry delay of 1 hour before talking to the = server (the resolver) again. >>=20 >> Now, other parts of the document imply "for this particular set of = bits" - in the overview, near the bottom of page 5, it says to use = NOTIMP (actually it says NOTIMPL, maybe those are different things and = I'm confused?) if a message is received for a class other than "IN" and = the server has only implemented push for "IN". Again, that "assume a = retry delay" kicks in. >=20 > Robert, first, thanks for doing a really thorough review of this = document. This is much appreciated. This particular insight is one = that I think is really important. I think your initial take on this is = correct: if a resolver receives NOTIMP or DSONI from upstream, what this = means is =E2=80=9Cfail,=E2=80=9D not =E2=80=9Cnot implemented,=E2=80=9D = from the perspective of the resolver. The resolver knows what the = client is asking, and can=E2=80=99t do it. That=E2=80=99s SERVFAIL, not = NOTIMP or DSONI. >=20 a. If the client sends SUBSCRIBE or KEEPALIVE to the resolver and the = resolver doesn=E2=80=99t support DSO, it will send NOTIMP whether you = want it to or not because it doesn=E2=80=99t know about the opcode. b. If the client sends SUBSCRIBE and gets back DSONI from the resolver = because it supports DSO but not PUSH Notifications, the resolver is = following the DSO spec. c. If the client sends KEEPALIVE and successfully establishes a DSO = connection to the resolver and then sends SUBSCRIBE and the resolver = gets back NOTIMP from the authoritative, and returns this to the client, = then the client knows exactly that the problem is that the authoritative = doesn=E2=80=99t support DSO. To solve the ambiguity: 1. The client should only send SUBSCRIBE to set up the DSO session if it = has gone through the discovery process and wants to talk to the = authoritative directly. If it wants to try to subscribe to push = notifications through a resolver, then it should use KEEPALIVE first to = establish the DSO connection with the resolver. 2. If the resolver supports SUBSCRIBE but the authoritative doesn=E2=80=99= t, the resolver should not send DSONI back to the client because the = client can=E2=80=99t tell the difference between the resolver not = supporting SUBSCRIBE and the authoritative not supporting SUBSCRIBE. In = this case, the resolver should return SERVFAIL. This should inform the = client that the authoritative doesn=E2=80=99t support SUBSCRIBE. If = there are multiple authoritative servers supporting _dns-push._tcp, the = resolver may want to try all of them before returning SERVFAIL. > I think your subsequent point about terminating connections is also = correct: we do not want a billion broken clients hammering on servers. = However, the DSO document actually specifies how to deal with this: the = server can tell the client to shut up for a period of time, and this is = explicitly recommended for situations like this. The advantage of = failing in cases like this is that it causes the implementation to not = work, which then motivates the implementor to fix it. >=20 > And thanks for the advice about how to terminate TLS connections=E2=80=94= I had missed that nuance. Are TLS implementations actually able to do = this (to reject RST packets)? This was actually a comment from David Schinazi (and a good one). I=E2=80=99= ve adjusted the working copy on github but there=E2=80=99s still one = section I=E2=80=99m wrestling with regarding TCP RST. Thanks, Tom --Apple-Mail=_46456897-3773-4E84-8E07-6864F68217CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 3, 2019, at 11:12 AM, Ted Lemon <mellon@fugue.com> = wrote:

On Jul 3, 2019, at = 10:45 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
And I think that's a problem.

What does a NOTIMP mean to the client? Most of the draft says = "The server doesn't implement DSO". It doesn't say "doesn't implement = DSO for this particular set of bits in this query". Section 6.2.2 says = the client should assume a retry delay of 1 hour before talking to the = server (the resolver) again.

Now, other parts of the document imply "for this particular = set of bits" - in the overview, near the bottom of page 5, it says to = use NOTIMP (actually it says NOTIMPL, maybe those are different things = and I'm confused?) if a message is received for a class other than "IN" = and the server has only implemented push for "IN". Again, that "assume a = retry delay" kicks in.

Robert, first, thanks for doing a really thorough review of = this document.  This is much appreciated.   This particular = insight is one that I think is really important.   I think your = initial take on this is correct: if a resolver receives NOTIMP or DSONI = from upstream, what this means is =E2=80=9Cfail,=E2=80=9D not =E2=80=9Cnot= implemented,=E2=80=9D from the perspective of the resolver.   The = resolver knows what the client is asking, and can=E2=80=99t do it. =  That=E2=80=99s SERVFAIL, not NOTIMP or DSONI.


a. If the client sends SUBSCRIBE or KEEPALIVE to = the resolver and the resolver doesn=E2=80=99t support DSO, it will send = NOTIMP whether you want it to or not because it doesn=E2=80=99t know = about the opcode.

b. If the client = sends SUBSCRIBE and gets back DSONI from the resolver because it = supports DSO but not PUSH Notifications, the resolver is following the = DSO spec.

c. If the client sends = KEEPALIVE and successfully establishes a DSO connection to the resolver = and then sends SUBSCRIBE and the resolver gets back NOTIMP from the = authoritative, and returns this to the client, then the client knows = exactly that the problem is that the authoritative doesn=E2=80=99t = support DSO.

To solve the = ambiguity:

1. The client should only = send SUBSCRIBE to set up the DSO session if it has gone through the = discovery process and wants to talk to the authoritative directly. If it = wants to try to subscribe to push notifications through a resolver, then = it should use KEEPALIVE first to establish the DSO connection with the = resolver.

2. If the resolver = supports SUBSCRIBE but the authoritative doesn=E2=80=99t, the resolver = should not send DSONI back to the client because the client can=E2=80=99t = tell the difference between the resolver not supporting SUBSCRIBE and = the authoritative not supporting SUBSCRIBE. In this case, the resolver = should return SERVFAIL. This should inform the client that the = authoritative doesn=E2=80=99t support SUBSCRIBE. If there are multiple = authoritative servers supporting _dns-push._tcp, the resolver may want = to try all of them before returning SERVFAIL.

I = think your subsequent point about terminating connections is also = correct: we do not want a billion broken clients hammering on servers. =  However, the DSO document actually specifies how to deal with = this: the server can tell the client to shut up for a period of time, = and this is explicitly recommended for situations like this.   The = advantage of failing in cases like this is that it causes the = implementation to not work, which then motivates the implementor to fix = it.

And thanks = for the advice about how to terminate TLS connections=E2=80=94I had = missed that nuance.  Are TLS implementations actually able to do = this (to reject RST packets)?

This was actually a comment from David Schinazi = (and a good one). I=E2=80=99ve adjusted the working copy on github but = there=E2=80=99s still one section I=E2=80=99m wrestling with regarding = TCP RST.

Thanks,
Tom


= --Apple-Mail=_46456897-3773-4E84-8E07-6864F68217CE-- From nobody Thu Jul 4 11:13:37 2019 Return-Path: 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 122E1120143 for ; Thu, 4 Jul 2019 11:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oLRQL0xqdJ3t for ; Thu, 4 Jul 2019 11:13:25 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 2A114120159 for ; Thu, 4 Jul 2019 11:13:22 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id v22so6115104qkj.8 for ; Thu, 04 Jul 2019 11:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5yXs/2EZLbNUZ763/11/SaFYPLjepWGHWS24gg/nd4k=; b=nFMi2EsLUvfzUSD5t57WEvZ6TDWxw48PZJ5XmX28WcCoCN515mcFCsu9RV/PwHcauZ eqkQ+DI9kHlxrP7eg+pSAV5knldPQ1ZBGdIMJ7sNdPvlrxLaXDKQBVRU8FfFU0IzMER8 Ob1CeZBZW3qkSLeutXJG6QtoIm9uKlwmlImxRr++sTgLIEcxMMlKk+lB4i613tPFuB5O xA89RaAu/I1TT4pg3IQzDimfPdtosCwiUUnwD2sFpYkJx86I/jrO+wHRSVgy98L39e6V BJ+kTj38Wz0engFj9Wca5GmGOAiQF01MAxaPXlIIK1qpPUVmjbn12xqwPAgNqCrvj+pI 6nhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5yXs/2EZLbNUZ763/11/SaFYPLjepWGHWS24gg/nd4k=; b=Ii3i7GvhEEpbW1n+7IV8SEy0GRIwsq/mR3nB3m8A0BDxZxPNfyE7wspxwktCROZkX5 0ALpKG3c3ikiUmCsLPYIY+AZgKwNgbU0NtKzxdKA1zUg2HXixIvHhGtQi0vjFEvgSVV3 6eZhXt0DyueP6t++vdiM4JYRqYvvn1cBe0QHI0rVAKIWvMo1IY3ppk0OGzgz6PQ0qYxh DNicex+ZkSEQVi3w6vOyEQIuwbZfh8llxd0gvkGVCgDxP1AMiIPYwq7xb6crsFD5ELq/ eDo/grnyiNpEIT5TuYuzJhs30LEIpNWc57EWJP3lAAQhGu6zMTUAX9i/KH9DMQLhAbRv QRjA== X-Gm-Message-State: APjAAAW6m8IGmKp+ZBCtJ8KIe+/BoUjFhgpmybsnJPXvi/wSOyvQo9D0 3zAD2rNUXCp6+2LNaL+40rtXrg== X-Google-Smtp-Source: APXvYqyQOP+mVVoSn6ocwHMJVptijj13sRd72CBlGc1CplRcG0rvu4vHf9/ZLKjHEjPMvv2rmYRbNQ== X-Received: by 2002:ae9:f809:: with SMTP id x9mr2959960qkh.86.1562264000950; Thu, 04 Jul 2019 11:13:20 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:14d2:b425:853d:12fe? ([2001:470:c1a2:1:14d2:b425:853d:12fe]) by smtp.gmail.com with ESMTPSA id h4sm2710075qkk.39.2019.07.04.11.13.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 11:13:20 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8E55E8C5-D8D8-4EC6-8C68-9BAEC871F6A6" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 4 Jul 2019 14:13:16 -0400 In-Reply-To: Cc: Robert Sparks , draft-ietf-dnssd-push.all@ietf.org, gen-art@ietf.org, dnssd@ietf.org, IETF To: Tom Pusateri References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 18:13:27 -0000 --Apple-Mail=_8E55E8C5-D8D8-4EC6-8C68-9BAEC871F6A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 4, 2019, at 12:52 PM, Tom Pusateri wrote: > 1. The client should only send SUBSCRIBE to set up the DSO session if = it has gone through the discovery process and wants to talk to the = authoritative directly. If it wants to try to subscribe to push = notifications through a resolver, then it should use KEEPALIVE first to = establish the DSO connection with the resolver. This creates a new semantic connection between KEEPALIVE and SUBSCRIBE. = This means that DSO implementations now have to track more state. I = don=E2=80=99t think there=E2=80=99s a benefit to doing this. Why do you = think it=E2=80=99s necessary? > 2. If the resolver supports SUBSCRIBE but the authoritative doesn=E2=80=99= t, the resolver should not send DSONI back to the client because the = client can=E2=80=99t tell the difference between the resolver not = supporting SUBSCRIBE and the authoritative not supporting SUBSCRIBE. In = this case, the resolver should return SERVFAIL. This should inform the = client that the authoritative doesn=E2=80=99t support SUBSCRIBE. If = there are multiple authoritative servers supporting _dns-push._tcp, the = resolver may want to try all of them before returning SERVFAIL. There=E2=80=99s no need to mention DSONI here. Just say what the right = behavior is. If you mention DSONI here, someone might read this to = suggest that in some case DSONI would make sense. SERVFAIL just means that the server is unable to support the requested = behavior. It doesn=E2=80=99t signal why. Unless there=E2=80=99s = something the client would do differently, I don=E2=80=99t think it=E2=80=99= s necessary for the client to know why the request failed. --Apple-Mail=_8E55E8C5-D8D8-4EC6-8C68-9BAEC871F6A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 4, 2019, at 12:52 PM, Tom Pusateri <pusateri@bangj.com> = wrote:
1. = The client should only send SUBSCRIBE to set up the DSO session if it = has gone through the discovery process and wants to talk to the = authoritative directly. If it wants to try to subscribe to push = notifications through a resolver, then it should use KEEPALIVE first to = establish the DSO connection with the = resolver.

This creates = a new semantic connection between KEEPALIVE and SUBSCRIBE.  This = means that DSO implementations now have to track more state.  I = don=E2=80=99t think there=E2=80=99s a benefit to doing this.  Why = do you think it=E2=80=99s necessary?

2. = If the resolver supports SUBSCRIBE but the authoritative doesn=E2=80=99t, = the resolver should not send DSONI back to the client because the client = can=E2=80=99t tell the difference between the resolver not supporting = SUBSCRIBE and the authoritative not supporting SUBSCRIBE. In this case, = the resolver should return SERVFAIL. This should inform the client that = the authoritative doesn=E2=80=99t support SUBSCRIBE. If there are = multiple authoritative servers supporting _dns-push._tcp, the resolver = may want to try all of them before returning = SERVFAIL.

There=E2=80=99s no need to mention DSONI here. =  Just say what the right behavior is.  If you mention DSONI = here, someone might read this to suggest that in some case DSONI would make = sense.

SERVFAIL just means that the server is = unable to support the requested behavior. It doesn=E2=80=99t signal why. = Unless there=E2=80=99s something the client would do differently, I = don=E2=80=99t think it=E2=80=99s necessary for the client to know why = the request failed.

= --Apple-Mail=_8E55E8C5-D8D8-4EC6-8C68-9BAEC871F6A6-- From nobody Thu Jul 4 12:32:58 2019 Return-Path: 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 EF9481201C5; Thu, 4 Jul 2019 12:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 sKQDwqBRnqFd; Thu, 4 Jul 2019 12:32:54 -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 A6E331200B6; Thu, 4 Jul 2019 12:32:54 -0700 (PDT) Received: from [172.16.10.104] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (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 460EB33D87; Thu, 4 Jul 2019 15:32:53 -0400 (EDT) From: Tom Pusateri Message-Id: <8ED0A4DA-3398-4CC8-8896-E126D82D6A31@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_12A1A3AA-CB83-4CAC-A31B-4DE43C1D6F6D" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Date: Thu, 4 Jul 2019 15:32:52 -0400 In-Reply-To: Cc: draft-ietf-dnssd-push.all@ietf.org, gen-art@ietf.org, IETF , dnssd@ietf.org, Robert Sparks To: Ted Lemon References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com> X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 19:32:57 -0000 --Apple-Mail=_12A1A3AA-CB83-4CAC-A31B-4DE43C1D6F6D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 4, 2019, at 2:13 PM, Ted Lemon wrote: >=20 > On Jul 4, 2019, at 12:52 PM, Tom Pusateri > wrote: >> 1. The client should only send SUBSCRIBE to set up the DSO session if = it has gone through the discovery process and wants to talk to the = authoritative directly. If it wants to try to subscribe to push = notifications through a resolver, then it should use KEEPALIVE first to = establish the DSO connection with the resolver. >=20 > This creates a new semantic connection between KEEPALIVE and = SUBSCRIBE. This means that DSO implementations now have to track more = state. I don=E2=80=99t think there=E2=80=99s a benefit to doing this. = Why do you think it=E2=80=99s necessary? >=20 Do I already have a session or not with my resolver is not a lot of = extra state. Especially when it=E2=80=99s over TLS and you are likely to = keep the session up for some time and then let it expire. This state is = necessary regardless. I was trying to give the client enough information to determine WHY it = failed. If we determine this isn=E2=80=99t important, we can just let = the client try to figure it out but it will be more work for the client. >> 2. If the resolver supports SUBSCRIBE but the authoritative = doesn=E2=80=99t, the resolver should not send DSONI back to the client = because the client can=E2=80=99t tell the difference between the = resolver not supporting SUBSCRIBE and the authoritative not supporting = SUBSCRIBE. In this case, the resolver should return SERVFAIL. This = should inform the client that the authoritative doesn=E2=80=99t support = SUBSCRIBE. If there are multiple authoritative servers supporting = _dns-push._tcp, the resolver may want to try all of them before = returning SERVFAIL. >=20 > There=E2=80=99s no need to mention DSONI here. Just say what the = right behavior is. If you mention DSONI here, someone might read this = to suggest that in some case DSONI would make sense. >=20 > SERVFAIL just means that the server is unable to support the requested = behavior. It doesn=E2=80=99t signal why. Unless there=E2=80=99s = something the client would do differently, I don=E2=80=99t think it=E2=80=99= s necessary for the client to know why the request failed. It=E2=80=99s likely that resolvers aren=E2=80=99t going to support this = before authoritative servers are and clients will quickly learn their = resolver isn=E2=80=99t capable and go directly to the authoritative for = some period of time. Tom --Apple-Mail=_12A1A3AA-CB83-4CAC-A31B-4DE43C1D6F6D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 4, 2019, at 2:13 PM, Ted Lemon <mellon@fugue.com> = wrote:

On Jul 4, 2019, at = 12:52 PM, Tom Pusateri <pusateri@bangj.com> wrote:
1. The client should only send = SUBSCRIBE to set up the DSO session if it has gone through the discovery = process and wants to talk to the authoritative directly. If it wants to = try to subscribe to push notifications through a resolver, then it = should use KEEPALIVE first to establish the DSO connection with the = resolver.

This creates a new semantic connection between KEEPALIVE and = SUBSCRIBE.  This means that DSO implementations now have to track = more state.  I don=E2=80=99t think there=E2=80=99s a benefit to = doing this.  Why do you think it=E2=80=99s necessary?


Do I already have a session or not with my resolver is = not a lot of extra state. Especially when it=E2=80=99s over TLS and you = are likely to keep the session up for some time and then let it expire. = This state is necessary regardless.

I = was trying to give the client enough information to determine WHY it = failed. If we determine this isn=E2=80=99t important, we can just let = the client try to figure it out but it will be more work for the = client.

2. If the resolver supports SUBSCRIBE but the = authoritative doesn=E2=80=99t, the resolver should not send DSONI back = to the client because the client can=E2=80=99t tell the difference = between the resolver not supporting SUBSCRIBE and the authoritative not = supporting SUBSCRIBE. In this case, the resolver should return SERVFAIL. = This should inform the client that the authoritative doesn=E2=80=99t = support SUBSCRIBE. If there are multiple authoritative servers = supporting _dns-push._tcp, the resolver may want to try all of them = before returning SERVFAIL.

There=E2=80=99s no need to mention DSONI here.  Just say = what the right behavior is.  If you mention DSONI here, someone = might read this to suggest that in some case DSONI would = make = sense.

SERVFAIL just = means that the server is unable to support the requested behavior. It = doesn=E2=80=99t signal why. Unless there=E2=80=99s something the client = would do differently, I don=E2=80=99t think it=E2=80=99s necessary for = the client to know why the request = failed.


It=E2=80=99s likely that resolvers aren=E2=80=99t going to = support this before authoritative servers are and clients will quickly = learn their resolver isn=E2=80=99t capable and go directly to the = authoritative for some period of time.

Tom


= --Apple-Mail=_12A1A3AA-CB83-4CAC-A31B-4DE43C1D6F6D-- From nobody Thu Jul 4 12:54:17 2019 Return-Path: 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 9D6AE1200B6 for ; Thu, 4 Jul 2019 12:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 EI8wx1qD4PBn for ; Thu, 4 Jul 2019 12:54:08 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 CA783120188 for ; Thu, 4 Jul 2019 12:54:07 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id w17so5900538qto.10 for ; Thu, 04 Jul 2019 12:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=JJHTVdctnQUMJAV1RrFA9LKeiGlK+7sbi1FyyYj0aUc=; b=xl7GCVJ1J8ap8QGtEgf7GTdlt0sdaoxCL8wIZbbsCUH7Zfb2VPcjTlA13n5gG5GbJ7 maotUwBlBLqGapGCM2VpWOBl9XufWOVndmX6/3WPsuzGoXDw6rgL/qRunwD0eKMURa5o NmGVFaV9UPtMj+2QiYS4rZtONNEdbzhHofLS2rEfm8l/NodB2ADlm89QJjFnS8aONG6g RjyJg1j9EV6Q8Mrm6UmAdw1GCVx+u5gYJZGXN1c+0TTmsMqCKZepf7nyOQ9foyw79mzv 31qSJZsUYzTmZSFzWseyjhr42pgUDQVnhntmc+oA/2mIkQq30XL8Qp2FJv92kSSYsIwG NRKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=JJHTVdctnQUMJAV1RrFA9LKeiGlK+7sbi1FyyYj0aUc=; b=HY7cVlCHdhoKjY4ednxvDB0ljhVnL/hCcQHkB5QERhsz43M1vGBPJIgqU2jAeClBQe Nzo5k1uFs9zR6483RidOstSgaOCdoPqID1APwzrPPndnuB6nIj7oypdJXzJPb6WD+puJ Hkhoql7dpDj6+J3NkTDSgc4ncotpQ2ZA1+i7JDVltWGj/Skm+DkCsf09wbnPsP+ij79g b8jaEt3NwlfFe6HAkcrlOCxJBsTjGptAhUQpuNvl4AHLWYAv0cSprEliH8RySVfPnqmk jfilJSA+XwR6wVrBSrFBkUAwoCB4imNJWQGZspgWX3c0+S7aUOdVJujkq0nW6ZdoqQfI NTIQ== X-Gm-Message-State: APjAAAW2g9L5IKbZO5YjwR6TAD4tSdSJkGhuYjdF3FQc4Kgt/mp5g0/G c2jkjGMYuMNpxn0g3S7Io67D/Q== X-Google-Smtp-Source: APXvYqxtcxH9ujZVWR6gs7JUaVr+q4IzAILovRPjNGALj/feFilRjyZiy4cGJ1+IVPztH90rz6999A== X-Received: by 2002:ac8:3636:: with SMTP id m51mr36557837qtb.102.1562270046830; Thu, 04 Jul 2019 12:54:06 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:14d2:b425:853d:12fe? ([2001:470:c1a2:1:14d2:b425:853d:12fe]) by smtp.gmail.com with ESMTPSA id n5sm3040379qta.29.2019.07.04.12.54.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 12:54:06 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_001132AE-C0BE-49C2-971B-22D3612A314F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 4 Jul 2019 15:54:04 -0400 In-Reply-To: <8ED0A4DA-3398-4CC8-8896-E126D82D6A31@bangj.com> Cc: draft-ietf-dnssd-push.all@ietf.org, gen-art@ietf.org, IETF , dnssd@ietf.org, Robert Sparks To: Tom Pusateri References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com> <8ED0A4DA-3398-4CC8-8896-E126D82D6A31@bangj.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 19:54:11 -0000 --Apple-Mail=_001132AE-C0BE-49C2-971B-22D3612A314F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 4, 2019, at 3:32 PM, Tom Pusateri wrote: > I was trying to give the client enough information to determine WHY it = failed. If we determine this isn=E2=80=99t important, we can just let = the client try to figure it out but it will be more work for the client. The client is a computer program, not a person, so there is no chance = that it will be able to figure out what went wrong! :) Seriously, though, what=E2=80=99s the strategy the client should follow = in this case? I think we generally say =E2=80=9Ctry again in an hour=E2=80= =9D but I=E2=80=99m not sure if we said that explicitly here or just in = the DSO document. > It=E2=80=99s likely that resolvers aren=E2=80=99t going to support = this before authoritative servers are and clients will quickly learn = their resolver isn=E2=80=99t capable and go directly to the = authoritative for some period of time. I think that how resolver support for this will work is an open question = right now, which will probably have to be addressed in a follow-on = document. At present, the implementation I=E2=80=99ve done doesn=E2=80=99= t even attempt the local resolver, because I couldn=E2=80=99t figure out = how to implement that. I=E2=80=99m assuming that in most cases = there=E2=80=99s no particular benefit to using the local resolver, = because the auth server will also be local. --Apple-Mail=_001132AE-C0BE-49C2-971B-22D3612A314F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 4, 2019, at 3:32 PM, Tom Pusateri <pusateri@bangj.com> = wrote:
I was = trying to give the client enough information to determine WHY it failed. = If we determine this isn=E2=80=99t important, we can just let the client = try to figure it out but it will be more work for the = client.

The client is = a computer program, not a person, so there is no chance that it will be = able to figure out what went wrong! :)

Seriously, though, what=E2=80=99s the strategy the = client should follow in this case?  I think we generally say =E2=80=9C= try again in an hour=E2=80=9D but I=E2=80=99m not sure if we said that = explicitly here or just in the DSO document.

It=E2=80=99s = likely that resolvers aren=E2=80=99t going to support this before = authoritative servers are and clients will quickly learn their resolver = isn=E2=80=99t capable and go directly to the authoritative for some = period of time.

I think that how resolver support for this = will work is an open question right now, which will probably have to be = addressed in a follow-on document.  At present, the implementation = I=E2=80=99ve done doesn=E2=80=99t even attempt the local resolver, = because I couldn=E2=80=99t figure out how to implement that.  I=E2=80= =99m assuming that in most cases there=E2=80=99s no particular benefit = to using the local resolver, because the auth server will also be = local.

= --Apple-Mail=_001132AE-C0BE-49C2-971B-22D3612A314F-- From nobody Thu Jul 4 13:09:15 2019 Return-Path: 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 5A2F512029C; Thu, 4 Jul 2019 13:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 yCtpADPg0ZAe; Thu, 4 Jul 2019 13:09:11 -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 F00FD120223; Thu, 4 Jul 2019 13:09:10 -0700 (PDT) Received: from [172.16.10.123] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (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 EA3C233D96; Thu, 4 Jul 2019 16:09:09 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-44B26C82-FA46-489D-AA61-E5F239E6C399 Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Thu, 4 Jul 2019 16:09:09 -0400 Cc: dnssd@ietf.org, draft-ietf-dnssd-push.all@ietf.org, gen-art@ietf.org, IETF , Robert Sparks Content-Transfer-Encoding: 7bit Message-Id: References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com> <8ED0A4DA-3398-4CC8-8896-E126D82D6A31@bangj.com> To: Ted Lemon Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 20:09:15 -0000 --Apple-Mail-44B26C82-FA46-489D-AA61-E5F239E6C399 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Maybe we could have a conference call and hash this out. Anyone is welcome.=20= I=E2=80=99m ok with removing resolver support for now to simplify this and t= ackle resolvers in another document. But if there=E2=80=99s a good solution w= e=E2=80=99re all happy with, we can fix it now.=20 Tom > On Jul 4, 2019, at 3:54 PM, Ted Lemon wrote: >=20 >> On Jul 4, 2019, at 3:32 PM, Tom Pusateri wrote: >> I was trying to give the client enough information to determine WHY it fa= iled. If we determine this isn=E2=80=99t important, we can just let the clie= nt try to figure it out but it will be more work for the client. >=20 > The client is a computer program, not a person, so there is no chance that= it will be able to figure out what went wrong! :) >=20 > Seriously, though, what=E2=80=99s the strategy the client should follow in= this case? I think we generally say =E2=80=9Ctry again in an hour=E2=80=9D= but I=E2=80=99m not sure if we said that explicitly here or just in the DSO= document. >=20 >> It=E2=80=99s likely that resolvers aren=E2=80=99t going to support this b= efore authoritative servers are and clients will quickly learn their resolve= r isn=E2=80=99t capable and go directly to the authoritative for some period= of time. >=20 > I think that how resolver support for this will work is an open question r= ight now, which will probably have to be addressed in a follow-on document. = At present, the implementation I=E2=80=99ve done doesn=E2=80=99t even attem= pt the local resolver, because I couldn=E2=80=99t figure out how to implemen= t that. I=E2=80=99m assuming that in most cases there=E2=80=99s no particul= ar benefit to using the local resolver, because the auth server will also be= local. >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail-44B26C82-FA46-489D-AA61-E5F239E6C399 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
May= be we could have a conference call and hash this out. Anyone is welcome.&nbs= p;

I=E2=80=99m ok with remo= ving resolver support for now to simplify this and tackle resolvers in anoth= er document. But if there=E2=80=99s a good solution we=E2=80=99re all happy w= ith, we can fix it now. 

Tom

On Jul 4, 2019, at 3:54 PM, Ted Lemon <<= a href=3D"mailto:mellon@fugue.com">mellon@fugue.com> wrote:

On Jul 4, 2019, at 3:32 PM, Tom P= usateri <pusateri@bangj.= com> wrote:
=
I was trying to give the client enough inf= ormation to determine WHY it failed. If we determine this isn=E2=80=99t impo= rtant, we can just let the client try to figure it out but it will be more w= ork for the client.

The cl= ient is a computer program, not a person, so there is no chance that it will= be able to figure out what went wrong! :)

Seriously, though, what=E2=80=99s the strategy the client should follow i= n this case?  I think we generally say =E2=80=9Ctry again in an hour=E2= =80=9D but I=E2=80=99m not sure if we said that explicitly here or just in t= he DSO document.

It=E2=80=99s likely that resolvers aren=E2=80=99t going to suppo= rt this before authoritative servers are and clients will quickly learn thei= r resolver isn=E2=80=99t capable and go directly to the authoritative for so= me period of time.

I= think that how resolver support for this will work is an open question righ= t now, which will probably have to be addressed in a follow-on document. &nb= sp;At present, the implementation I=E2=80=99ve done doesn=E2=80=99t even att= empt the local resolver, because I couldn=E2=80=99t figure out how to implem= ent that.  I=E2=80=99m assuming that in most cases there=E2=80=99s no p= articular benefit to using the local resolver, because the auth server will a= lso be local.

________________________________________= _______
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd<= /a>
= --Apple-Mail-44B26C82-FA46-489D-AA61-E5F239E6C399-- From nobody Thu Jul 4 14:31:06 2019 Return-Path: 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 5DDE61200D8 for ; Thu, 4 Jul 2019 14:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 JLLH-it55m3k for ; Thu, 4 Jul 2019 14:30:49 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 4E53C120220 for ; Thu, 4 Jul 2019 14:30:47 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id m14so6453014qka.10 for ; Thu, 04 Jul 2019 14:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vfw8mZBpd6SpTDpjwVk7ihAY6HDMiI5kBPzLyhij28Q=; b=HNVBr4TSzoklo5y/rDGs3Md4vR3XOz+mvSJEtr8csmuQiOidc4TcNKIShqrTMn7VgE Td6bfLY3r+Go0sn74Ly7OFkGA2/dfvbIogjC5Dr5eXfvdZVkLR7vMqmczOKhBmHu4KRM eesSMdV3rYJ/Tlh+A+yVukidFj4fjHoWaSSIgwv0UbobLSM7+VNRMZ5Vnu64i1nkE5xE SV7mDiEnU1H6FhBXDQURP3oMng/Y0ES1sZqEQUSvyVTfMhJMSS/3AvlxvsqmwRNaMAwH oPAXhLVAQ5gX8AxXa5EI1Yphp1yw7PQzEk8O9J1ClmB3TCryBMP90zL2R0D6voA8/3+4 01bQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vfw8mZBpd6SpTDpjwVk7ihAY6HDMiI5kBPzLyhij28Q=; b=FsNPRM53XPRV76Kht63J3ces0UPjZyjHvbxizDFRSQk5kECAshUfNZiXKiQ84tsjHF 04VfNsmiAmqsNRc3YBTLEY/wWbJnUxShcXgtUPKLup7i6Aqqn5eTww2ukOftfIxmN0G6 TfextlGtNsuBoZrZS98d9pTKWdEYbPwoFIHW3gr2miSZ2geeTDJIanB3QEEpJkWbnSUK /LQiJNJYk/38X7Y0VPiQIg+tUwgyqxJt91GOMAQLCwNZNN1Ul15JyIQB16k78eH3LAY4 9vnKvUFwU+TsdOzFStL1DP7u1yILWCUIp8fLTtE2pVWoNTDowrZHdoFGBAiTmSqX73Li mYRA== X-Gm-Message-State: APjAAAWkHNITinWvWCuBPpTgOLDVXm+tedovrvfcDd+bBGLxUUHxNmO4 urHn++ZQUvCR1Y3H5ugCy1NaMQ== X-Google-Smtp-Source: APXvYqxQUFUrnd5D2eTITygNbXZ2SWjoLEZdRHI7iQkVJbLQ2JLoZO0snDAmNWJkbRkGvYS1aF+rQg== X-Received: by 2002:ae9:e217:: with SMTP id c23mr442487qkc.227.1562275845174; Thu, 04 Jul 2019 14:30:45 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:14d2:b425:853d:12fe? ([2001:470:c1a2:1:14d2:b425:853d:12fe]) by smtp.gmail.com with ESMTPSA id o17sm2612856qkm.6.2019.07.04.14.30.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 14:30:44 -0700 (PDT) From: Ted Lemon Message-Id: <307B7C7F-1920-48FB-8316-FCEC250513D6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C9B376A0-B437-4102-B8AA-6DDB9AF354CD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 4 Jul 2019 17:30:39 -0400 In-Reply-To: Cc: dnssd@ietf.org, draft-ietf-dnssd-push.all@ietf.org, gen-art@ietf.org, IETF , Robert Sparks To: Tom Pusateri References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com> <8ED0A4DA-3398-4CC8-8896-E126D82D6A31@bangj.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 21:30:51 -0000 --Apple-Mail=_C9B376A0-B437-4102-B8AA-6DDB9AF354CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 4, 2019, at 4:09 PM, Tom Pusateri wrote: > I=E2=80=99m ok with removing resolver support for now to simplify this = and tackle resolvers in another document. But if there=E2=80=99s a good = solution we=E2=80=99re all happy with, we can fix it now.=20 I think we=E2=80=99ve specified the parts of resolver support that we = understand, and it would be a shame to take those out. I don=E2=80=99t = think we need to make this any more complicated than that=E2=80=94we=E2=80= =99d talked about the resolver support issue during WGLC, and were = satisfied. Simply addressing the point Robert raised should be = sufficient. --Apple-Mail=_C9B376A0-B437-4102-B8AA-6DDB9AF354CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 4, 2019, at 4:09 PM, Tom Pusateri <pusateri@bangj.com> = wrote:
I=E2=80=99m ok with removing resolver support for now = to simplify this and tackle resolvers in another document. But if = there=E2=80=99s a good solution we=E2=80=99re all happy with, we can fix = it now. 

I think = we=E2=80=99ve specified the parts of resolver support that we = understand, and it would be a shame to take those out.   I don=E2=80=99= t think we need to make this any more complicated than that=E2=80=94we=E2=80= =99d talked about the resolver support issue during WGLC, and were = satisfied.   Simply addressing the point Robert raised should be = sufficient.


= --Apple-Mail=_C9B376A0-B437-4102-B8AA-6DDB9AF354CD-- From nobody Fri Jul 5 17:45:29 2019 Return-Path: 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 E4F9E1200DB; Fri, 5 Jul 2019 17:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3BEj2RhiqC3J; Fri, 5 Jul 2019 17:45:25 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 8EB691200A3; Fri, 5 Jul 2019 17:45:24 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id q26so7315013lfc.3; Fri, 05 Jul 2019 17:45:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8BCl72kwFPqkJdUT9Jz6oxBvNtrbjhUR3CfM1OC2Inc=; b=B5SKjWCZ72oXqXiJ+vMLB5v3qV7opXRgWZKxssOkHFPgW8yB6VrTfaXuBnwjkpNQNH LICqxmmvD0YNsuWHPfI4TvlhBLzoS1rNVItovBVbtAVC+MN4i4duam7Qt3btvB9CmoUr RQvK+Qzowrukp7xgODeuuJy+ovzGuV3MGIKHGz8d3MzVb15vlRkPql7ZWuFGJa9N68r4 2uamNT1j6dLCFIoHfhfh6Iu4YGzsq50lQbNbf7dVrqVv0//W91Nh3fGJ2GxIgmgOzqHf hCx14V6SaR7Lz3OuZHmqCZeGuLRlxLft61gDUZw6F1amQOSSJYX+dGnG5tBM6yROIu+n Ra9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8BCl72kwFPqkJdUT9Jz6oxBvNtrbjhUR3CfM1OC2Inc=; b=bm39IYOfRajoIFOP/CmirvkZ8PSYBVU26S0I/5UAq0pkEH0+9d4mR1dWDHUnxAMYr0 4HP+aIqLrKU2iUtPEeHvB0AkiDhDbyDrKCItfLOXLiVP5ViTN5mCqJh4YjkXm1Ke4l22 dZWaeNAuWIEVZLd1JX78Gd1QriOLu0SH1Fpe/l437FJdov7CwdH/FmPOHxJsK10W3rYk +pVc3ExGUMOsq1eNngb18nVOeoOvFQDJ8Q8nTnze18QHL17yCTu5UU4dZSnclUxT9Z+G U7uHmdcNGV0eMICLBK+ITvH5OxRbR1weiTOn/FyZP+cQzdTZAwAh3j4/Wo/4gcvk5fD4 fJ+Q== X-Gm-Message-State: APjAAAW8P33oOINqlU4F0+V9UiJC5VV+EwRpIHquWUjLpNef+WKdsXVJ Gh4itAnv6ZzMFNvIubJXNT9mO13k6FcPtIHDh6Zi5w== X-Google-Smtp-Source: APXvYqz5xymLKZJlJgalHmayIPD51RpV2/zrpUq91x0PjDm2DSJyaC79/JLXRdXaIWdlQdwz1n3DWpq7KK0VOoeRDPU= X-Received: by 2002:ac2:46ce:: with SMTP id p14mr3310396lfo.148.1562373922700; Fri, 05 Jul 2019 17:45:22 -0700 (PDT) MIME-Version: 1.0 References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com> In-Reply-To: From: David Schinazi Date: Fri, 5 Jul 2019 17:45:11 -0700 Message-ID: To: Tom Pusateri Cc: Ted Lemon , draft-ietf-dnssd-push.all@ietf.org, DNSSD Content-Type: multipart/alternative; boundary="000000000000ab4121058cf8862f" Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 00:45:27 -0000 --000000000000ab4121058cf8862f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 4, 2019 at 9:52 AM Tom Pusateri wrote: > On Jul 3, 2019, at 11:12 AM, Ted Lemon wrote: > > And thanks for the advice about how to terminate TLS connections=E2=80=94= I had > missed that nuance. Are TLS implementations actually able to do this (to > reject RST packets)? > > > This was actually a comment from David Schinazi (and a good one). I=E2=80= =99ve > adjusted the working copy on github but there=E2=80=99s still one section= I=E2=80=99m > wrestling with regarding TCP RST. > On most operating systems today, TCP is in the kernel and TLS is in user-space, so most implementations of TLS over TCP do not have the ability to discard TCP RSTs that were injected by attackers. However, the TLS close_notify alert allows endpoints to be able to tell the difference between a connection that was closed gracefully by the peer and one that was forcefully terminated (possibly by an attacker). So upon receipt of a TCP RST without prior TLS close_notify, the connection will die, but the application will know that the latest message could have been truncated halfway through transmission and should therefore be discarded. David --000000000000ab4121058cf8862f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Jul 4, 2019 at 9:52 AM Tom Pusate= ri <pusateri@bangj.com> wro= te:
On Jul 3, 201= 9, at 11:12 AM, Ted Lemon <mellon@fugue.com> wrote:
An= d thanks for the advice about how to terminate TLS connections=E2=80=94I ha= d missed that nuance.=C2=A0 Are TLS implementations actually able to do thi= s (to reject RST packets)?

Thi= s was actually a comment from David Schinazi (and a good one). I=E2=80=99ve= adjusted the working copy on github but there=E2=80=99s still one section = I=E2=80=99m wrestling with regarding TCP RST.
=
On most operating systems today, TCP is in the kernel and TL= S is in user-space, so most implementations of TLS over TCP do not have the= ability to discard TCP RSTs that were injected by attackers. However, the = TLS close_notify alert allows endpoints to be able to tell the difference b= etween a connection that was closed gracefully by the peer and one that was= forcefully terminated (possibly by an attacker). So upon receipt of a TCP = RST without prior TLS close_notify, the connection will die, but the applic= ation will know that the latest message could have been truncated halfway t= hrough transmission and should therefore be discarded.

=
David=C2=A0
--000000000000ab4121058cf8862f-- From nobody Fri Jul 5 19:41:40 2019 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C14120328; Fri, 5 Jul 2019 19:41:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <156238089783.21969.17041189661403372778@ietfa.amsl.com> Date: Fri, 05 Jul 2019 19:41:37 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-21.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 02:41:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-21.txt Pages : 39 Date : 2019-07-05 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-21 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-21 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 5 19:47:16 2019 Return-Path: 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 BB7AC120345 for ; Fri, 5 Jul 2019 19:47:14 -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 FZI9DuVZNctK for ; Fri, 5 Jul 2019 19:47:12 -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 8EA71120340 for ; Fri, 5 Jul 2019 19:47:12 -0700 (PDT) Received: from [172.16.10.110] (mta-107-13-246-59.nc.rr.com [107.13.246.59]) (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 88AE933F19 for ; Fri, 5 Jul 2019 22:47:11 -0400 (EDT) From: Tom Pusateri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Date: Fri, 5 Jul 2019 22:47:10 -0400 References: <156238089783.21969.17041189661403372778@ietfa.amsl.com> To: DNSSD In-Reply-To: <156238089783.21969.17041189661403372778@ietfa.amsl.com> Message-Id: <0C5D2224-AE6A-4B94-B55A-50F2D3CC93D2@bangj.com> X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-push-21.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 02:47:15 -0000 This version addresses the comments found during the GENART review and = the IANA review. Thanks to Robert Sparks, David Schinazi, Ted Lemon, and =C3=89ric = Vyncke for their valuable feedback. Tom > On Jul 5, 2019, at 10:41 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Extensions for Scalable DNS Service = Discovery WG of the IETF. >=20 > Title : DNS Push Notifications > Authors : Tom Pusateri > Stuart Cheshire > Filename : draft-ietf-dnssd-push-21.txt > Pages : 39 > Date : 2019-07-05 >=20 > Abstract: > The Domain Name System (DNS) was designed to return matching records > efficiently for queries for data that are relatively static. When > those records change frequently, DNS is still efficient at returning > the updated results when polled, as long as the polling rate is not > too high. But there exists no mechanism for a client to be > asynchronously notified when these changes occur. This document > defines a mechanism for a client to be notified of such changes to > DNS records, called DNS Push Notifications. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnssd-push-21 > https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-21 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnssd-push-21 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Sat Jul 6 06:50:42 2019 Return-Path: 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 A25311201D0 for ; Sat, 6 Jul 2019 06:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=Y7X6FG8t; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yW42+t7B 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 IL0wwhhASqz8 for ; Sat, 6 Jul 2019 06:50:38 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9DBD1201CA for ; Sat, 6 Jul 2019 06:50:38 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 1AE7F48D for ; Sat, 6 Jul 2019 09:50:38 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Sat, 06 Jul 2019 09:50:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=1427O EQdGF6/z5C6ppd28pwc3GLzeZrukwfG91E/CdU=; b=Y7X6FG8tObfpWDoCSkQx9 YopAzawLBiFSawRZ708G4uLMD8g0zZ0OrBA/E3iQ/K6mvgvijb88ondwk+7Rt7hm xJZNOId4MkWqy0xUY1IzMhY4TtNVr9ui7JajJNmpuVBZSa2toSRIBelqm/LfIYo3 CcbsbBRDLf1y4bCSFbLRGv340lK/yRUu5E5l3q8b6syFRcPy1z8HZZiNhka2M9kA iHNenov9YV55qyguNJiUODTPUKaalSYF1B0BA8fUG0ePuthNqAwiyLf2iaaWrJRw VimNy0XT7FXOPk5HAccHF1jLnhsuXuNTYEL1Z05syZ0S4mXLYkgS1AS+3MUXN1uL Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=1427OEQdGF6/z5C6ppd28pwc3GLzeZrukwfG91E/C dU=; b=yW42+t7BeBvQzR1VMHJ8W9KvhVtK4M4iEW8sD7Sh52DYQKhzOZfxuGUxd YsfHJwvaNzaGbERbolEG4/KFhuG6O3aO5Ri2VdasfyciB9hfRxL1c9urMTv5ZILV 8VyIH20cGUb3XqfppYOA7Z9ZTVmN0C/mZ8IOwxVgkYmxw9hLa02kDol/L1ue2HDb BmVT/2s4AoSdLjudzwzcLAkk/8uyJNtZljJsU9j6Olvqw+vNExR/lT+PUP9vLlSj 74sKFXHjcyC6UOsPRzGljj7cPQOnxpML9rP7/qPSjwZ1CFysX30hAgUAylP8nAWJ IHWX6ak3X9bo0Er3OWgxOqB2e7I1w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrfeeigdeilecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucfrrghrrghmpehmrghilhhfrhhomheptg grfieshhgvrghpihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 328BC3C00A1; Sat, 6 Jul 2019 09:50:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <1f4642f7-a976-45d1-a297-997fb39fe7ad@www.fastmail.com> In-Reply-To: References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <1CCCFE4D-9F75-432A-9839-A75C94C6E170@bangj.com> <31B20480-C368-46FE-8D5E-654584358EF2@fugue.com> Date: Sat, 06 Jul 2019 06:50:36 -0700 From: "Christopher Wood" To: dnssd@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2019 13:50:41 -0000 On Fri, Jul 5, 2019, at 5:45 PM, David Schinazi wrote: >=20 > On Thu, Jul 4, 2019 at 9:52 AM Tom Pusateri wrote= : > >> On Jul 3, 2019, at 11:12 AM, Ted Lemon wrote: > >> And thanks for the advice about how to terminate TLS connections=E2= =80=94I had missed that nuance. Are TLS implementations actually able to= do this (to reject RST packets)? > >=20 > > This was actually a comment from David Schinazi (and a good one). I=E2= =80=99ve adjusted the working copy on github but there=E2=80=99s still o= ne section I=E2=80=99m wrestling with regarding TCP RST. >=20 > On most operating systems today, TCP is in the kernel and TLS is in=20= > user-space, so most implementations of TLS over TCP do not have the=20= > ability to discard TCP RSTs that were injected by attackers. However,=20= > the TLS close_notify alert allows endpoints to be able to tell the=20 > difference between a connection that was closed gracefully by the peer= =20 > and one that was forcefully terminated (possibly by an attacker). So=20= > upon receipt of a TCP RST without prior TLS close_notify, the=20 > connection will die, but the application will know that the latest=20 > message could have been truncated halfway through transmission and=20 > should therefore be discarded. +1 (though some applications might choose to use the partial message) From nobody Mon Jul 8 15:54:06 2019 Return-Path: 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 C853712037D; Mon, 8 Jul 2019 15:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 V3vUZYTt_Uyx; Mon, 8 Jul 2019 15:53:53 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B400120320; Mon, 8 Jul 2019 15:53:53 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x68Mptwq005298; Mon, 8 Jul 2019 15:53:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=d40JHvGkWL2LZ/CdN2qMzMbPSMWWWzfhLUc8IUmo/X0=; b=Zi9MpvElnsTmMXmEpg+DQSj+7qfUZG4wWaxAD9mYcrDYWv9RLz5ieS7/EAlrI3zvcQ7r inajYdUEWxshgM3wJfYdCKenUdHTZ6zH0mLXP/rjVuipIW9iyjZlLfCj0mQuHvwlqUI/ kT0eVb7CP9CSr7WGCvrRJAdtxCW7jE+tFS1s3WCstVG79EA1zS0MZi+f4F5knXRnwkzb +sBdhR1qTYfrPxxMHsatJlqqY38MI71MSOvIShC4c/s+eKeQYrg/qiaikexLLq096k6Z oNiVc7hScsNJwPCRwZXgPUauCCkYBh4C7nKWLwqDfsECxB4vcpA3mfsm8nMvx98Ij53A Xw== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2tkbvk4pfv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 08 Jul 2019 15:53:50 -0700 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PUC00KSFI9P8J80@mr2-mtap-s03.rno.apple.com>; Mon, 08 Jul 2019 15:53:50 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PUC00D00HEDE100@nwk-mmpp-sz09.apple.com>; Mon, 08 Jul 2019 15:53:50 -0700 (PDT) X-Va-A: X-Va-T-CD: 10a534a1686abdccb129dd18c18ba03f X-Va-E-CD: 3c579badc8061719d024feec5a8178fb X-Va-R-CD: dac62b87d893430a0308504ef8763cad X-Va-CD: 0 X-Va-ID: ff7f07e5-ca13-400e-94d9-ecf5596c31e7 X-V-A: X-V-T-CD: 10a534a1686abdccb129dd18c18ba03f X-V-E-CD: 3c579badc8061719d024feec5a8178fb X-V-R-CD: dac62b87d893430a0308504ef8763cad X-V-CD: 0 X-V-ID: 97fc82e5-31cc-416e-85fb-ec65b8ce3980 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-08_09:,, signatures=0 Received: from [17.192.139.245] (unknown [17.192.139.245]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PUC00HF5I996T50@nwk-mmpp-sz09.apple.com>; Mon, 08 Jul 2019 15:53:33 -0700 (PDT) Sender: cheshire@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Stuart Cheshire In-reply-to: Date: Mon, 08 Jul 2019 15:53:32 -0700 Cc: Tom Pusateri , Robert Sparks , draft-ietf-dnssd-push.all@ietf.org, DNSSD , Eric Rescorla Content-transfer-encoding: quoted-printable Message-id: <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> To: David Schinazi X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-08_09:, , signatures=0 Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 22:54:04 -0000 On 2 Jul 2019, at 12:36, David Schinazi = wrote: > Hi Tom, >=20 > If the protocol is restricted to TLS over TCP, it should send a TLS = close_notify, not a TCP RST. > TLS close_notify is cryptographically guaranteed to originate from the = peer, > whereas TCP RST can be injected by an on-path entity to cause = truncation attacks. In TCP we use FIN for a graceful close, and RST for an abortive close. = The former is normal operation; the latter means your code has a bug you = need to fix. Is there an appropriate equivalent in TLS? It would be good to = differentiate normal operation from a fatal protocol error that causes a = forcible termination. I see in the TLS 1.3 spec, RFC 8446, Section 6.2. =E2=80=9CError = Alerts=E2=80=9D says: Whenever an implementation encounters a fatal error condition, it SHOULD send an appropriate fatal alert and MUST close the connection without sending or receiving any additional data. Are any of these error alerts appropriate to perform this abortive = disconnect, like perhaps the decode_error code? decode_error: A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This alert is used for errors where the message does not conform to the formal protocol syntax. This alert should never be observed in communication between proper implementations, except when messages were corrupted in the network. Or are these TLS error alerts reserved for TLS-layer error conditions? Stuart Cheshire From nobody Mon Jul 8 16:05:51 2019 Return-Path: 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 419D5120384; Mon, 8 Jul 2019 16:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YbAOsi1SArb0; Mon, 8 Jul 2019 16:05:32 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 B046C120354; Mon, 8 Jul 2019 16:05:31 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id m23so17589342lje.12; Mon, 08 Jul 2019 16:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y6EH5ujmCSeGDYZ3ylnNPCo1M9YGamS7J3jcwalt3no=; b=tCGS+JCz8q2Q2KbQs/CDFxG2pE2QpzoJprqV7UGV1iXERBXReakhyxVw3lruh5MnSV 9R8XSmVC0BYhcIJHusT8YbkN+pI7Xx42Sc3YZEhhpDLk/9/+ev93VwK0TG9B61QTjhd0 Ff/oxkao/QOdJONd80bTKKniBHOOWkuYxerKeon1VZ4o8ckPCFoYa+ZYY3eq4eVIc+cy umdkGLQE0bDUMP8hntCYRKzNLH6tdHvVcEPZEEsS4EG+MUcP2mRUkRMk8pDLz4b7JD21 xIDpA13rweCF0f7SkH8eYw0ECERemfjeRlqBTJF4dMTkpni7P8SptjU2l0eFTkUSbZYM oFZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y6EH5ujmCSeGDYZ3ylnNPCo1M9YGamS7J3jcwalt3no=; b=dWJBlZjmSPs2N46cIL9TcctA8VhPpNTqgswbmOSNjx3D3SPkcCeWXTFMdtzsO6tNj6 CRXHqVnGHXyc2toykrBEZYnHsV+d+fzCrU0bz2UOR4/OB0yA2DBYGknMfj33aJZq3DRW TDSbCYOs22M6V5qkVFrEJOkPA95tjUTFGIGtpjVhGjT3EYiKYC3RlU2JMirmxfDjLVLj EPWhgv6lrToA1Ixuj6H07KoB36ECahWJDKPa3nq/GKEfxy66Xi/ub3Ju8dV3ZkrjrkC9 0e9zQVe6RWyuLmTpThLwDcffn8qWaAM6Zimn80AWjJDW+Zv43WA7aT+KMpOqEf2ZQRG0 ft1g== X-Gm-Message-State: APjAAAUA+zQ3ycCKg0nQw0UJzI3kUuZXoM4SMckDaj4OkfsUovRMrt9M oJdFvjp+36hRMHZB+MdZ7Z6gnOZRXR+0p+wBugw= X-Google-Smtp-Source: APXvYqwVgRplkP3mtRIoqiH47WsPRLCyNtxt6kXXJrQesFnwWgn5z4MPtXUf/rBr4YkYAgrzWB3Zmg+lw8nKu/wLF+4= X-Received: by 2002:a2e:2c14:: with SMTP id s20mr11653099ljs.54.1562627129826; Mon, 08 Jul 2019 16:05:29 -0700 (PDT) MIME-Version: 1.0 References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> In-Reply-To: <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> From: David Schinazi Date: Mon, 8 Jul 2019 16:05:18 -0700 Message-ID: To: Stuart Cheshire Cc: Tom Pusateri , Robert Sparks , draft-ietf-dnssd-push.all@ietf.org, DNSSD , Eric Rescorla Content-Type: multipart/alternative; boundary="000000000000fd6333058d337a80" Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 23:05:41 -0000 --000000000000fd6333058d337a80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In general the "TLS Alerts" error codes are specific to the operation of TLS itself, not the application running over TLS. If you want to send a graceful close, the tool of choice is close_notify. If you detect an unrecoverable error and want to abort the connection, I see two options: (1) forcibly terminate the connection at the DNS layer by sending a DNS error message followed by a TLS close_notify (2) forcibly terminate the connection at the TCP layer by sending a RST As a client sending, I don't see much value in (1) since all the server can do in either case is free the resources associated with this connection. As a server sending, I suspect (1) is best unless you were unable to parse anything in which case (2) makes sense. David On Mon, Jul 8, 2019 at 3:53 PM Stuart Cheshire wrote: > On 2 Jul 2019, at 12:36, David Schinazi wrote: > > > Hi Tom, > > > > If the protocol is restricted to TLS over TCP, it should send a TLS > close_notify, not a TCP RST. > > TLS close_notify is cryptographically guaranteed to originate from the > peer, > > whereas TCP RST can be injected by an on-path entity to cause truncatio= n > attacks. > > In TCP we use FIN for a graceful close, and RST for an abortive close. Th= e > former is normal operation; the latter means your code has a bug you need > to fix. > > Is there an appropriate equivalent in TLS? It would be good to > differentiate normal operation from a fatal protocol error that causes a > forcible termination. > > I see in the TLS 1.3 spec, RFC 8446, Section 6.2. =E2=80=9CError Alerts= =E2=80=9D says: > > Whenever an implementation encounters a fatal error condition, it > SHOULD send an appropriate fatal alert and MUST close the connection > without sending or receiving any additional data. > > > > Are any of these error alerts appropriate to perform this abortive > disconnect, like perhaps the decode_error code? > > decode_error: A message could not be decoded because some field was > out of the specified range or the length of the message was > incorrect. This alert is used for errors where the message does > not conform to the formal protocol syntax. This alert should > never be observed in communication between proper implementations, > except when messages were corrupted in the network. > > Or are these TLS error alerts reserved for TLS-layer error conditions? > > Stuart Cheshire > > --000000000000fd6333058d337a80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In general the "TLS Alerts" error codes are spec= ific to the operation of TLS itself, not the application running over TLS.<= div>
If you want to send a graceful close, the tool of choice= is close_notify.
If you detect an unrecoverable error and want t= o abort the connection, I see two options:
(1) forcibly terminate= the connection at the DNS layer by sending a DNS error message followed by= a TLS close_notify
(2) forcibly terminate the connection at the = TCP layer by sending a RST

As a client sending, I = don't see much value in (1) since all the server can do in either case = is free the resources associated with this connection.
As a serve= r sending, I suspect (1) is best unless you were unable to parse anything i= n which case (2) makes sense.

David
On Mon, J= ul 8, 2019 at 3:53 PM Stuart Cheshire <cheshire@apple.com> wrote:
On 2 Jul 2019, at 12:36, David Schinazi <dschinazi.ietf@gmail= .com> wrote:

> Hi Tom,
>
> If the protocol is restricted to TLS over TCP, it should send a TLS cl= ose_notify, not a TCP RST.
> TLS close_notify is cryptographically guaranteed to originate from the= peer,
> whereas TCP RST can be injected by an on-path entity to cause truncati= on attacks.

In TCP we use FIN for a graceful close, and RST for an abortive close. The = former is normal operation; the latter means your code has a bug you need t= o fix.

Is there an appropriate equivalent in TLS? It would be good to differentiat= e normal operation from a fatal protocol error that causes a forcible termi= nation.

I see in the TLS 1.3 spec, RFC 8446, Section 6.2. =E2=80=9CError Alerts=E2= =80=9D says:

=C2=A0 =C2=A0Whenever an implementation encounters a fatal error condition,= it
=C2=A0 =C2=A0SHOULD send an appropriate fatal alert and MUST close the conn= ection
=C2=A0 =C2=A0without sending or receiving any additional data.

<https://tools.ietf.org/html/rfc8446#section-6.2>

Are any of these error alerts appropriate to perform this abortive disconne= ct, like perhaps the decode_error code?

=C2=A0 =C2=A0decode_error:=C2=A0 A message could not be decoded because som= e field was
=C2=A0 =C2=A0 =C2=A0 out of the specified range or the length of the messag= e was
=C2=A0 =C2=A0 =C2=A0 incorrect.=C2=A0 This alert is used for errors where t= he message does
=C2=A0 =C2=A0 =C2=A0 not conform to the formal protocol syntax.=C2=A0 This = alert should
=C2=A0 =C2=A0 =C2=A0 never be observed in communication between proper impl= ementations,
=C2=A0 =C2=A0 =C2=A0 except when messages were corrupted in the network.
Or are these TLS error alerts reserved for TLS-layer error conditions?

Stuart Cheshire

--000000000000fd6333058d337a80-- From nobody Mon Jul 8 16:12:40 2019 Return-Path: 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 7F41E120364; Mon, 8 Jul 2019 16:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 bKSA6dCoXKBI; Mon, 8 Jul 2019 16:12:27 -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 7C95C120316; Mon, 8 Jul 2019 16:12:27 -0700 (PDT) Received: from [10.21.50.205] (mobile-166-170-58-254.mycingular.net [166.170.58.254]) (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 0452C342E7; Mon, 8 Jul 2019 19:12:26 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-6BC29C0C-975E-4D9A-9F31-DA2C83A4473E Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Mon, 8 Jul 2019 19:12:24 -0400 Cc: Stuart Cheshire , Robert Sparks , draft-ietf-dnssd-push.all@ietf.org, DNSSD , Eric Rescorla Content-Transfer-Encoding: 7bit Message-Id: <7F485F2D-C9C7-4530-98AB-2A7498EA2D4F@bangj.com> References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> To: David Schinazi Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 23:12:38 -0000 --Apple-Mail-6BC29C0C-975E-4D9A-9F31-DA2C83A4473E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If we detect a PUSH protocol error and don=E2=80=99t want the client to imme= diately reconnect and repeat the same error, we can send a retry delay TLV w= ith a long delay and then close gracefully with a TLS close_notify in lieu o= f a TCP RST.=20 Tom > On Jul 8, 2019, at 7:05 PM, David Schinazi wrot= e: >=20 > In general the "TLS Alerts" error codes are specific to the operation of T= LS itself, not the application running over TLS. >=20 > If you want to send a graceful close, the tool of choice is close_notify. > If you detect an unrecoverable error and want to abort the connection, I s= ee two options: > (1) forcibly terminate the connection at the DNS layer by sending a DNS er= ror message followed by a TLS close_notify > (2) forcibly terminate the connection at the TCP layer by sending a RST >=20 > As a client sending, I don't see much value in (1) since all the server ca= n do in either case is free the resources associated with this connection. > As a server sending, I suspect (1) is best unless you were unable to parse= anything in which case (2) makes sense. >=20 > David >=20 >> On Mon, Jul 8, 2019 at 3:53 PM Stuart Cheshire wrote= : >> On 2 Jul 2019, at 12:36, David Schinazi wrote:= >>=20 >> > Hi Tom, >> >=20 >> > If the protocol is restricted to TLS over TCP, it should send a TLS clo= se_notify, not a TCP RST. >> > TLS close_notify is cryptographically guaranteed to originate from the p= eer, >> > whereas TCP RST can be injected by an on-path entity to cause truncatio= n attacks. >>=20 >> In TCP we use FIN for a graceful close, and RST for an abortive close. Th= e former is normal operation; the latter means your code has a bug you need t= o fix. >>=20 >> Is there an appropriate equivalent in TLS? It would be good to differenti= ate normal operation from a fatal protocol error that causes a forcible term= ination. >>=20 >> I see in the TLS 1.3 spec, RFC 8446, Section 6.2. =E2=80=9CError Alerts=E2= =80=9D says: >>=20 >> Whenever an implementation encounters a fatal error condition, it >> SHOULD send an appropriate fatal alert and MUST close the connection >> without sending or receiving any additional data. >>=20 >> >>=20 >> Are any of these error alerts appropriate to perform this abortive discon= nect, like perhaps the decode_error code? >>=20 >> decode_error: A message could not be decoded because some field was >> out of the specified range or the length of the message was >> incorrect. This alert is used for errors where the message does >> not conform to the formal protocol syntax. This alert should >> never be observed in communication between proper implementations, >> except when messages were corrupted in the network. >>=20 >> Or are these TLS error alerts reserved for TLS-layer error conditions? >>=20 >> Stuart Cheshire >>=20 --Apple-Mail-6BC29C0C-975E-4D9A-9F31-DA2C83A4473E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If w= e detect a PUSH protocol error and don=E2=80=99t want the client to immediat= ely reconnect and repeat the same error, we can send a retry delay TLV with a= long delay and then close gracefully with a TLS close_notify in lieu of a T= CP RST. 

Tom

On Jul 8, 2019, at 7:05 PM, David Schinazi <dschinazi.ietf@gmail.com> wrote:
<= br>
In gene= ral the "TLS Alerts" error codes are specific to the operation of TLS itself= , not the application running over TLS.

If you want to se= nd a graceful close, the tool of choice is close_notify.
If you de= tect an unrecoverable error and want to abort the connection, I see two opti= ons:
(1) forcibly terminate the connection at the DNS layer by sen= ding a DNS error message followed by a TLS close_notify
(2) forcib= ly terminate the connection at the TCP layer by sending a RST

=
As a client sending, I don't see much value in (1) since all the s= erver can do in either case is free the resources associated with this conne= ction.
As a server sending, I suspect (1) is best unless you were u= nable to parse anything in which case (2) makes sense.

<= div>David

On Mon, Jul 8, 2019 at 3:53 PM Stuart Cheshire <cheshire@apple.com> wrote:
On 2 Jul 2019, at 12:36, David Sch= inazi <dsch= inazi.ietf@gmail.com> wrote:

> Hi Tom,
>
> If the protocol is restricted to TLS over TCP, it should send a TLS clo= se_notify, not a TCP RST.
> TLS close_notify is cryptographically guaranteed to originate from the p= eer,
> whereas TCP RST can be injected by an on-path entity to cause truncatio= n attacks.

In TCP we use FIN for a graceful close, and RST for an abortive close. The f= ormer is normal operation; the latter means your code has a bug you need to f= ix.

Is there an appropriate equivalent in TLS? It would be good to differentiate= normal operation from a fatal protocol error that causes a forcible termina= tion.

I see in the TLS 1.3 spec, RFC 8446, Section 6.2. =E2=80=9CError Alerts=E2=80= =9D says:

   Whenever an implementation encounters a fatal error condition, i= t
   SHOULD send an appropriate fatal alert and MUST close the conne= ction
   without sending or receiving any additional data.

<https://tools.ietf.org/html/rfc8446#section-6.2= >

Are any of these error alerts appropriate to perform this abortive disconnec= t, like perhaps the decode_error code?

   decode_error:  A message could not be decoded because some= field was
      out of the specified range or the length of the message= was
      incorrect.  This alert is used for errors where th= e message does
      not conform to the formal protocol syntax.  This a= lert should
      never be observed in communication between proper imple= mentations,
      except when messages were corrupted in the network.
=
Or are these TLS error alerts reserved for TLS-layer error conditions?

Stuart Cheshire

= --Apple-Mail-6BC29C0C-975E-4D9A-9F31-DA2C83A4473E-- From nobody Mon Jul 8 16:58:11 2019 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 203E31203C0; Mon, 8 Jul 2019 16:58:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <156263028107.1025.16633536435502006684@ietfa.amsl.com> Date: Mon, 08 Jul 2019 16:58:01 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-22.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 23:58:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-22.txt Pages : 39 Date : 2019-07-08 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-22 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-22 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-22 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 8 17:00:30 2019 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 328611203FA; Mon, 8 Jul 2019 17:00:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <156263040311.808.7751959596411629710@ietfa.amsl.com> Date: Mon, 08 Jul 2019 17:00:03 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-srp-02.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 00:00:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : Service Registration Protocol for DNS-Based Service Discovery Authors : Stuart Cheshire Ted Lemon Filename : draft-ietf-dnssd-srp-02.txt Pages : 23 Date : 2019-07-08 Abstract: The Service Registration Protocol for DNS-Based Service Discovery uses the standard DNS Update mechanism to enable DNS-Based Service Discovery using only unicast packets. This makes it possible to deploy DNS Service Discovery without multicast, which greatly improves scalability and improves performance on networks where multicast service is not an optimal choice, particularly 802.11 (Wi-Fi) and 802.15.4 (IoT) networks. DNS-SD Service registration uses public keys and SIG(0) to allow services to defend their registrations against attack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-srp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-srp-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-srp-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-srp-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 9 09:41:14 2019 Return-Path: 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 CEEF61202D0 for ; Tue, 9 Jul 2019 09:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 OOQZuLI2U5mW for ; Tue, 9 Jul 2019 09:41:05 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 4E0A71206A2 for ; Tue, 9 Jul 2019 09:41:05 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id g18so16522397qkl.3 for ; Tue, 09 Jul 2019 09:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AOi19T3dvmct+CoPa3PWrdkKZ9ATmrnSoAkTnSATOiI=; b=N9jpYfscjjXgwI8hUhG3VWBfP6ScI44mHyV6D7LEQIgDIAXzjwbSLi3SFhcX4kiq45 vGWsa1uoqXBzn+H7hFeqh9Z6r6jK3kbBEVlxww3O9hY7h09bL3ZDhXzIfXsfJ9jRnb2k AgIlvYglPgy1JZRj6YLi3WreNXI9XnTVxPBh8l84OtMZO/XVUKA4QNVjs1o2uF0hTiUM FthYq0wZgj4QLbXT79OUxu5uWXROFokbaub4hzjLHfpzAw9BIQDkA3T+CKTZq76ZmKNh O4G4iiE5ziQuHTMAUY+cd01japw5Sr31oFOKLIJLbvvz4jEhdS/IFPQaEX9O4FkoZoSr xq6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AOi19T3dvmct+CoPa3PWrdkKZ9ATmrnSoAkTnSATOiI=; b=EbzKoUZxu8mN0e2btGNpEKJYvnnuQxY+8wVHikCM6qVHuXuHFp5/DKLLyS0+f4Yzr6 gtqQf1erwAe0ivJst3JvNRYc7h+e8SdszyHJwT+0dMegpRAKR8X4+6oLXD32VrBW+dHv 3GrWTShTV4D1ILs5jmjXDzcAMoed0e+u5zq+j7Egd4Z+qe6FuUXeiYU9JT8QUr/WF5Pk fKIf4eX1wCmm2GMF2Q0PShHW6UWzA9kYop/HOlWzVCLu/llkW+dZf4fPEYe4ZxvhoS/Z afNU3i2gVNgnnhAufaOoqZa/rdFoVu5MigEjKtSTp7ohsQypXTL03+W2w7NbXqCDTlQ5 MLcg== X-Gm-Message-State: APjAAAX4LGaOhubvlxZqnddLxi/uPr+XNHxrATRdpg+bZl1sm7eu322e iwy26R9COTyN9Zu2kd1WHN9rpA== X-Google-Smtp-Source: APXvYqwVvD+XlphqH7HlPG7ZwBTVe1onghrxOxpeTb2jRQtqPTK4TtLIVAL60xmy8AWj+oT53xqvAQ== X-Received: by 2002:a37:7a84:: with SMTP id v126mr18657462qkc.439.1562690464464; Tue, 09 Jul 2019 09:41:04 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:1dd2:b78f:3be7:8c79? ([2001:470:c1a2:1:1dd2:b78f:3be7:8c79]) by smtp.gmail.com with ESMTPSA id b5sm6273206qkk.78.2019.07.09.09.41.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 09:41:04 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8D64DB6E-828D-4008-ADAD-73154444E82D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 9 Jul 2019 12:41:02 -0400 In-Reply-To: Cc: DNSSD , dnssd-chairs@ietf.org To: David Schinazi References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] Call for agenda items: DNSSD at IETF 105 in Montreal 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 16:41:13 -0000 --Apple-Mail=_8D64DB6E-828D-4008-ADAD-73154444E82D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I could talk about any of the following things: The DNSSD-SRP draft status (draft-ietf-dnssd-srp) What updates have happened What to do about Tom=E2=80=99s comments on the DNSSD-SRP draft that I = haven=E2=80=99t addressed What to do with the draft generally Implementation report DNSSD-Push implementation report (draft-ietf-dnssd-hybrid-proxy) DNSSD Relay implementation status (draft-ietf-dnssd-mdns-relay) I could also demo DNSSD Push if there=E2=80=99s interest. The implementation reports should take on the order of five minutes. = The demo would probably take another five. The draft status update = shouldn=E2=80=99t take more than 10. Stuart or one of the other = authors might additionally want to talk about DNSSD Push status, since = there=E2=80=99s been activity on that in IETF last call, but I=E2=80=99m = not an author, so I=E2=80=99m not proposing to do that. --Apple-Mail=_8D64DB6E-828D-4008-ADAD-73154444E82D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = could talk about any of the following things:

  • The DNSSD-SRP draft status (draft-ietf-dnssd-srp)
    • What updates have happened
    • What to do about Tom=E2=80=99s comments on the DNSSD-SRP = draft that I haven=E2=80=99t addressed
    • What to do = with the draft generally
    • Implementation = report
  • DNSSD-Push implementation report = (draft-ietf-dnssd-hybrid-proxy)
  • DNSSD Relay = implementation status (draft-ietf-dnssd-mdns-relay)

I could also demo DNSSD = Push if there=E2=80=99s interest.

The implementation reports should take = on the order of five minutes.   The demo would probably take = another five.   The draft status update shouldn=E2=80=99t take more = than 10.   Stuart or one of the other authors might additionally = want to talk about DNSSD Push status, since there=E2=80=99s been = activity on that in IETF last call, but I=E2=80=99m not an author, so = I=E2=80=99m not proposing to do that.

= --Apple-Mail=_8D64DB6E-828D-4008-ADAD-73154444E82D-- From nobody Tue Jul 9 18:52:22 2019 Return-Path: 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 33565120090; Tue, 9 Jul 2019 18:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 mtTv7htqyojv; Tue, 9 Jul 2019 18:52:19 -0700 (PDT) Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A15120048; Tue, 9 Jul 2019 18:52:18 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6A1qGq2037807; Tue, 9 Jul 2019 18:52:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=X3ksKsIjI9D2B1m8hyDUtboMl7IEu0wxxj86G5JiAk8=; b=XRrCgaumCLd0raXvXbDZTfzQOLEIHdmiePmJgr/teFetewinFEpH1RdO3Ezl/y0LRzZW PgyASChxoMOOiEuRRseMneUY5a+FQeMlmmYW39ZbGF5Ax7aYjZJGGo2XL2ybJUMdpdg+ koaMYjLcA3wgljuCi0uFfbGD5VY74V2zXZEguH4igHZ5iEmgh2hw1akvEdSRdetNAbbJ vYHzgDh31Mhu1l0mgmcJFqktcVtBD2rI2ohXwPEbZJ6PSkwuCNRtjI1sDbQeCiYrxwdo snrAO6TqVNWAhOVDS1zyD1rYB2opMLW01dVwS0LKOfbxkqXzF8k0bKT4Zd+iCgjGcRlG Pg== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2tjtmxxybj-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 09 Jul 2019 18:52:16 -0700 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PUE00KPFL6UUD20@ma1-mtap-s03.corp.apple.com>; Tue, 09 Jul 2019 18:52:09 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PUE00A00L6P2D00@nwk-mmpp-sz09.apple.com>; Tue, 09 Jul 2019 18:52:08 -0700 (PDT) X-Va-A: X-Va-T-CD: 10a534a1686abdccb129dd18c18ba03f X-Va-E-CD: d61f1c9f7f046d6e2d5001925d2c5b8d X-Va-R-CD: b199db9bad3719ee7681a84e2553ae71 X-Va-CD: 0 X-Va-ID: d3afdcf0-dace-4dfc-beef-0026a556843a X-V-A: X-V-T-CD: 10a534a1686abdccb129dd18c18ba03f X-V-E-CD: d61f1c9f7f046d6e2d5001925d2c5b8d X-V-R-CD: b199db9bad3719ee7681a84e2553ae71 X-V-CD: 0 X-V-ID: c9f4e471-ee8c-4a90-8917-3d1f41c15032 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-10_01:,, signatures=0 Received: from [17.192.139.245] (unknown [17.192.139.245]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PUE00C4XL4RHV60@nwk-mmpp-sz09.apple.com>; Tue, 09 Jul 2019 18:50:51 -0700 (PDT) Sender: cheshire@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Stuart Cheshire In-reply-to: Date: Tue, 09 Jul 2019 18:50:50 -0700 Cc: DNSSD , dnssd-chairs Content-transfer-encoding: quoted-printable Message-id: References: To: David Schinazi X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-10_01:, , signatures=0 Archived-At: Subject: Re: [dnssd] Call for agenda items: DNSSD at IETF 105 in Montreal 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 01:52:21 -0000 On 2 Jul 2019, at 17:07, David Schinazi = wrote: > Hello everyone, >=20 > DNSSD has been scheduled on Thursday, 2019-07-25 at 13:30-15:30 EDT. >=20 > If you would like to present, please reply to this thread, > or email with: > - title of presentation > - related draft(s) if applicable > - expected duration > - name of presenter > Please also let us know if you will be presenting remotely > or have any specific requests or questions. Here are some items for discussion: Last Call feedback on draft-ietf-dnssd-push We have two hot topics to resolve: 1. TLS close_notify vs. TCP reset 2. Allowing subscribe request in TLS early data? Estimate 20 minutes As Ted Lemon noted earlier today: 1. Implementation updates on draft-ietf-dnssd-hybrid, = draft-ietf-dnssd-mdns-relay, including possibly a live demo. 2. Status update on draft-ietf-dnssd-srp Finally, an important thing: Discussing the future of the DNSSD Working = Group. 1. Draft-ietf-dnssd-srp is important for efficient reliable service = discovery on mesh networks, such as Thread wireless home automation = networks, and multi-link routed home networks such as envisioned by = Homenet. Is there sufficient energy to pursue this work in the IETF, or = will it end up moving somewhere else, like the Thread Group? 2. Privacy-respecting device and service discovery remains a very = important topic, but in the past we struggled to find implementers = creating real products that needed the privacy mechanisms we were = considering. Is that still true? With increasing public awareness of the = importance of privacy, we may see renewed interest in this area. It = would be a pity to give up on this work just as its importance is being = recognized. Stuart Cheshire From nobody Tue Jul 9 19:23:04 2019 Return-Path: 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 3A0991200C5; Tue, 9 Jul 2019 19:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 1-HtlVy5-etV; Tue, 9 Jul 2019 19:23:00 -0700 (PDT) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9581200CD; Tue, 9 Jul 2019 19:23:00 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6A2M7IX013899; Tue, 9 Jul 2019 19:22:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=0OVvZBAjCPSyQyynzhGkqjpprBpElVWdCNA2uWLdOCM=; b=Ld3tUq/GUw1GqmvNZyrfMNo63ptdKqHuRjM5zJEpthEKTmRjawbcWPWmyrf61ExL+oJ5 SS8HTvdkUo/6ilpLuEou9n2rzQS6VkbFRHlL8u7a/ufRB+vR3xsNdkgP66UzbnkJ0Qcx idCyKC97f2KupemHpDB2qJjgNUSUWEh3G46+3vkE9Eu1E1QG1AthQZIzmkchmb/lTshX BmoibhEXo5woXOwV48S/KbcR0c0MkdQmdLvuxntg2GfhrIL+/aCj2J3aAWsmt69DUKBn +dQneEbDRicnE8ThRaYRUiRs9zsSj+TOA3eVcBoXz+27ce7l9tJUFB6xUKuVY/mgI3x1 1A== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2tjtk32gxs-11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 09 Jul 2019 19:22:57 -0700 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PUE008SHMM4FT20@ma1-mtap-s03.corp.apple.com>; Tue, 09 Jul 2019 19:22:54 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz09.apple.com by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PUE00B00MJROS00@nwk-mmpp-sz09.apple.com>; Tue, 09 Jul 2019 19:22:53 -0700 (PDT) X-Va-A: X-Va-T-CD: 10a534a1686abdccb129dd18c18ba03f X-Va-E-CD: 3c579badc8061719d024feec5a8178fb X-Va-R-CD: dac62b87d893430a0308504ef8763cad X-Va-CD: 0 X-Va-ID: 6d73c46c-6854-4c62-8e19-e490f1451c36 X-V-A: X-V-T-CD: 10a534a1686abdccb129dd18c18ba03f X-V-E-CD: 3c579badc8061719d024feec5a8178fb X-V-R-CD: dac62b87d893430a0308504ef8763cad X-V-CD: 0 X-V-ID: ff402b2a-03aa-409d-ae5f-d0ade04c5a6f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-10_01:,, signatures=0 Received: from [17.192.139.245] (unknown [17.192.139.245]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PUE00CG9MM3HV70@nwk-mmpp-sz09.apple.com>; Tue, 09 Jul 2019 19:22:52 -0700 (PDT) Sender: cheshire@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Stuart Cheshire In-reply-to: Date: Tue, 09 Jul 2019 19:22:50 -0700 Cc: Tom Pusateri , Robert Sparks , draft-ietf-dnssd-push.all@ietf.org, DNSSD , Eric Rescorla Content-transfer-encoding: quoted-printable Message-id: References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> To: David Schinazi X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-10_01:, , signatures=0 Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 02:23:03 -0000 On 8 Jul 2019, at 16:05, David Schinazi = wrote: > In general the "TLS Alerts" error codes are specific to the operation = of TLS itself, not the application running over TLS. >=20 > If you want to send a graceful close, the tool of choice is = close_notify. > If you detect an unrecoverable error and want to abort the connection, = I see two options: > (1) forcibly terminate the connection at the DNS layer by sending a = DNS error message followed by a TLS close_notify > (2) forcibly terminate the connection at the TCP layer by sending a = RST >=20 > As a client sending, I don't see much value in (1) since all the = server can do in either case is free the resources associated with this = connection. > As a server sending, I suspect (1) is best unless you were unable to = parse anything in which case (2) makes sense. This is a great candidate for some serious discussion in Montr=C3=A9al. The draft *used* to say to respond to fatal errors by forcibly aborting = the connection with a TCP RST. This is consistent with RFC 8490, DNS = Stateful Operations, the underlying technology used by = draft-ietf-dnssd-push. I believe it was actually you who suggested using TLS close_notify: > From: David Schinazi > Subject: Re: [dnssd] Genart last call review of = draft-ietf-dnssd-push-20 > Date: 2 July 2019 at 12:36:09 PDT > To: Tom Pusateri > Cc: Robert Sparks , = draft-ietf-dnssd-push.all@ietf.org, DNSSD > Resent-From: alias-bounces@ietf.org > Resent-To: pusateri@bangj.com, cheshire@apple.com, = dschinazi.ietf@gmail.com, bs7652@att.com, evyncke@cisco.com, = suresh@kaloom.com, Tim Wicinski , tjw.ietf@gmail.com >=20 > Hi Tom, >=20 > If the protocol is restricted to TLS over TCP, it should send a TLS = close_notify, not a TCP RST. > TLS close_notify is cryptographically guaranteed to originate from the = peer, > whereas TCP RST can be injected by an on-path entity to cause = truncation attacks. >=20 > Thanks, > David I suspect we have a miscommunication going on here. Robert Sparks, in his Genart review, said: > Page 23, top of page: Since section 4 restricts this protocol to TLS = over TCP, > the "(or equivalent for other protocols)" phrase should be removed. This is a fine observation. You then suggested changing TCP RST to TLS close_notify, not realizing = (a) this is only for fatal errors, and (b) the precedent already set by = RFC 8490. We have in fact updated the document, but I think this was too hasty, = and we should revert it back to the way it was before. If not, we at least need to have a thorough DNSSD Working Group = discussion about this before making a last-minute change to the = protocol. Stuart Cheshire From nobody Wed Jul 10 10:33:18 2019 Return-Path: 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 EA5CE1204EB; Wed, 10 Jul 2019 10:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jjnohVCqRVQI; Wed, 10 Jul 2019 10:33:11 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 8ECF812062C; Wed, 10 Jul 2019 10:33:06 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id k18so2894906ljc.11; Wed, 10 Jul 2019 10:33:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WBq5uGIhxyRUOu84AWADhuN2oxaOD49KV5y6ZDHhd5E=; b=XgdBbjkAut4iuTO1vv/tLb1f5xKILkNhu1CcBSr/NjQ2hu/u40jgcR4G73SgvHGaWo X+RpkvZhLbjH6BjaNKVLDUECFm2UAIk4C8EjtW397yzBX38UP/eYynsEEHPS/Sn1JvgW h4yfdXpwOHqeY1mtGRslLaj3tAOcvMgKJBWZl6htMT17f+tpozZ8HwTOFiGFklFmq39L d+ThKIZranaREMeX/FOkTlCJPDkcWjPyhdZBV8iyC9+Zg3LM1q/7FBAhWhl8ljTq7RYm rXb7vZtyISf0EHSdyeBS7WSbNRUQeOJd2SZZnVThWJLz1BOmPzW8TdPY6rbbY5rQtOvR 3QEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WBq5uGIhxyRUOu84AWADhuN2oxaOD49KV5y6ZDHhd5E=; b=QrPp6c1nk6lvCID8cDokko62r/esyW4OKiU5FY/zwq2QzztQPFd02jcdqoAJryaIJv IU85MYMxybh8b/egmKYTlY+NCP2eA6MRAEc/0PLTIOA5yZzJARbRkoiER7cOqW+APeBI mbMLJSF50HLtLSSaJwEUPvQ3mwS3JPH7v+nnRqnEJVqPtA+k9AfjU9Xjs09po3NNUp77 VOlu2pKHlcLEs+2/QMj3ICAaNUaC8gwlVfUARFeSFsL2XXPlrGjMaqpuWg1O4Ei8eQXQ okL9pkWusa45TaJZBCYNe1ql9rnY+Rp8GjjLOAtIdKTeozR0anD6uDEfiy+YhZdhlZOS QxQQ== X-Gm-Message-State: APjAAAXJTHzNY0QqDVMwjyVDpXqJCdmb+jaih7hHGLvZXr7/fdER6DBS w19R7XDiPESev7OvJmoy4vy9Dl0+lHNyhR6Wohc= X-Google-Smtp-Source: APXvYqz6bRWhJ1fy1qncXiiow/occ5vbdVpjDb0YmrfZBaRv/IJFwb0W3LWJS6CQPbSJNN47QHzya5PJqS/GHELaagQ= X-Received: by 2002:a2e:7f05:: with SMTP id a5mr15514166ljd.190.1562779984589; Wed, 10 Jul 2019 10:33:04 -0700 (PDT) MIME-Version: 1.0 References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> In-Reply-To: From: David Schinazi Date: Wed, 10 Jul 2019 10:32:53 -0700 Message-ID: To: Stuart Cheshire Cc: Tom Pusateri , Robert Sparks , draft-ietf-dnssd-push.all@ietf.org, DNSSD , Eric Rescorla Content-Type: multipart/alternative; boundary="000000000000d7f748058d571106" Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 17:33:16 -0000 --000000000000d7f748058d571106 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Stuart, that makes sense to me - I hadn't loaded the entire context back into memory... Apologies. Basically a "graceful" close should always use a TLS close_notify, but any catastrophic failure can use TCP RST. David On Tue, Jul 9, 2019 at 7:22 PM Stuart Cheshire wrote: > On 8 Jul 2019, at 16:05, David Schinazi wrote: > > > In general the "TLS Alerts" error codes are specific to the operation o= f > TLS itself, not the application running over TLS. > > > > If you want to send a graceful close, the tool of choice is close_notif= y. > > If you detect an unrecoverable error and want to abort the connection, = I > see two options: > > (1) forcibly terminate the connection at the DNS layer by sending a DNS > error message followed by a TLS close_notify > > (2) forcibly terminate the connection at the TCP layer by sending a RST > > > > As a client sending, I don't see much value in (1) since all the server > can do in either case is free the resources associated with this connecti= on. > > As a server sending, I suspect (1) is best unless you were unable to > parse anything in which case (2) makes sense. > > This is a great candidate for some serious discussion in Montr=C3=A9al. > > The draft *used* to say to respond to fatal errors by forcibly aborting > the connection with a TCP RST. This is consistent with RFC 8490, DNS > Stateful Operations, the underlying technology used by > draft-ietf-dnssd-push. > > I believe it was actually you who suggested using TLS close_notify: > > > From: David Schinazi > > Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-2= 0 > > Date: 2 July 2019 at 12:36:09 PDT > > To: Tom Pusateri > > Cc: Robert Sparks , > draft-ietf-dnssd-push.all@ietf.org, DNSSD > > Resent-From: alias-bounces@ietf.org > > Resent-To: pusateri@bangj.com, cheshire@apple.com, > dschinazi.ietf@gmail.com, bs7652@att.com, evyncke@cisco.com, > suresh@kaloom.com, Tim Wicinski , tjw.ietf@gmail.com > > > > Hi Tom, > > > > If the protocol is restricted to TLS over TCP, it should send a TLS > close_notify, not a TCP RST. > > TLS close_notify is cryptographically guaranteed to originate from the > peer, > > whereas TCP RST can be injected by an on-path entity to cause truncatio= n > attacks. > > > > Thanks, > > David > > I suspect we have a miscommunication going on here. > > Robert Sparks, in his Genart review, said: > > > Page 23, top of page: Since section 4 restricts this protocol to TLS > over TCP, > > the "(or equivalent for other protocols)" phrase should be removed. > > This is a fine observation. > > You then suggested changing TCP RST to TLS close_notify, not realizing (a= ) > this is only for fatal errors, and (b) the precedent already set by RFC > 8490. > > We have in fact updated the document, but I think this was too hasty, and > we should revert it back to the way it was before. > > If not, we at least need to have a thorough DNSSD Working Group discussio= n > about this before making a last-minute change to the protocol. > > Stuart Cheshire > > --000000000000d7f748058d571106 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Stuart, that makes sense to me - I hadn't loade= d the entire context back into memory... Apologies.

Basi= cally a "graceful" close should always use a TLS close_notify, bu= t any catastrophic failure can use TCP RST.

David<= /div>

On Tue, Jul 9, 2019 at 7:22 PM Stuart Cheshire <cheshire@apple.com> wrote:
On 8 Jul 2019, at 16:05, David Schinaz= i <dschina= zi.ietf@gmail.com> wrote:

> In general the "TLS Alerts" error codes are specific to the = operation of TLS itself, not the application running over TLS.
>
> If you want to send a graceful close, the tool of choice is close_noti= fy.
> If you detect an unrecoverable error and want to abort the connection,= I see two options:
> (1) forcibly terminate the connection at the DNS layer by sending a DN= S error message followed by a TLS close_notify
> (2) forcibly terminate the connection at the TCP layer by sending a RS= T
>
> As a client sending, I don't see much value in (1) since all the s= erver can do in either case is free the resources associated with this conn= ection.
> As a server sending, I suspect (1) is best unless you were unable to p= arse anything in which case (2) makes sense.

This is a great candidate for some serious discussion in Montr=C3=A9al.

The draft *used* to say to respond to fatal errors by forcibly aborting the= connection with a TCP RST. This is consistent with RFC 8490, DNS Stateful = Operations, the underlying technology used by draft-ietf-dnssd-push.

I believe it was actually you who suggested using TLS close_notify:

> From: David Schinazi <dschinazi.ietf@gmail.com>
> Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-= 20
> Date: 2 July 2019 at 12:36:09 PDT
> To: Tom Pusateri <pusateri@bangj.com>
> Cc: Robert Sparks <rjsparks@nostrum.com>, draft-ietf-dnssd-push.all@ietf.org, DNSSD <dnssd@iet= f.org>
> Resent-From: alias-bounces@ietf.org
> Resent-To: pus= ateri@bangj.com, cheshire@apple.com, dschinazi.ietf@gmail.com, bs7652@att.com, evyncke@cisco.com, suresh@kaloom.com, Tim Wicinski <tjw.ietf@gmail.com>, tjw.ietf@gmail.com=
>
> Hi Tom,
>
> If the protocol is restricted to TLS over TCP, it should send a TLS cl= ose_notify, not a TCP RST.
> TLS close_notify is cryptographically guaranteed to originate from the= peer,
> whereas TCP RST can be injected by an on-path entity to cause truncati= on attacks.
>
> Thanks,
> David

I suspect we have a miscommunication going on here.

Robert Sparks, in his Genart review, said:

> Page 23, top of page: Since section 4 restricts this protocol to TLS o= ver TCP,
> the "(or equivalent for other protocols)" phrase should be r= emoved.

This is a fine observation.

You then suggested changing TCP RST to TLS close_notify, not realizing (a) = this is only for fatal errors, and (b) the precedent already set by RFC 849= 0.

We have in fact updated the document, but I think this was too hasty, and w= e should revert it back to the way it was before.

If not, we at least need to have a thorough DNSSD Working Group discussion = about this before making a last-minute change to the protocol.

Stuart Cheshire

--000000000000d7f748058d571106-- From nobody Wed Jul 10 11:58:42 2019 Return-Path: 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 0F6851206B8; Wed, 10 Jul 2019 11:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Nv5u-nMSftbu; Wed, 10 Jul 2019 11:58:38 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 C3DF9120729; Wed, 10 Jul 2019 11:58:37 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id v24so3136782ljg.13; Wed, 10 Jul 2019 11:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pEvgd8d7YcQxamBuWS8PRyvcRuxmQaA54dzXwRFs0xw=; b=bYCFNs1CMeR86xin444NaKXugjCBhX1HV8S1jw5ehrbhioOGqObtKjcgfwIVv/37Xz +hr9DS+jyaNfclWzzKJfkjvtKNFRSdP7FYq6BIdQ4ubfmgvpARFKvWRjg0G8CEyPv+Fs 3/7MGk6wKHrUansnfUmJ1+vd+RXb1ztlQ1l3Cv2FGbcAEbyShaE59t+VUi1zvwLcbAJ8 wWEnbjYqhis6Dq+Ghf3EFHX/y0tMIQY8Qe09wH3mWru22y/oVT/kshVn0/hVM7BeLTby Z09tKfAa6khiAms+7qgZbB9FULsdMvOoCtJa7frWeSNz3+0168tOiW5F0cbAG34jAABP tpbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pEvgd8d7YcQxamBuWS8PRyvcRuxmQaA54dzXwRFs0xw=; b=MA3NvRo4C71/YQhcDuYdRIaprBtRZ47gOeIZVAkDLr0WDye2HikvVzO2WLziTMhVWf d1jZ4Y7yMdcxScoix/0zmV/A9bdRFnL3mUo1ACyFgAFy5QIp05i4+1f2zd7Y+GILoDon CV2/pwCUVXBk2vDty0YAaauKVXR2Ir5azhvQ+7Rbl35oDItL+ajIsi1v2nNYqcdx9slx GxPwwTkb6mpPJcb2/VEBN0Pp45t0dbkOow/srLBe4kTHgxiuMFfhagMie+XJ9Ypbqveh FIqu0T6kjnJYts0H/7Z6vvG8kPTM8qR97ovetWlqnRCitKUfnKSebNoHt0xjh5adXm/R Sd8Q== X-Gm-Message-State: APjAAAVIrYpNpuRBpW6xhC9kv/EEshOrI9lp8AYGyCYphuHTxd+4Qkli 8myZ0YtV10Zbg1Bxy+XHbVW/BSAw14MlamdVQVQ= X-Google-Smtp-Source: APXvYqxx3/yuEqY/bb6mL+qJboP5Es1iClyUOdiU978x27/O8hwWaD9yfL7uTYxupW+UVoxQxDofj7oJoUjGlRd+naE= X-Received: by 2002:a2e:89c8:: with SMTP id c8mr18717118ljk.70.1562785115905; Wed, 10 Jul 2019 11:58:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Schinazi Date: Wed, 10 Jul 2019 11:58:24 -0700 Message-ID: To: Stuart Cheshire Cc: DNSSD , dnssd-chairs Content-Type: multipart/alternative; boundary="000000000000b1a002058d584345" Archived-At: Subject: Re: [dnssd] Call for agenda items: DNSSD at IETF 105 in Montreal 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 18:58:40 -0000 --000000000000b1a002058d584345 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ted and Stuart. We've posted the preliminary agenda (see link or copy in email below) https://datatracker.ietf.org/doc/agenda-105-dnssd/ Feel free to bash the agenda. Thanks, Barbara and David =3D=3D=3D Introduction (Chairs - 15 minutes) Update on DNS Push (Stuart Cheshire - 15 minutes) draft-ietf-dnssd-push - TLS close_notify vs. TCP reset - Allowing subscribe request in TLS early data? - Implementation report and demo Service Registration (Ted Lemon, 15 minutes) draft-ietf-dnssd-srp - Latest updates to the draft - Tom Pusateri=E2=80=99s comments - Implementation report - Future of the draft Discovery Relay (Ted Lemon, 5 mins) draft-ietf-dnssd-mdns-relay - Implementation report - Future of the draft Future of the Working Group (Chairs - 30 minutes) Conclusion (Chairs - 5 minutes) =3D=3D=3D On Tue, Jul 9, 2019 at 6:52 PM Stuart Cheshire wrote: > On 2 Jul 2019, at 17:07, David Schinazi wrote: > > > Hello everyone, > > > > DNSSD has been scheduled on Thursday, 2019-07-25 at 13:30-15:30 EDT. > > > > If you would like to present, please reply to this thread, > > or email with: > > - title of presentation > > - related draft(s) if applicable > > - expected duration > > - name of presenter > > Please also let us know if you will be presenting remotely > > or have any specific requests or questions. > > Here are some items for discussion: > > Last Call feedback on draft-ietf-dnssd-push > We have two hot topics to resolve: > 1. TLS close_notify vs. TCP reset > 2. Allowing subscribe request in TLS early data? > Estimate 20 minutes > > As Ted Lemon noted earlier today: > 1. Implementation updates on draft-ietf-dnssd-hybrid, > draft-ietf-dnssd-mdns-relay, including possibly a live demo. > 2. Status update on draft-ietf-dnssd-srp > > Finally, an important thing: Discussing the future of the DNSSD Working > Group. > > 1. Draft-ietf-dnssd-srp is important for efficient reliable service > discovery on mesh networks, such as Thread wireless home automation > networks, and multi-link routed home networks such as envisioned by > Homenet. Is there sufficient energy to pursue this work in the IETF, or > will it end up moving somewhere else, like the Thread Group? > > 2. Privacy-respecting device and service discovery remains a very > important topic, but in the past we struggled to find implementers creati= ng > real products that needed the privacy mechanisms we were considering. Is > that still true? With increasing public awareness of the importance of > privacy, we may see renewed interest in this area. It would be a pity to > give up on this work just as its importance is being recognized. > > Stuart Cheshire > > --000000000000b1a002058d584345 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ted and Stuart.

We've posted= the preliminary agenda (see link or copy in email below)

Feel free to b= ash the agenda.

Thanks,
Barbara and Davi= d

=3D=3D=3D

Introduction = (Chairs - 15 minutes)

Update on DNS Push (Stuart Cheshire - 15 minut= es)
=C2=A0 =C2=A0 draft-ietf-dnssd-push
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -= TLS close_notify vs. TCP reset
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Allowing s= ubscribe request in TLS early data?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Implem= entation report and demo

Service Registration (Ted Lemon, 15 minutes= )
=C2=A0 =C2=A0 draft-ietf-dnssd-srp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - La= test updates to the draft
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Tom Pusateri=E2= =80=99s comments
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Implementation report
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 - Future of the draft

Discovery Relay (T= ed Lemon, 5 mins)
=C2=A0 =C2=A0 draft-ietf-dnssd-mdns-relay
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 - Implementation report
=C2=A0 =C2=A0 =C2=A0 =C2=A0= - Future of the draft

Future of the Working Group (Chairs - 30 minu= tes)

Conclusion (Chairs - 5 minutes)

= =3D=3D=3D

On Tue, Jul 9, 2019 at 6:52 PM Stuart Cheshire <cheshire@apple.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On 2 Jul 2019, at 17:07, D= avid Schinazi <dschinazi.ietf@gmail.com> wrote:

> Hello everyone,
>
> DNSSD has been scheduled on Thursday, 2019-07-25 at 13:30-15:30 EDT. >
> If you would like to present, please reply to this thread,
> or email <dnssd-chairs@ietf.org> with:
> - title of presentation
> - related draft(s) if applicable
> - expected duration
> - name of presenter
> Please also let us know if you will be presenting remotely
> or have any specific requests or questions.

Here are some items for discussion:

Last Call feedback on draft-ietf-dnssd-push
We have two hot topics to resolve:
1. TLS close_notify vs. TCP reset
2. Allowing subscribe request in TLS early data?
Estimate 20 minutes

As Ted Lemon noted earlier today:
1. Implementation updates on draft-ietf-dnssd-hybrid, draft-ietf-dnssd-mdns= -relay, including possibly a live demo.
2. Status update on draft-ietf-dnssd-srp

Finally, an important thing: Discussing the future of the DNSSD Working Gro= up.

1. Draft-ietf-dnssd-srp is important for efficient reliable service discove= ry on mesh networks, such as Thread wireless home automation networks, and = multi-link routed home networks such as envisioned by Homenet. Is there suf= ficient energy to pursue this work in the IETF, or will it end up moving so= mewhere else, like the Thread Group?

2. Privacy-respecting device and service discovery remains a very important= topic, but in the past we struggled to find implementers creating real pro= ducts that needed the privacy mechanisms we were considering. Is that still= true? With increasing public awareness of the importance of privacy, we ma= y see renewed interest in this area. It would be a pity to give up on this = work just as its importance is being recognized.

Stuart Cheshire

--000000000000b1a002058d584345-- From nobody Wed Jul 10 12:57:01 2019 Return-Path: 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 1F2FF120345; Wed, 10 Jul 2019 12:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 SripAzsTL7Fa; Wed, 10 Jul 2019 12:56:46 -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 BCD0712004D; Wed, 10 Jul 2019 12:56:46 -0700 (PDT) Received: from [172.16.25.117] (69-77-155-155.static.skybest.com [69.77.155.155]) (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 4CF7734610; Wed, 10 Jul 2019 15:56:45 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C5C431DE-1300-449A-BC12-F3B9CD5030CC Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPad Mail (16F203) In-Reply-To: Date: Wed, 10 Jul 2019 15:56:44 -0400 Cc: Stuart Cheshire , Robert Sparks , draft-ietf-dnssd-push.all@ietf.org, DNSSD , Eric Rescorla Content-Transfer-Encoding: 7bit Message-Id: <162B893B-00F6-448A-A4F1-3C10EA38BFE3@bangj.com> References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> To: David Schinazi Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 19:56:55 -0000 --Apple-Mail-C5C431DE-1300-449A-BC12-F3B9CD5030CC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I pointed out earlier that now that we have a RETRY DELAY TLV in DNS Statefu= l Operations, we can do better than just a TCP RST by not only signaling tha= t a fatal error occurred but also, inform the client not to try reconnecting= for a long time. This means we would always close with a TLS close_notify and if a fatal erro= r occurs, we set the RETRY DELAY. This would keep the broken client from con= necting right away again and then following the same error path. So we should discuss this more before restoring the old behavior. Tom > On Jul 10, 2019, at 1:32 PM, David Schinazi wro= te: >=20 > Thanks Stuart, that makes sense to me - I hadn't loaded the entire context= back into memory... Apologies. >=20 > Basically a "graceful" close should always use a TLS close_notify, but any= catastrophic failure can use TCP RST. >=20 > David >=20 >> On Tue, Jul 9, 2019 at 7:22 PM Stuart Cheshire wrote= : >> On 8 Jul 2019, at 16:05, David Schinazi wrote:= >>=20 >> > In general the "TLS Alerts" error codes are specific to the operation o= f TLS itself, not the application running over TLS. >> >=20 >> > If you want to send a graceful close, the tool of choice is close_notif= y. >> > If you detect an unrecoverable error and want to abort the connection, I= see two options: >> > (1) forcibly terminate the connection at the DNS layer by sending a DNS= error message followed by a TLS close_notify >> > (2) forcibly terminate the connection at the TCP layer by sending a RST= >> >=20 >> > As a client sending, I don't see much value in (1) since all the server= can do in either case is free the resources associated with this connection= . >> > As a server sending, I suspect (1) is best unless you were unable to pa= rse anything in which case (2) makes sense. >>=20 >> This is a great candidate for some serious discussion in Montr=C3=A9al. >>=20 >> The draft *used* to say to respond to fatal errors by forcibly aborting t= he connection with a TCP RST. This is consistent with RFC 8490, DNS Stateful= Operations, the underlying technology used by draft-ietf-dnssd-push. >>=20 >> I believe it was actually you who suggested using TLS close_notify: >>=20 >> > From: David Schinazi >> > Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-2= 0 >> > Date: 2 July 2019 at 12:36:09 PDT >> > To: Tom Pusateri >> > Cc: Robert Sparks , draft-ietf-dnssd-push.all@iet= f.org, DNSSD >> > Resent-From: alias-bounces@ietf.org >> > Resent-To: pusateri@bangj.com, cheshire@apple.com, dschinazi.ietf@gmail= .com, bs7652@att.com, evyncke@cisco.com, suresh@kaloom.com, Tim Wicinski , tjw.ietf@gmail.com >> >=20 >> > Hi Tom, >> >=20 >> > If the protocol is restricted to TLS over TCP, it should send a TLS clo= se_notify, not a TCP RST. >> > TLS close_notify is cryptographically guaranteed to originate from the p= eer, >> > whereas TCP RST can be injected by an on-path entity to cause truncatio= n attacks. >> >=20 >> > Thanks, >> > David >>=20 >> I suspect we have a miscommunication going on here. >>=20 >> Robert Sparks, in his Genart review, said: >>=20 >> > Page 23, top of page: Since section 4 restricts this protocol to TLS ov= er TCP, >> > the "(or equivalent for other protocols)" phrase should be removed. >>=20 >> This is a fine observation. >>=20 >> You then suggested changing TCP RST to TLS close_notify, not realizing (a= ) this is only for fatal errors, and (b) the precedent already set by RFC 84= 90. >>=20 >> We have in fact updated the document, but I think this was too hasty, and= we should revert it back to the way it was before. >>=20 >> If not, we at least need to have a thorough DNSSD Working Group discussio= n about this before making a last-minute change to the protocol. >>=20 >> Stuart Cheshire >>=20 --Apple-Mail-C5C431DE-1300-449A-BC12-F3B9CD5030CC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I p= ointed out earlier that now that we have a RETRY DELAY TLV in DNS Stateful O= perations, we can do better than just a TCP RST by not only signaling that a= fatal error occurred but also, inform the client not to try reconnecting fo= r a long time.

This means w= e would always close with a TLS close_notify and if a fatal error occurs, we= set the RETRY DELAY. This would keep the broken client from connecting righ= t away again and then following the same error path.
<= br>
So we should discuss this more before restoring th= e old behavior.

Tom

On Jul 10, 2019, at 1:32 PM, David Schinazi <dschinazi.ietf@gmail.com> wrote:
Thank= s Stuart, that makes sense to me - I hadn't loaded the entire context back i= nto memory... Apologies.

Basically a "graceful" close sho= uld always use a TLS close_notify, but any catastrophic failure can use TCP R= ST.

David

On Tue, Jul 9, 2019 at 7:22 PM Stuart= Cheshire <cheshire@apple.com&g= t; wrote:
On 8 Jul= 2019, at 16:05, David Schinazi <dschinazi.ietf@gmail.com> wrote:

> In general the "TLS Alerts" error codes are specific to the operation o= f TLS itself, not the application running over TLS.
>
> If you want to send a graceful close, the tool of choice is close_notif= y.
> If you detect an unrecoverable error and want to abort the connection, I= see two options:
> (1) forcibly terminate the connection at the DNS layer by sending a DNS= error message followed by a TLS close_notify
> (2) forcibly terminate the connection at the TCP layer by sending a RST=
>
> As a client sending, I don't see much value in (1) since all the server= can do in either case is free the resources associated with this connection= .
> As a server sending, I suspect (1) is best unless you were unable to pa= rse anything in which case (2) makes sense.

This is a great candidate for some serious discussion in Montr=C3=A9al.

The draft *used* to say to respond to fatal errors by forcibly aborting the c= onnection with a TCP RST. This is consistent with RFC 8490, DNS Stateful Ope= rations, the underlying technology used by draft-ietf-dnssd-push.

I believe it was actually you who suggested using TLS close_notify:

> From: David Schinazi <dschinazi.ietf@gmail.com>
> Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-2= 0
> Date: 2 July 2019 at 12:36:09 PDT
> To: Tom Pusateri <pusateri@bangj.com>
> Cc: Robert Sparks <rjsparks@nostrum.com>, draft-ietf-dnssd-push.all@ietf.org, D= NSSD <dnssd@ietf.org<= /a>>
> Resent-From: alias-bounces@ietf.org
> Resent-To: pusa= teri@bangj.com, = cheshire@apple.com, dschinazi.ietf@gmail.com, bs7652@att.com, evyncke@cisco.com, suresh@kaloom.com, Tim Wicinski <tjw.ietf@gmail.com>, tjw.ietf@gmail.com
>
> Hi Tom,
>
> If the protocol is restricted to TLS over TCP, it should send a TLS clo= se_notify, not a TCP RST.
> TLS close_notify is cryptographically guaranteed to originate from the p= eer,
> whereas TCP RST can be injected by an on-path entity to cause truncatio= n attacks.
>
> Thanks,
> David

I suspect we have a miscommunication going on here.

Robert Sparks, in his Genart review, said:

> Page 23, top of page: Since section 4 restricts this protocol to TLS ov= er TCP,
> the "(or equivalent for other protocols)" phrase should be removed.
=
This is a fine observation.

You then suggested changing TCP RST to TLS close_notify, not realizing (a) t= his is only for fatal errors, and (b) the precedent already set by RFC 8490.=

We have in fact updated the document, but I think this was too hasty, and we= should revert it back to the way it was before.

If not, we at least need to have a thorough DNSSD Working Group discussion a= bout this before making a last-minute change to the protocol.

Stuart Cheshire

= --Apple-Mail-C5C431DE-1300-449A-BC12-F3B9CD5030CC-- From nobody Thu Jul 11 10:19:22 2019 Return-Path: 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 B5752120331 for ; Thu, 11 Jul 2019 10:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 fSQHVNwMDjQm for ; Thu, 11 Jul 2019 10:19:10 -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 2CF5E12047C for ; Thu, 11 Jul 2019 10:19:10 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id a15so5086759qtn.7 for ; Thu, 11 Jul 2019 10:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=afkuRKgm9QG8DmCT8/YUp8FEXi7iULCeP7h1wgiUS6s=; b=WW8fhI+d9kE6duiW/R++Jvkctl+eYTPSR/guso80MS78lM+KXUp97+FEDs5oSghTTk +pwHniH+UHVi17yZuLmTePkShzknh7WSD6/FIZpqH8tBvm621p0NvDUSFqJ0peiKPxGi hueIZAcO8Vciji7RRDYfe9fPjh9XlNYlOxIlGYR7n/ikA5sXczA+X5VVYs/cE/WYmtrn WCZ4iOw8w4DuMIioxpKtNKTiF1sxzf6dpulSMtzZoPbbkV8XgCKHqigqoYP/U2vtZkuI OI7ZykonD8D85gISoq4wahJG7cyeJjzGFzk3GzYHW5HyzccBOQLoxY2oJ6Vj87t1E+iy bb9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=afkuRKgm9QG8DmCT8/YUp8FEXi7iULCeP7h1wgiUS6s=; b=tmpxqabJFaIFfHF1Y3sprney7vIiBUwRzFLJ5OeyM5GioIekn4F25n5NH40u21IGQq zH4y180OrjogFMNS7Xy0b0QG+HKKEsdfSMA8USg6vtlzjga4/QMLJaHxan7z5yfDZkS1 C25aWntm+IGG4aB49w/6NFUP17ngE1C2Rbj3CqY4MWRNTZjAEUJpx2spa8tRhxc37aPC 02sr/HTnvudQ8uBA/TkOhfrwwr5XzD20eJ+N53X1Gg2HKLzOLWw3Ez/l2ZUPWQppPuNC DN5pzYf+fm87LqB7MhB+bWBd+vBlQ9RD4CCFd06YBLGWzP/WmnrYUoBDIkzyXLymo4oh TEzQ== X-Gm-Message-State: APjAAAXhSyRTDywWYmKTICe9S1Bc7iEqvRuDRVENL82FQkbu6BW/D4t6 +FTkYJ4zd++4EHrLMjB17Yan7g== X-Google-Smtp-Source: APXvYqz3O89IRAPIP7Yw0lYjPzcsbnnClABPvPSmBFIPUA9g+y0NlicQ/a/oG5EASGtLx1MxhGSPXw== X-Received: by 2002:a0c:bd9a:: with SMTP id n26mr2777933qvg.25.1562865549140; Thu, 11 Jul 2019 10:19:09 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:1414:e90b:150f:bd61? ([2001:470:c1a2:1:1414:e90b:150f:bd61]) by smtp.gmail.com with ESMTPSA id x23sm2052208qtp.37.2019.07.11.10.19.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 10:19:08 -0700 (PDT) From: Ted Lemon Message-Id: <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_34F403E2-273D-431C-AAE1-7BDF85331869" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 13:19:05 -0400 In-Reply-To: Cc: David Schinazi , draft-ietf-dnssd-push.all@ietf.org, DNSSD , Tom Pusateri , Eric Rescorla , Robert Sparks To: Stuart Cheshire References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 17:19:20 -0000 --Apple-Mail=_34F403E2-273D-431C-AAE1-7BDF85331869 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 9, 2019, at 10:22 PM, Stuart Cheshire = wrote: > This is a fine observation. >=20 > You then suggested changing TCP RST to TLS close_notify, not realizing = (a) this is only for fatal errors, and (b) the precedent already set by = RFC 8490. >=20 > We have in fact updated the document, but I think this was too hasty, = and we should revert it back to the way it was before. >=20 > If not, we at least need to have a thorough DNSSD Working Group = discussion about this before making a last-minute change to the = protocol. To add some further nuance from a discussion that Stuart and I had today = on this, there are actually several different cases where connection = closes are done, and how they should be done is something we should talk = about. I think in all cases where the client is closing the connection, = there=E2=80=99s a case to be made that we don=E2=80=99t want to use = close_notify. It=E2=80=99s true that an attacker can kill our DNS Push = connection in this case by forging an RST to the server. We should = discuss whether this is a serious concern that we need to take into = account. If it is, then using close_notify would protect against this = iff the server ignores TCP RSTs for active TLS sessions.=20 But the main argument for using close_notify in this case is that we = want to be able to resume. This will not be the case if the client = closed the connection because of a protocol error. It will be the case = when the client is closing the connection due to inactivity. There is a case where the server closes the connection when the client = sends a duplicate subscribe. That=E2=80=99s because this is a protocol = error: the client is broken, and cannot be expected to take corrective = action. Then the question is, do we close the connection down with a = retry-delay to make the client go away, or do we just send an RST? Argument in favor of sending retry-delay: if the client implements it, it will shut up for a while. Arguments against: If the client doesn=E2=80=99t implement it, it won=E2=80=99t shut up, so = we haven=E2=80=99t gained anything Making things =E2=80=9Csort of work=E2=80=9D when the client is broken = isn=E2=80=99t all that helpful=E2=80=94we actually want the behavior in = this case to be dysfunctional, so that it is noticed and fixed. I think that the working group should consider these issues and come to = a consensus. My own personal opinion is that we should always do close_notify, = because if we can assume this, then an attacker can=E2=80=99t kill the = connection by sending an RST, if that behavior is implemented in the = TLS/TCP stack. My one doubt about this is that if we are going through = a NAT, will the NAT drop its mapping when it sees the RST? If so, then = close_notify doesn=E2=80=99t protect against this attack for a majority = of current users. It still might be worth doing for IPv6, of course. As to whether we should use retry-delay, I have really mixed feelings = about this. I want implementations to be visibly broken when they are = broken, but I don=E2=80=99t want to have to operate a server that has to = deal with broken clients. The question is whether forcibly = disconnecting will actually cause implementors to take action, or = whether it will not be noticed and contribute to dysfunction. My personal experience is that breaking badly is actually conducive to = improvement, so that=E2=80=99s the direction I=E2=80=99m leaning at the = moment. --Apple-Mail=_34F403E2-273D-431C-AAE1-7BDF85331869 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 9, 2019, at 10:22 PM, Stuart Cheshire <cheshire=3D40apple.com@dmarc.ietf.org> = wrote:
This is a = fine observation.

You then suggested changing TCP RST to TLS close_notify, not = realizing (a) this is only for fatal errors, and (b) the precedent = already set by RFC 8490.

We have in fact updated the document, but I think this was = too hasty, and we should revert it back to the way it was = before.

If not, we at = least need to have a thorough DNSSD Working Group discussion about this = before making a last-minute change to the = protocol.

To= add some further nuance from a discussion that Stuart and I had today = on this, there are actually several different cases where connection = closes are done, and how they should be done is something we should talk = about.

I think = in all cases where the client is closing the connection, there=E2=80=99s = a case to be made that we don=E2=80=99t want to = use close_notify.   It=E2=80=99s true that an attacker can kill our = DNS Push connection in this case by forging an RST to the server.   = We should discuss whether this is a serious concern that we need to take = into account.   If it is, then using close_notify would protect = against this iff the server ignores TCP RSTs for active TLS = sessions. 

But the main argument for using close_notify in this case is = that we want to be able to resume.   This will not be the case if = the client closed the connection because of a protocol error.   It = will be the case when the client is closing the connection due to = inactivity.

There is a case where the server closes the connection when = the client sends a duplicate subscribe.   That=E2=80=99s because = this is a protocol error: the client is broken, and cannot be expected = to take corrective action.   Then the question is, do we close the = connection down with a retry-delay to make the client go away, or do we = just send an RST?

Argument in favor of sending retry-delay:
  • if the client = implements it, it will shut up for a while.

Arguments against:
  • If the client doesn=E2=80=99t = implement it, it won=E2=80=99t shut up, so we haven=E2=80=99t gained = anything
  • Making things =E2=80=9Csort of work=E2=80=9D = when the client is broken isn=E2=80=99t all that helpful=E2=80=94we = actually want the behavior in this case to be dysfunctional, so that it = is noticed and fixed.

I think that the working group = should consider these issues and come to a consensus.

My own personal opinion = is that we should always do close_notify, because if we can assume this, = then an attacker can=E2=80=99t kill the connection by sending an RST, if = that behavior is implemented in the TLS/TCP stack.   My one doubt = about this is that if we are going through a NAT, will the NAT drop its = mapping when it sees the RST?   If so, then close_notify doesn=E2=80=99= t protect against this attack for a majority of current users.   It = still might be worth doing for IPv6, of course.

As to whether we should use = retry-delay, I have really mixed feelings about this.   I want = implementations to be visibly broken when they are broken, but I don=E2=80= =99t want to have to operate a server that has to deal with broken = clients.   The question is whether forcibly disconnecting will = actually cause implementors to take action, or whether it will not be = noticed and contribute to dysfunction.

My personal experience is that breaking = badly is actually conducive to improvement, so that=E2=80=99s the = direction I=E2=80=99m leaning at the moment.

= --Apple-Mail=_34F403E2-273D-431C-AAE1-7BDF85331869-- From nobody Thu Jul 11 11:20:42 2019 Return-Path: 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 AECE11203B0; Thu, 11 Jul 2019 11:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 0ZkyQqVaJnjM; Thu, 11 Jul 2019 11:20:38 -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 55DCB1203AA; Thu, 11 Jul 2019 11:20:34 -0700 (PDT) Received: from [172.16.25.117] (69-77-155-155.static.skybest.com [69.77.155.155]) (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 DDF0234766; Thu, 11 Jul 2019 14:20:32 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-0EA95D1B-5B0E-4344-B2EE-4A2984D214D3 Mime-Version: 1.0 (1.0) From: Tom Pusateri X-Mailer: iPad Mail (16F203) In-Reply-To: <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> Date: Thu, 11 Jul 2019 14:20:32 -0400 Cc: Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Robert Sparks Content-Transfer-Encoding: 7bit Message-Id: References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> To: Ted Lemon Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 18:20:41 -0000 --Apple-Mail-0EA95D1B-5B0E-4344-B2EE-4A2984D214D3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If a client implements PUSH, it implements DSO which means it implements KEE= PALIVE and RETRY DELAY. That doesn=E2=80=99t mean it will honor every part and it might retry before= the delay expires. But the server sent the retry delay and knows the timeout value and so the s= erver can filter this client for that period of time regardless of whether t= he client honors it or not. In fact, a server SHOULD do the filtering becaus= e the RETRY DELAY is really saying, I=E2=80=99m not going to listen to you u= ntil after this timeout. Also, even if the client closes because of an error, that doesn=E2=80=99t pr= eclude it from using TLS session resumption for the next subscription. So I=E2=80=99m in favor of always using close_notify and sending a RETRY DEL= AY for critical errors when needed. But I think it would be helpful to outline the actual errors that could occu= r on either end and verify this works in every case. Sending as much informa= tion to the other side as possible is helpful for determining bugs. TCP RST s= ignaling doesn=E2=80=99t convey much information. Tom > On Jul 11, 2019, at 1:19 PM, Ted Lemon wrote: >=20 >> On Jul 9, 2019, at 10:22 PM, Stuart Cheshire wrote: >> This is a fine observation. >>=20 >> You then suggested changing TCP RST to TLS close_notify, not realizing (a= ) this is only for fatal errors, and (b) the precedent already set by RFC 84= 90. >>=20 >> We have in fact updated the document, but I think this was too hasty, and= we should revert it back to the way it was before. >>=20 >> If not, we at least need to have a thorough DNSSD Working Group discussio= n about this before making a last-minute change to the protocol. >=20 > To add some further nuance from a discussion that Stuart and I had today o= n this, there are actually several different cases where connection closes a= re done, and how they should be done is something we should talk about. >=20 > I think in all cases where the client is closing the connection, there=E2=80= =99s a case to be made that we don=E2=80=99t want to use close_notify. It=E2= =80=99s true that an attacker can kill our DNS Push connection in this case b= y forging an RST to the server. We should discuss whether this is a seriou= s concern that we need to take into account. If it is, then using close_no= tify would protect against this iff the server ignores TCP RSTs for active T= LS sessions.=20 >=20 > But the main argument for using close_notify in this case is that we want t= o be able to resume. This will not be the case if the client closed the co= nnection because of a protocol error. It will be the case when the client i= s closing the connection due to inactivity. >=20 > There is a case where the server closes the connection when the client sen= ds a duplicate subscribe. That=E2=80=99s because this is a protocol error:= the client is broken, and cannot be expected to take corrective action. T= hen the question is, do we close the connection down with a retry-delay to m= ake the client go away, or do we just send an RST? >=20 > Argument in favor of sending retry-delay: > if the client implements it, it will shut up for a while. >=20 > Arguments against: > If the client doesn=E2=80=99t implement it, it won=E2=80=99t shut up, so w= e haven=E2=80=99t gained anything > Making things =E2=80=9Csort of work=E2=80=9D when the client is broken isn= =E2=80=99t all that helpful=E2=80=94we actually want the behavior in this ca= se to be dysfunctional, so that it is noticed and fixed. >=20 > I think that the working group should consider these issues and come to a c= onsensus. >=20 > My own personal opinion is that we should always do close_notify, because i= f we can assume this, then an attacker can=E2=80=99t kill the connection by s= ending an RST, if that behavior is implemented in the TLS/TCP stack. My on= e doubt about this is that if we are going through a NAT, will the NAT drop i= ts mapping when it sees the RST? If so, then close_notify doesn=E2=80=99t p= rotect against this attack for a majority of current users. It still might= be worth doing for IPv6, of course. >=20 > As to whether we should use retry-delay, I have really mixed feelings abou= t this. I want implementations to be visibly broken when they are broken, b= ut I don=E2=80=99t want to have to operate a server that has to deal with br= oken clients. The question is whether forcibly disconnecting will actually= cause implementors to take action, or whether it will not be noticed and co= ntribute to dysfunction. >=20 > My personal experience is that breaking badly is actually conducive to imp= rovement, so that=E2=80=99s the direction I=E2=80=99m leaning at the moment.= >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail-0EA95D1B-5B0E-4344-B2EE-4A2984D214D3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
If a= client implements PUSH, it implements DSO which means it implements KEEPALI= VE and RETRY DELAY.

That do= esn=E2=80=99t mean it will honor every part and it might retry before the de= lay expires.

But the server= sent the retry delay and knows the timeout value and so the server can filt= er this client for that period of time regardless of whether the client hono= rs it or not. In fact, a server SHOULD do the filtering because the RETRY DE= LAY is really saying, I=E2=80=99m not going to listen to you until after thi= s timeout.

Also, even if th= e client closes because of an error, that doesn=E2=80=99t preclude it from u= sing TLS session resumption for the next subscription.

So I=E2=80=99m in favor of always using close_no= tify and sending a RETRY DELAY for critical errors when needed.

But I think it would be helpful to outl= ine the actual errors that could occur on either end and verify this works i= n every case. Sending as much information to the other side as possible is h= elpful for determining bugs. TCP RST signaling doesn=E2=80=99t convey much i= nformation.

Tom

On Jul 11, 2019, at 1:19 PM, Ted Lemon <mellon@fugue.com> wrote:

On Jul 9, 2019, at 10:22 PM, Stuart Cheshire <= cheshire= =3D40apple.com@dmarc.ietf.org> wrote:
This is a fine observation.

You t= hen suggested changing TCP RST to TLS close_notify, not realizing (a) this i= s only for fatal errors, and (b) the precedent already set by RFC 8490.

We have in fact updated the document, but I think this was too hast= y, and we should revert it back to the way it was before.

If no= t, we at least need to have a thorough DNSSD Working Group discussion about t= his before making a last-minute change to the protocol.

To add some further nuance from a d= iscussion that Stuart and I had today on this, there are actually several di= fferent cases where connection closes are done, and how they should be done i= s something we should talk about.

=
I think in all cases where the client is closing the connect= ion, there=E2=80=99s a case to be made that we don=E2=80=99t want to use close_notify.   It=E2=80=99s true that an attacker c= an kill our DNS Push connection in this case by forging an RST to the server= .   We should discuss whether this is a serious concern that we need to= take into account.   If it is, then using close_notify would protect a= gainst this iff the server ignores TCP RSTs for active TLS sessions. 

But the main argume= nt for using close_notify in this case is that we want to be able to resume.=   This will not be the case if the client closed the connection becaus= e of a protocol error.   It will be the case when the client is closing= the connection due to inactivity.

There is a case where the server closes the connection when= the client sends a duplicate subscribe.   That=E2=80=99s because this i= s a protocol error: the client is broken, and cannot be expected to take cor= rective action.   Then the question is, do we close the connection down= with a retry-delay to make the client go away, or do we just send an RST?

Argument in favor o= f sending retry-delay:
  • if the client implements it, it will shut up for a while.
=

Arguments against:
  • If the client doesn=E2=80=99t impl= ement it, it won=E2=80=99t shut up, so we haven=E2=80=99t gained anything
  • Making things =E2=80=9Csort of work=E2=80=9D when the clien= t is broken isn=E2=80=99t all that helpful=E2=80=94we actually want the beha= vior in this case to be dysfunctional, so that it is noticed and fixed.
    • =

I think that= the working group should consider these issues and come to a consensus.

My own personal opini= on is that we should always do close_notify, because if we can assume this, t= hen an attacker can=E2=80=99t kill the connection by sending an RST, if that= behavior is implemented in the TLS/TCP stack.   My one doubt about thi= s is that if we are going through a NAT, will the NAT drop its mapping when i= t sees the RST?   If so, then close_notify doesn=E2=80=99t protect agai= nst this attack for a majority of current users.   It still might be wo= rth doing for IPv6, of course.

As to whether we should use retry-delay, I have really mixed fe= elings about this.   I want implementations to be visibly broken when t= hey are broken, but I don=E2=80=99t want to have to operate a server that ha= s to deal with broken clients.   The question is whether forcibly disco= nnecting will actually cause implementors to take action, or whether it will= not be noticed and contribute to dysfunction.

My personal experience is that breaking badly i= s actually conducive to improvement, so that=E2=80=99s the direction I=E2=80= =99m leaning at the moment.

=
______________= _________________________________
dnssd mailing list<= br>dnssd@ietf.org
https://www.ietf.o= rg/mailman/listinfo/dnssd
= --Apple-Mail-0EA95D1B-5B0E-4344-B2EE-4A2984D214D3-- From nobody Thu Jul 11 14:44:39 2019 Return-Path: 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 246F9120156; Thu, 11 Jul 2019 14:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZUK_ZdGB0n-S; Thu, 11 Jul 2019 14:44:34 -0700 (PDT) Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 D1762120123; Thu, 11 Jul 2019 14:44:33 -0700 (PDT) Received: by mail-lf1-x142.google.com with SMTP id h28so5055521lfj.5; Thu, 11 Jul 2019 14:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U65N0PrkOpB/Jav3ny95bdNQYarSDjvMbnryx9A1CEo=; b=qJrXgUngFYkzKatZ8IiX41rtU5kSkbTvcwh3UYENKYlVNkU5FKCH/Uj5XOyuoWRkJ3 jGI3xVvxhcfw0ijCiBKVRXk4JIJ5rF4veE4dlOMD84zhOYPqpy9szV3CWyjI5U3RBADc 4LredKCftz6h5DLLA6rBHsZptlBwXpu+xgCDe8DriIDaLUOEqR3vZVoH5BozcJQ3uuTc MZ77+KxNPjrPH4zWx48Jshcrgb72QU5M/1vpCwoellfL9ROtryIA+aIrPDrJRc3x7JZn CqQTO1w7ns0fCFhApjJYRovFv8Gyfj7YTJCd7pu92frJjcb3YAfDA2atQeGVtO6rw3EQ tEeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=U65N0PrkOpB/Jav3ny95bdNQYarSDjvMbnryx9A1CEo=; b=ct0jOBqvSE2PyeUMYV61ZnXZVIsFDHd+n6s412lMBneYEg39aSGRrmPlAm7IHH4G0H kK8Q6aDo3su129A5O7RyccKVn6m8NcTIT89KdgOXF/9gZhvO/yO+uXO2an7HKVpDBuKx tEfr7R+6JMhiOHzEXl6KZvyJ2JhToxwhJ4vLADlDBWRBSEwXWiSTjaFRQFx4r2esO3Ue TK9fewVu3RQx1qgZMz+/+ShvLve8dM4sXYoFK+AAtPqjp2xFq8wIW5Dp3qQQz492Avhv 8TWK5BVUXp93OdK2siUC7Kd6wBrMrKzAJFbmeffn8pjbJMJJv9E6ph26pQ0fzPwpgsfv gZ0w== X-Gm-Message-State: APjAAAWzogv7Updn2B/Jg7OvseDwLKnEOKfA2NSeqQ3Q/RroThhK+F2T XTN9iqlPR4YSaq1VDwR5JqbBAOCsE0E+XV8BzRg= X-Google-Smtp-Source: APXvYqxiRKiXn8Rlvu/5rLzm1MEM7lXCJdAo62L4aODnZojmN2w4aiu04H+j2PPIXdQ2we5wstZetDxAKn+eRSQtwsA= X-Received: by 2002:ac2:514b:: with SMTP id q11mr2997492lfd.33.1562881472008; Thu, 11 Jul 2019 14:44:32 -0700 (PDT) MIME-Version: 1.0 References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> In-Reply-To: From: David Schinazi Date: Thu, 11 Jul 2019 14:44:20 -0700 Message-ID: To: Tom Pusateri Cc: Ted Lemon , Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, Robert Sparks Content-Type: multipart/alternative; boundary="000000000000f71848058d6eb2ba" Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 21:44:37 -0000 --000000000000f71848058d6eb2ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To reiterate my earlier point, TLS close_notify DOES NOT protect against an attacker closing the connection by sending a FIN or RST. The benefit of close_notify is to protect against truncation attacks: if an attacker sends a FIN or RST in the middle of a stream, the recipient application should ignore the current message instead of considering it complete. This is important for protocols such as HTTP/0.9 that rely on the TCP FIN instead of using prefixed lengths. Given that DSO messages contain a prefixed length, making sure implementations do not act on partial messages is sufficient to prevent truncation attacks. If my understanding is correct, DNS-PUSH does not get ANY security benefits from close_notify. When a critical error occurs, a TCP RST should cause the other side to tear down state more aggressively than a close_notify, which is what we want. I'd recommend using close_notify for gracefully closes, and TCP RST for any critical failures. I agree with Ted that if an implementation is broken it's best to have it fail very visibly. David On Thu, Jul 11, 2019 at 11:20 AM Tom Pusateri wrote: > If a client implements PUSH, it implements DSO which means it implements > KEEPALIVE and RETRY DELAY. > > That doesn=E2=80=99t mean it will honor every part and it might retry bef= ore the > delay expires. > > But the server sent the retry delay and knows the timeout value and so th= e > server can filter this client for that period of time regardless of wheth= er > the client honors it or not. In fact, a server SHOULD do the filtering > because the RETRY DELAY is really saying, I=E2=80=99m not going to listen= to you > until after this timeout. > > Also, even if the client closes because of an error, that doesn=E2=80=99t= preclude > it from using TLS session resumption for the next subscription. > > So I=E2=80=99m in favor of always using close_notify and sending a RETRY = DELAY for > critical errors when needed. > > But I think it would be helpful to outline the actual errors that could > occur on either end and verify this works in every case. Sending as much > information to the other side as possible is helpful for determining bugs= . > TCP RST signaling doesn=E2=80=99t convey much information. > > Tom > > On Jul 11, 2019, at 1:19 PM, Ted Lemon wrote: > > On Jul 9, 2019, at 10:22 PM, Stuart Cheshire < > cheshire=3D40apple.com@dmarc.ietf.org> wrote: > > This is a fine observation. > > You then suggested changing TCP RST to TLS close_notify, not realizing (a= ) > this is only for fatal errors, and (b) the precedent already set by RFC > 8490. > > We have in fact updated the document, but I think this was too hasty, and > we should revert it back to the way it was before. > > If not, we at least need to have a thorough DNSSD Working Group discussio= n > about this before making a last-minute change to the protocol. > > > To add some further nuance from a discussion that Stuart and I had today > on this, there are actually several different cases where connection clos= es > are done, and how they should be done is something we should talk about. > > I think in all cases where the client is closing the connection, there=E2= =80=99s a > case to be made that we *don=E2=80=99t* want to use close_notify. It=E2= =80=99s true > that an attacker can kill our DNS Push connection in this case by forging > an RST to the server. We should discuss whether this is a serious conce= rn > that we need to take into account. If it is, then using close_notify > would protect against this iff the server ignores TCP RSTs for active TLS > sessions. > > But the main argument for using close_notify in this case is that we want > to be able to resume. This will not be the case if the client closed th= e > connection because of a protocol error. It will be the case when the > client is closing the connection due to inactivity. > > There is a case where the server closes the connection when the client > sends a duplicate subscribe. That=E2=80=99s because this is a protocol = error: the > client is broken, and cannot be expected to take corrective action. The= n > the question is, do we close the connection down with a retry-delay to ma= ke > the client go away, or do we just send an RST? > > Argument in favor of sending retry-delay: > > - if the client implements it, it will shut up for a while. > > > Arguments against: > > - If the client doesn=E2=80=99t implement it, it won=E2=80=99t shut up= , so we haven=E2=80=99t > gained anything > - Making things =E2=80=9Csort of work=E2=80=9D when the client is brok= en isn=E2=80=99t all > that helpful=E2=80=94we actually want the behavior in this case to be > dysfunctional, so that it is noticed and fixed. > > > I think that the working group should consider these issues and come to a > consensus. > > My own personal opinion is that we should always do close_notify, because > if we can assume this, then an attacker can=E2=80=99t kill the connection= by > sending an RST, if that behavior is implemented in the TLS/TCP stack. M= y > one doubt about this is that if we are going through a NAT, will the NAT > drop its mapping when it sees the RST? If so, then close_notify doesn= =E2=80=99t > protect against this attack for a majority of current users. It still > might be worth doing for IPv6, of course. > > As to whether we should use retry-delay, I have really mixed feelings > about this. I want implementations to be visibly broken when they are > broken, but I don=E2=80=99t want to have to operate a server that has to = deal with > broken clients. The question is whether forcibly disconnecting will > actually cause implementors to take action, or whether it will not be > noticed and contribute to dysfunction. > > My personal experience is that breaking badly is actually conducive to > improvement, so that=E2=80=99s the direction I=E2=80=99m leaning at the m= oment. > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --000000000000f71848058d6eb2ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To reiterate my earlier point, TLS close_notify DOES = NOT protect against an attacker closing the connection by sending a FIN or = RST.
The benefit of close_notify is to protect against trunca= tion attacks: if an attacker sends a FIN or RST in the middle of a stream,<= /div>
the recipient application should ignore the current message inste= ad of considering it complete.
This is important for protocols su= ch as HTTP/0.9 that rely on the TCP FIN instead of using prefixed lengths.<= /div>
Given that DSO messages contain a prefixed length, making sure im= plementations do not act on partial messages is sufficient to prevent trunc= ation attacks.
If my understanding=C2=A0is correct, DNS-PUSH does= not get ANY security benefits from close_notify.

When a = critical error occurs, a TCP RST should cause the other side to tear down s= tate more aggressively than a close_notify, which is what we want.

I'd recommend using close_notify for gracefully closes= , and TCP RST for any critical failures.

I agree w= ith Ted that if an implementation is broken it's best to have it fail v= ery visibly.

David

On Thu, Jul 11, 2019 at 11= :20 AM Tom Pusateri <pusateri@bang= j.com> wrote:
If a client = implements PUSH, it implements DSO which means it implements KEEPALIVE and = RETRY DELAY.

That doesn=E2= =80=99t mean it will honor every part and it might retry before the delay e= xpires.

But the server sen= t the retry delay and knows the timeout value and so the server can filter = this client for that period of time regardless of whether the client honors= it or not. In fact, a server SHOULD do the filtering because the RETRY DEL= AY is really saying, I=E2=80=99m not going to listen to you until after thi= s timeout.

Also, even if t= he client closes because of an error, that doesn=E2=80=99t preclude it from= using TLS session resumption for the next subscription.

So I=E2=80=99m in favor of always using clos= e_notify and sending a RETRY DELAY for critical errors when needed.

But I think it would be helpful t= o outline the actual errors that could occur on either end and verify this = works in every case. Sending as much information to the other side as possi= ble is helpful for determining bugs. TCP RST signaling doesn=E2=80=99t conv= ey much information.

Tom

On Jul 11, 2019, at 1:19 PM, Ted Lemon <mellon@fugue.com> wro= te:

On Jul 9, 2019,= at 10:22 PM, Stuart Cheshire <cheshire=3D40apple.com@dmarc.ietf.org= > wrote:
This is a fine observation.

You then suggested changing TCP RST to TLS close_notify, not realiz= ing (a) this is only for fatal errors, and (b) the precedent already set by= RFC 8490.

We have in fact updated the docum= ent, but I think this was too hasty, and we should revert it back to the wa= y it was before.

If not, we at least need to= have a thorough DNSSD Working Group discussion about this before making a = last-minute change to the protocol.

To add some further nuance from a discussion that Stuart and I had today o= n this, there are actually several different cases where connection closes = are done, and how they should be done is something we should talk about.

I think in all cases where the client is closing the= connection, there=E2=80=99s a case to be made that we don=E2=80=99t= =C2=A0want to use close_notify. =C2=A0 It=E2=80=99s true that an attacker c= an kill our DNS Push connection in this case by forging an RST to the serve= r. =C2=A0 We should discuss whether this is a serious concern that we need = to take into account. =C2=A0 If it is, then using close_notify would protec= t against this iff the server ignores TCP RSTs for active TLS sessions.=C2= =A0

But the main argument for using close_notify i= n this case is that we want to be able to resume. =C2=A0 This will not be t= he case if the client closed the connection because of a protocol error. = =C2=A0 It will be the case when the client is closing the connection due to= inactivity.

There is a case where the server clos= es the connection when the client sends a duplicate subscribe. =C2=A0 That= =E2=80=99s because this is a protocol error: the client is broken, and cann= ot be expected to take corrective action. =C2=A0 Then the question is, do w= e close the connection down with a retry-delay to make the client go away, = or do we just send an RST?

Argument in favor of se= nding retry-delay:
  • if the client implements it, it will shut up for a while.
    • <= /ul>

    Arguments against:
    • If the client doesn=E2=80=99t implement it, = it won=E2=80=99t shut up, so we haven=E2=80=99t gained anything
    • Mak= ing things =E2=80=9Csort of work=E2=80=9D when the client is broken isn=E2= =80=99t all that helpful=E2=80=94we actually want the behavior in this case= to be dysfunctional, so that it is noticed and fixed.

    I think that the working group should consider these issues = and come to a consensus.

    My own personal opinion i= s that we should always do close_notify, because if we can assume this, the= n an attacker can=E2=80=99t kill the connection by sending an RST, if that = behavior is implemented in the TLS/TCP stack. =C2=A0 My one doubt about thi= s is that if we are going through a NAT, will the NAT drop its mapping when= it sees the RST? =C2=A0 If so, then close_notify doesn=E2=80=99t protect a= gainst this attack for a majority of current users. =C2=A0 It still might b= e worth doing for IPv6, of course.

    As to whether w= e should use retry-delay, I have really mixed feelings about this. =C2=A0 I= want implementations to be visibly broken when they are broken, but I don= =E2=80=99t want to have to operate a server that has to deal with broken cl= ients. =C2=A0 The question is whether forcibly disconnecting will actually = cause implementors to take action, or whether it will not be noticed and co= ntribute to dysfunction.

    My personal experience is= that breaking badly is actually conducive to improvement, so that=E2=80=99= s the direction I=E2=80=99m leaning at the moment.

___________= ____________________________________
dnssd mailing list
dnssd@ietf= .org
https://www.ietf.org/mailman/listinfo/dnssd
--000000000000f71848058d6eb2ba-- From nobody Thu Jul 11 14:46:47 2019 Return-Path: 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 43E2E120112; Thu, 11 Jul 2019 14:46:46 -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 HpwI8zS2pFZI; Thu, 11 Jul 2019 14:46:44 -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 7DA801200F8; Thu, 11 Jul 2019 14:46:44 -0700 (PDT) Received: from [172.16.25.146] (69-77-155-155.static.skybest.com [69.77.155.155]) (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 62625347B2; Thu, 11 Jul 2019 17:46:43 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) From: Tom Pusateri In-Reply-To: Date: Thu, 11 Jul 2019 17:46:42 -0400 Cc: Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Robert Sparks Content-Transfer-Encoding: quoted-printable Message-Id: References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 21:46:46 -0000 > On Jul 11, 2019, at 2:20 PM, Tom Pusateri wrote: >=20 > But I think it would be helpful to outline the actual errors that = could occur on either end and verify this works in every case. Sending = as much information to the other side as possible is helpful for = determining bugs. TCP RST signaling doesn=E2=80=99t convey much = information. >=20 > Tom Here are all the places a TCP RST was suggested in -20. These are all = likely BUGS. 1. CLIENT receives SUBSCRIBE from server 2. SERVER receives duplicate SUBSCRIBE 3. CLIENT receives PUSH with no change notifications 4. CLIENT receives PUSH notification with =E2=80=98collective remove=E2=80= =99 TTL and non-zero RDLEN 5. CLIENT receives PUSH notification with DNS message length larger than = 16k 6. CLIENT receives UNSUBSCRIBE from SERVER In cases 1, 3, 4, 5, and 6, the CLIENT will likely mark the SERVER as = buggy, close the connection and not try to reconnect for a period of = time or use another SERVER if available. A RETRY DELAY isn=E2=80=99t = applicable and the CLIENT can close the connection either with a TCP RST = or a TLS close_notify. The consensus seems to be to send a TCP RST in = this case. In case 2, the SERVER should send a RETRY DELAY TLV and then send a TLS = close_notify or it could wait for the CLIENT to close_notify or RST but = the SERVER shouldn=E2=80=99t RST because it wants the CLIENT to get the = RETRY DELAY. There are also cases where the server sends a RETRY DELAY TLV because of = a SUBSCRIBE error and the CLIENT is supposed to close the connection. = However, if the CLIENT does not close the connection, the SERVER may = choose to close it in which case it should close with TLS close_notify = to make sure the RETRY DELAY is received. I think it would be better for the CLIENT to try to send a TLS = close_notify after receiving a RETRY DELAY so it can resume later = especially in the cases when a SUBSCRIBE fails. Tom= From nobody Thu Jul 11 15:58:28 2019 Return-Path: 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 A7114120041 for ; Thu, 11 Jul 2019 15:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ne3NiwIgL79H for ; Thu, 11 Jul 2019 15:58:23 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 97C0612017C for ; Thu, 11 Jul 2019 15:58:21 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id k10so6254449qtq.1 for ; Thu, 11 Jul 2019 15:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7csaWt9xzuB7S5/JT26e/r/xEcpwIal7vjH48cp1yaA=; b=LuO80knzWV++9iNxkzi5dGirHwbFNTxPxHuRn5yz5YPw72/7ceqvNFLDR5xldl1r+a De5gHOQt1nNSBj3VvNH811TyGrBMDNbckEIYsR/TbHkiiliQzYGGvLt3i18bmXTDgFCT sFgVSfXwqfD4bKZCdIU/syRlqvoqyvT99k2L0aCdy1W2sMPt/MDYjmi1o+YFC/+cv+jj K+oGUT4ZpN+k0V227AngER8CSVuENwmowBK0xSEf5FnyHhrY1ixiAgO8Y5zi4FQ/R4X8 Zq5pCuAFfrj9RT8nAU+zw/rjConKSdy+kE99hSczP+Dxd2UNg5rPDuI79wUj9P4cZTvu z1aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7csaWt9xzuB7S5/JT26e/r/xEcpwIal7vjH48cp1yaA=; b=GAkZHy9/1oyJ2NgExgnXa0rZZyOVn7dwm1NlGINCeGVgpww8UsaiQwX3DM82XObXum 5NB1a1gr21ey5d4hZ6YvryvzAo7/KJmnF0CSm6TsFCRCaEOkKy85l3CnbjnlVYHwIq8P nHLnE9eHHULrgFBHD1tn7Z6RU0ZEjH8hE3Ky2/dAQoKQr8JoBhPqihs/ubWeVz28Ha/w UZ37/7maoFw1Qx1c0lE6D68wn11RZELOpU3RIsRoNjfUGtoCZDhgKDwrLb54xDGFhFn3 D8JtZCYOh+AcU16HEwwycqXgnBtq5HjqBuHX19gZiixf8t6mwoo7mpRKpUfYcJChazmb gp1w== X-Gm-Message-State: APjAAAWu8JKRbZhNdX+EO+6+j9zrmprWP8BsfrWVfAZRww/H4ScRcetb uunF1jvGSmFk36NybJ6cYBST0g== X-Google-Smtp-Source: APXvYqzEri16aV5QY6MGHIt++pJR5fJNZjFqapMPxDTfAgOB2nKIsaP907rH6UBRx2hIo6ZKivCg6A== X-Received: by 2002:ac8:2726:: with SMTP id g35mr3841333qtg.35.1562885900409; Thu, 11 Jul 2019 15:58:20 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:1414:e90b:150f:bd61? ([2001:470:c1a2:1:1414:e90b:150f:bd61]) by smtp.gmail.com with ESMTPSA id a21sm2686362qka.113.2019.07.11.15.58.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 15:58:19 -0700 (PDT) From: Ted Lemon Message-Id: <83331D7B-2853-4B5B-8350-ACD18922780E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_27009587-3EFA-4BB8-B9E8-AE12591F85C2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 18:58:16 -0400 In-Reply-To: Cc: Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Robert Sparks To: Tom Pusateri References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 22:58:26 -0000 --Apple-Mail=_27009587-3EFA-4BB8-B9E8-AE12591F85C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 11, 2019, at 5:46 PM, Tom Pusateri wrote: > 1. CLIENT receives SUBSCRIBE from server > 2. SERVER receives duplicate SUBSCRIBE > 3. CLIENT receives PUSH with no change notifications > 4. CLIENT receives PUSH notification with =E2=80=98collective = remove=E2=80=99 TTL and non-zero RDLEN > 5. CLIENT receives PUSH notification with DNS message length larger = than 16k > 6. CLIENT receives UNSUBSCRIBE from SERVER >=20 > In cases 1, 3, 4, 5, and 6, the CLIENT will likely mark the SERVER as = buggy, close the connection and not try to reconnect for a period of = time or use another SERVER if available. A RETRY DELAY isn=E2=80=99t = applicable and the CLIENT can close the connection either with a TCP RST = or a TLS close_notify. The consensus seems to be to send a TCP RST in = this case. >=20 > In case 2, the SERVER should send a RETRY DELAY TLV and then send a = TLS close_notify or it could wait for the CLIENT to close_notify or RST = but the SERVER shouldn=E2=80=99t RST because it wants the CLIENT to get = the RETRY DELAY. >=20 > There are also cases where the server sends a RETRY DELAY TLV because = of a SUBSCRIBE error and the CLIENT is supposed to close the connection. = However, if the CLIENT does not close the connection, the SERVER may = choose to close it in which case it should close with TLS close_notify = to make sure the RETRY DELAY is received. >=20 > I think it would be better for the CLIENT to try to send a TLS = close_notify after receiving a RETRY DELAY so it can resume later = especially in the cases when a SUBSCRIBE fails. Given David=E2=80=99s points, I don=E2=80=99t think there=E2=80=99s any = reason to send a RETRY DELAY in case 2. It should be handled the same = as the other =E2=80=9Cprotocol error=E2=80=9D cases. Can you think of a = reason why case 2 is different, other than that it=E2=80=99s the one = case where it=E2=80=99s possible to send a RETRY DELAY? Bear in mind = that it is a protocol error for the client to send a duplicate = subscribe: it means that the client=E2=80=99s internal state is not = being tracked correctly. So it=E2=80=99s not a recoverable error. We = don=E2=80=99t want the client to reconnect. Additionally, as you=E2=80=99ve pointed out, although the server could = send the client a RETRY DELAY, if the client isn=E2=80=99t following the = spec in one context there=E2=80=99s no particular reason to expect it to = follow the spec in another. Requiring the server to have special = heuristics to follow in the case of broken clients seems to be creating = an unreasonable burden. --Apple-Mail=_27009587-3EFA-4BB8-B9E8-AE12591F85C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 11, 2019, at 5:46 PM, Tom Pusateri <pusateri@bangj.com> = wrote:
1. CLIENT receives SUBSCRIBE from server
2. SERVER receives duplicate SUBSCRIBE
3. CLIENT = receives PUSH with no change notifications
4. CLIENT receives PUSH notification with =E2=80=98collective = remove=E2=80=99 TTL and non-zero RDLEN
5. CLIENT receives PUSH notification with DNS message length = larger than 16k
6. CLIENT receives UNSUBSCRIBE from SERVER

In cases 1, = 3, 4, 5, and 6, the CLIENT will likely mark the SERVER as buggy, close = the connection and not try to reconnect for a period of time or use = another SERVER if available. A RETRY DELAY isn=E2=80=99t applicable and = the CLIENT can close the connection either with a TCP RST or a TLS = close_notify. The consensus seems to be to send a TCP RST in this = case.

In case 2, = the SERVER should send a RETRY DELAY TLV and then send a TLS = close_notify or it could wait for the CLIENT to close_notify or RST but = the SERVER shouldn=E2=80=99t RST because it wants the CLIENT to get the = RETRY DELAY.

There are = also cases where the server sends a RETRY DELAY TLV because of a = SUBSCRIBE error and the CLIENT is supposed to close the connection. = However, if the CLIENT does not close the connection, the SERVER may = choose to close it in which case it should close with TLS close_notify = to make sure the RETRY DELAY is received.

I think it would be better for the CLIENT to try to send a = TLS close_notify after receiving a RETRY DELAY so it can resume later = especially in the cases when a SUBSCRIBE = fails.

Given= David=E2=80=99s points, I don=E2=80=99t think there=E2=80=99s any = reason to send a RETRY DELAY in case 2.   It should be handled the = same as the other =E2=80=9Cprotocol error=E2=80=9D cases.  Can you = think of a reason why case 2 is different, other than that it=E2=80=99s = the one case where it=E2=80=99s possible to send a RETRY DELAY? =  Bear in mind that it is a protocol = error for the client to send a duplicate subscribe: it means = that the client=E2=80=99s internal state is not being tracked correctly. =   So it=E2=80=99s not a recoverable error.  We don=E2=80=99t = want the client to reconnect.

Additionally, as you=E2=80=99ve pointed = out, although the server could send the client a RETRY DELAY, if the = client isn=E2=80=99t following the spec in one context there=E2=80=99s = no particular reason to expect it to follow the spec in another.   = Requiring the server to have special heuristics to follow in the case of = broken clients seems to be creating an unreasonable burden.

= --Apple-Mail=_27009587-3EFA-4BB8-B9E8-AE12591F85C2-- From nobody Thu Jul 11 15:58:48 2019 Return-Path: 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 BE72512018F for ; Thu, 11 Jul 2019 15:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 P9A0j-5H5nkE for ; Thu, 11 Jul 2019 15:58:45 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 71DA112017C for ; Thu, 11 Jul 2019 15:58:45 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id x22so1306810qtp.12 for ; Thu, 11 Jul 2019 15:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=2zd1DszLcJfZJguJR7VIzBpOQ/dzbxyl0X4wQFTBQRE=; b=GW95RM7MSnlJa3cQkZVEKpaX6gKNiwpxPWE9ZREM1ghiuPR09hZZ7zWgKT2g9ZRm8T ByEetJzuoPPOSiB5CiXBFgSlAfzB8/TS9XUdnbnbxGKNCW4MgZ76oQ9K4wo1CPDRqJ93 0XofbQpT3/JywVH1M1m5S2a8TSLU/rTG69wKA4gkIkfmCBRYGvU3XPrdTFWfsQkZqJWW HRmQPnLH/L68Ttln/5k1bZUiJCTrbWcjlQtrfF+oMyUD/IKxv9wNAi7QpR71VcqUROSQ YJS5Nnr2pS8IYsUHcTD7fUU+pzy6aTjMmjdqdfrNl0csNjfmTXTHXsrAm5iKB3RoLAN0 q8dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=2zd1DszLcJfZJguJR7VIzBpOQ/dzbxyl0X4wQFTBQRE=; b=knnfbAJ2Py+D9I0u4mqRzJTIj76mufkmcrCnvFz4tAFyP4Anb36VgOMgEbevrgd4a9 DHVa5LFiJncWU987Z4Xln20A6Od5wICc87hn7BIF40tfKTpr/JzClkI0NxbGhL2V73Y1 cqllknLBSeVnEogl4ZwQgRFeDQjNeD854Tuc8oY/hdS6EIymuuxPLfX+w5aunynbiWhd 3xR1hHiZw3CNVWmZkGGl0RQhQMWCVQ/WLSt8qQAIPlyjRnqBZRIU8EjnckDKtwyitwdb y6t+MW/mrEJ8lmrk9TJ47/N9TRelqFhi0opmm+tIX9okLFN0uKcZul8VSQOYYzSVz+1h 3jZg== X-Gm-Message-State: APjAAAXYM8rB4kcAJro4j0XhqTgd9oLDsmWMZlLSLQ/4iD14nEj0TujA Tcsq9+Czp+Qp1gM7XxhHhbE9Ug== X-Google-Smtp-Source: APXvYqxXQhNdlVneh/SGPmNMabF+tGZa1Q0Hzd6GYrMfZBusneNe1JTqYP/MT8HnLh48oxk573uXZw== X-Received: by 2002:ac8:285c:: with SMTP id 28mr3956008qtr.186.1562885924622; Thu, 11 Jul 2019 15:58:44 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:1414:e90b:150f:bd61? ([2001:470:c1a2:1:1414:e90b:150f:bd61]) by smtp.gmail.com with ESMTPSA id a21sm2686362qka.113.2019.07.11.15.58.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 15:58:44 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_25D3D5E3-8A91-4A6B-9CC0-0B6042DE173F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 18:58:42 -0400 In-Reply-To: Cc: Tom Pusateri , Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, Robert Sparks To: David Schinazi References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 22:58:47 -0000 --Apple-Mail=_25D3D5E3-8A91-4A6B-9CC0-0B6042DE173F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jul 11, 2019, at 5:44 PM, David Schinazi = wrote: > I'd recommend using close_notify for gracefully closes, and TCP RST = for any critical failures. > I agree with Ted that if an implementation is broken it's best to have = it fail very visibly. SGTM. Thanks for clarifying! --Apple-Mail=_25D3D5E3-8A91-4A6B-9CC0-0B6042DE173F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jul 11, 2019, at 5:44 PM, David Schinazi <dschinazi.ietf@gmail.com> wrote:
I'd recommend using close_notify for = gracefully closes, and TCP RST for any critical failures.
I = agree with Ted that if an implementation is broken it's best to have it = fail very visibly.

SGTM.  Thanks for clarifying!

= --Apple-Mail=_25D3D5E3-8A91-4A6B-9CC0-0B6042DE173F-- From nobody Thu Jul 11 16:03:24 2019 Return-Path: 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 1CE3F120041; Thu, 11 Jul 2019 16:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 vFnDTZlxc4Kc; Thu, 11 Jul 2019 16:03:20 -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 0D29212016B; Thu, 11 Jul 2019 16:03:20 -0700 (PDT) Received: from [192.168.1.13] (71-15-27-6.dhcp.hlrg.nc.charter.com [71.15.27.6]) (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 9EC20347D5; Thu, 11 Jul 2019 19:03:18 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_46CCAA12-F964-465A-83C1-5E7129210CDC" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Date: Thu, 11 Jul 2019 19:03:17 -0400 In-Reply-To: <83331D7B-2853-4B5B-8350-ACD18922780E@fugue.com> Cc: Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Robert Sparks To: Ted Lemon References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> <83331D7B-2853-4B5B-8350-ACD18922780E@fugue.com> X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 23:03:23 -0000 --Apple-Mail=_46CCAA12-F964-465A-83C1-5E7129210CDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 11, 2019, at 6:58 PM, Ted Lemon wrote: >=20 > On Jul 11, 2019, at 5:46 PM, Tom Pusateri > wrote: >> 1. CLIENT receives SUBSCRIBE from server >> 2. SERVER receives duplicate SUBSCRIBE >> 3. CLIENT receives PUSH with no change notifications >> 4. CLIENT receives PUSH notification with =E2=80=98collective = remove=E2=80=99 TTL and non-zero RDLEN >> 5. CLIENT receives PUSH notification with DNS message length larger = than 16k >> 6. CLIENT receives UNSUBSCRIBE from SERVER >>=20 >> In cases 1, 3, 4, 5, and 6, the CLIENT will likely mark the SERVER as = buggy, close the connection and not try to reconnect for a period of = time or use another SERVER if available. A RETRY DELAY isn=E2=80=99t = applicable and the CLIENT can close the connection either with a TCP RST = or a TLS close_notify. The consensus seems to be to send a TCP RST in = this case. >>=20 >> In case 2, the SERVER should send a RETRY DELAY TLV and then send a = TLS close_notify or it could wait for the CLIENT to close_notify or RST = but the SERVER shouldn=E2=80=99t RST because it wants the CLIENT to get = the RETRY DELAY. >>=20 >> There are also cases where the server sends a RETRY DELAY TLV because = of a SUBSCRIBE error and the CLIENT is supposed to close the connection. = However, if the CLIENT does not close the connection, the SERVER may = choose to close it in which case it should close with TLS close_notify = to make sure the RETRY DELAY is received. >>=20 >> I think it would be better for the CLIENT to try to send a TLS = close_notify after receiving a RETRY DELAY so it can resume later = especially in the cases when a SUBSCRIBE fails. >=20 > Given David=E2=80=99s points, I don=E2=80=99t think there=E2=80=99s = any reason to send a RETRY DELAY in case 2. It should be handled the = same as the other =E2=80=9Cprotocol error=E2=80=9D cases. Can you think = of a reason why case 2 is different, other than that it=E2=80=99s the = one case where it=E2=80=99s possible to send a RETRY DELAY? Bear in = mind that it is a protocol error for the client to send a duplicate = subscribe: it means that the client=E2=80=99s internal state is not = being tracked correctly. So it=E2=80=99s not a recoverable error. We = don=E2=80=99t want the client to reconnect. >=20 > Additionally, as you=E2=80=99ve pointed out, although the server could = send the client a RETRY DELAY, if the client isn=E2=80=99t following the = spec in one context there=E2=80=99s no particular reason to expect it to = follow the spec in another. Requiring the server to have special = heuristics to follow in the case of broken clients seems to be creating = an unreasonable burden. >=20 The SERVER may want to conserve resources from broken clients. The RETRY = DELAY is for the SERVER=E2=80=99s protection and it=E2=80=99s = thoughtfully informing the CLIENT how long it has to wait before the = SERVER will accept a connection from it. It doesn=E2=80=99t matter if = the CLIENT agrees or not or whether the CLIENT follows the spec or not. Tom --Apple-Mail=_46CCAA12-F964-465A-83C1-5E7129210CDC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 11, 2019, at 6:58 PM, Ted Lemon <mellon@fugue.com> = wrote:

On Jul 11, 2019, at = 5:46 PM, Tom Pusateri <pusateri@bangj.com> wrote:
1. CLIENT receives SUBSCRIBE from server
2. SERVER receives duplicate SUBSCRIBE
3. CLIENT = receives PUSH with no change notifications
4. CLIENT receives PUSH notification with =E2=80=98collective = remove=E2=80=99 TTL and non-zero RDLEN
5. CLIENT receives PUSH notification with DNS message length = larger than 16k
6. CLIENT receives UNSUBSCRIBE from SERVER

In cases 1, = 3, 4, 5, and 6, the CLIENT will likely mark the SERVER as buggy, close = the connection and not try to reconnect for a period of time or use = another SERVER if available. A RETRY DELAY isn=E2=80=99t applicable and = the CLIENT can close the connection either with a TCP RST or a TLS = close_notify. The consensus seems to be to send a TCP RST in this = case.

In case 2, = the SERVER should send a RETRY DELAY TLV and then send a TLS = close_notify or it could wait for the CLIENT to close_notify or RST but = the SERVER shouldn=E2=80=99t RST because it wants the CLIENT to get the = RETRY DELAY.

There are = also cases where the server sends a RETRY DELAY TLV because of a = SUBSCRIBE error and the CLIENT is supposed to close the connection. = However, if the CLIENT does not close the connection, the SERVER may = choose to close it in which case it should close with TLS close_notify = to make sure the RETRY DELAY is received.

I think it would be better for the CLIENT to try to send a = TLS close_notify after receiving a RETRY DELAY so it can resume later = especially in the cases when a SUBSCRIBE = fails.

Given= David=E2=80=99s points, I don=E2=80=99t think there=E2=80=99s any = reason to send a RETRY DELAY in case 2.   It should be handled the = same as the other =E2=80=9Cprotocol error=E2=80=9D cases.  Can you = think of a reason why case 2 is different, other than that it=E2=80=99s = the one case where it=E2=80=99s possible to send a RETRY DELAY? =  Bear in mind that it is a protocol = error for the client to send a duplicate subscribe: it means = that the client=E2=80=99s internal state is not being tracked correctly. =   So it=E2=80=99s not a recoverable error.  We don=E2=80=99t = want the client to reconnect.

Additionally, as you=E2=80=99ve pointed = out, although the server could send the client a RETRY DELAY, if the = client isn=E2=80=99t following the spec in one context there=E2=80=99s = no particular reason to expect it to follow the spec in another.   = Requiring the server to have special heuristics to follow in the case of = broken clients seems to be creating an unreasonable burden.


The SERVER may want to conserve resources = from broken clients. The RETRY DELAY is for the SERVER=E2=80=99s = protection and it=E2=80=99s thoughtfully informing the CLIENT how long = it has to wait before the SERVER will accept a connection from it. It = doesn=E2=80=99t matter if the CLIENT agrees or not or whether the CLIENT = follows the spec or not.

Tom

= --Apple-Mail=_46CCAA12-F964-465A-83C1-5E7129210CDC-- From nobody Thu Jul 11 16:31:57 2019 Return-Path: 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 A14DF120182 for ; Thu, 11 Jul 2019 16:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 k9ADWkdhHG6f for ; Thu, 11 Jul 2019 16:31:54 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 10E7E12016B for ; Thu, 11 Jul 2019 16:31:53 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id m14so5060230qka.10 for ; Thu, 11 Jul 2019 16:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EnOEV60aYGQPgoapxQ7F5YGZ9++ecAShHEhHGWxceVY=; b=k5Av0fF97dTEqPUtCObNvFSq7Ff20dq3VQT59NAjIN3LnlEx2bF7umaa89UVuJnPBd 9UJH6IonzYHSzGmk9uGBE1N4soDmxOdA98kaBYb9tfWZCNRmdTz5QQvqYRvpBqr/BzvV cDLQ4vN5iHaqAeC0/zQ4DN7uOt5hi8jsp6Y/0hxpESsvCKuHfPzmoWi0Wh/OKqaTscVD 6yIUbBH+bttL5Ccjqnt1uPY7iK6fkLDr/81EuoIjU2gd0ioLNnJmmwTvXBL2ycNffeCk FoXiaaQgFzp2COI3zzqxwA3Ffllkzwk0MBCFPFg75Cgv8xH+tcTM+t7ho9g9RsJ1UKaO cNYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EnOEV60aYGQPgoapxQ7F5YGZ9++ecAShHEhHGWxceVY=; b=bQpjNkzyN79a4jAXStzSGKuGR9QIHs2M6NEQ55iiSXb8jV2QqSFhWbMJ3Q4rUBjJBh +/1Ebs70d6t0AvN1u/jnhLh8IC46aeaRtqwBppkFhdebV9mZwul5W7RwVDpjBZ3z3MGG jSmAxrr5CJHY1dj05RwOMd4uiXvWzhwIa7lRM3vK1vKBdriZHX/g2aBIRAEqOnEdNQht QL4dLXXMdKmoLn0/5pUoHHH/bGJsN1h8t6UWT8nm0HhNo3IdLInL6wGUR7RfKCaV82ef xsk6IEe8LvR07m/paJ/nnOH8SNDOz18S2XW71oZcR7hMxyi57F/7HLxbDxZyyQ2Zjoln Y3Cg== X-Gm-Message-State: APjAAAXpR1IvKMz+5LFhFPsFzx3f0tWz2y1JZjksa35zc/QbLc+W9m0f i8+TSrhcGbAMgIsbl+pRPFyRMw== X-Google-Smtp-Source: APXvYqzM4bAIwKELVP9isgS841AP+oB4lTXOHrEWtoeUxGyP1GJwpQmBkBvHUaKYcg/XPSLnvj1ClA== X-Received: by 2002:a37:d95:: with SMTP id 143mr3884849qkn.132.1562887912097; Thu, 11 Jul 2019 16:31:52 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:1414:e90b:150f:bd61? ([2001:470:c1a2:1:1414:e90b:150f:bd61]) by smtp.gmail.com with ESMTPSA id v28sm2646201qkj.11.2019.07.11.16.31.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 16:31:51 -0700 (PDT) From: Ted Lemon Message-Id: <60198834-66F0-4CF0-BB09-B987684F3616@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8F54A151-5562-45D6-BB4E-A5DADED5F4AE" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 19:31:49 -0400 In-Reply-To: Cc: Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Robert Sparks To: Tom Pusateri References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> <83331D7B-2853-4B5B-8350-ACD18922780E@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 23:31:56 -0000 --Apple-Mail=_8F54A151-5562-45D6-BB4E-A5DADED5F4AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 11, 2019, at 7:03 PM, Tom Pusateri wrote: > The SERVER may want to conserve resources from broken clients. The = RETRY DELAY is for the SERVER=E2=80=99s protection and it=E2=80=99s = thoughtfully informing the CLIENT how long it has to wait before the = SERVER will accept a connection from it. It doesn=E2=80=99t matter if = the CLIENT agrees or not or whether the CLIENT follows the spec or not. Okay, so we have the following scenarios: 1. Server sends RETRY-DELAY, client honors it. Result: client goes = away for a long time and does polling instead of push. Behavior on = client is not great, but probably won=E2=80=99t be noticed by a typical = end-user other than as an inexplicable inconvenience. Vendor will have = no strong motivation to fix. 2. Server sends RETRY-DELAY, client ignores it. Result: whatever broken = behavior the client exhibits, up to and including back-to-back = reconnects. UX may degrade substantially: in particular, this will = affect battery life for mobile devices. Practically speaking, in this = case the vendor will be motivated to fix. 3. Server sends RST. Result: same as 2. So the question is, do we want outcome (1) or outcome (2)? --Apple-Mail=_8F54A151-5562-45D6-BB4E-A5DADED5F4AE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 11, 2019, at 7:03 PM, Tom Pusateri <pusateri@bangj.com> = wrote:
The SERVER may want to conserve resources from broken clients. = The RETRY DELAY is for the SERVER=E2=80=99s protection and it=E2=80=99s = thoughtfully informing the CLIENT how long it has to wait before the = SERVER will accept a connection from it. It doesn=E2=80=99t matter if = the CLIENT agrees or not or whether the CLIENT follows the spec or = not.

Okay, so we have = the following scenarios:

1. Server = sends RETRY-DELAY, client honors it.   Result: client goes away for = a long time and does polling instead of push.  Behavior on client = is not great, but probably won=E2=80=99t be noticed by a typical = end-user other than as an inexplicable inconvenience.   Vendor will = have no strong motivation to fix.
2. Server sends RETRY-DELAY, = client ignores it.  Result: whatever broken behavior the client = exhibits, up to and including back-to-back reconnects.  UX may = degrade substantially: in particular, this will affect battery life for = mobile devices.  Practically speaking, in this case the vendor will = be motivated to fix.
3. Server sends RST.   Result: same = as 2.

So the question is, do we want = outcome (1) or outcome (2)?

= --Apple-Mail=_8F54A151-5562-45D6-BB4E-A5DADED5F4AE-- From nobody Thu Jul 11 16:39:27 2019 Return-Path: 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 186C7120041; Thu, 11 Jul 2019 16:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qnyERsVCKqZ3; Thu, 11 Jul 2019 16:39:24 -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 1CB7E12006A; Thu, 11 Jul 2019 16:39:24 -0700 (PDT) Received: from [192.168.1.13] (71-15-27-6.dhcp.hlrg.nc.charter.com [71.15.27.6]) (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 CF79A347E1; Thu, 11 Jul 2019 19:39:22 -0400 (EDT) From: Tom Pusateri Message-Id: <680C7A57-BBF9-4AD5-9E51-AA101CDDC751@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_BF384444-11CC-418A-893D-F89D239C1ED6" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Date: Thu, 11 Jul 2019 19:39:21 -0400 In-Reply-To: <60198834-66F0-4CF0-BB09-B987684F3616@fugue.com> Cc: Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Robert Sparks To: Ted Lemon References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> <83331D7B-2853-4B5B-8350-ACD18922780E@fugue.com> <60198834-66F0-4CF0-BB09-B987684F3616@fugue.com> X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 23:39:26 -0000 --Apple-Mail=_BF384444-11CC-418A-893D-F89D239C1ED6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 11, 2019, at 7:31 PM, Ted Lemon wrote: >=20 > On Jul 11, 2019, at 7:03 PM, Tom Pusateri > wrote: >> The SERVER may want to conserve resources from broken clients. The = RETRY DELAY is for the SERVER=E2=80=99s protection and it=E2=80=99s = thoughtfully informing the CLIENT how long it has to wait before the = SERVER will accept a connection from it. It doesn=E2=80=99t matter if = the CLIENT agrees or not or whether the CLIENT follows the spec or not. >=20 > Okay, so we have the following scenarios: >=20 > 1. Server sends RETRY-DELAY, client honors it. Result: client goes = away for a long time and does polling instead of push. Behavior on = client is not great, but probably won=E2=80=99t be noticed by a typical = end-user other than as an inexplicable inconvenience. Vendor will have = no strong motivation to fix. > 2. Server sends RETRY-DELAY, client ignores it. Result: whatever = broken behavior the client exhibits, up to and including back-to-back = reconnects. UX may degrade substantially: in particular, this will = affect battery life for mobile devices. Practically speaking, in this = case the vendor will be motivated to fix. > 3. Server sends RST. Result: same as 2. >=20 > So the question is, do we want outcome (1) or outcome (2)? >=20 There is no back to back reconnect in the #2 case. The server = shouldn=E2=80=99t accept the connection after sending a RETRY DELAY to = this client. The client may ignore the RETRY DELAY but this doesn=E2=80=99= t matter. It=E2=80=99s only a courtesy that the SERVER tells the client = how long it has to wait. So #1 and #2 are the same. The server gets abused if it does #3. It should always send the RETRY = DELAY to protect itself. Tom= --Apple-Mail=_BF384444-11CC-418A-893D-F89D239C1ED6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 11, 2019, at 7:31 PM, Ted Lemon <mellon@fugue.com> = wrote:

On Jul 11, 2019, at = 7:03 PM, Tom Pusateri <pusateri@bangj.com> wrote:
The SERVER may = want to conserve resources from broken clients. The RETRY DELAY is for = the SERVER=E2=80=99s protection and it=E2=80=99s thoughtfully informing = the CLIENT how long it has to wait before the SERVER will accept a = connection from it. It doesn=E2=80=99t matter if the CLIENT agrees or = not or whether the CLIENT follows the spec or = not.

Okay, = so we have the following scenarios:

1. Server sends RETRY-DELAY, client = honors it.   Result: client goes away for a long time and does = polling instead of push.  Behavior on client is not great, but = probably won=E2=80=99t be noticed by a typical end-user other than as an = inexplicable inconvenience.   Vendor will have no strong motivation = to fix.
2. Server sends RETRY-DELAY, client ignores = it.  Result: whatever broken behavior the client exhibits, up to = and including back-to-back reconnects.  UX may degrade = substantially: in particular, this will affect battery life for mobile = devices.  Practically speaking, in this case the vendor will be = motivated to fix.
3. Server sends RST.   = Result: same as 2.

So the question is, do we want outcome (1) or outcome = (2)?



There is no back to back = reconnect in the #2 case. The server shouldn=E2=80=99t accept the = connection after sending a RETRY DELAY to this client. The client may = ignore the RETRY DELAY but this doesn=E2=80=99t matter. It=E2=80=99s = only a courtesy that the SERVER tells the client how long it has to = wait.

So #1 = and #2 are the same.

The server gets abused if it does #3. It should always send = the RETRY DELAY to protect itself.

Tom
= --Apple-Mail=_BF384444-11CC-418A-893D-F89D239C1ED6-- From nobody Thu Jul 11 16:40:05 2019 Return-Path: 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 5365012007A; Thu, 11 Jul 2019 16:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 NgoFowUBLAZz; Thu, 11 Jul 2019 16:40:03 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8628120041; Thu, 11 Jul 2019 16:40:02 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x6BNbecV022743; Thu, 11 Jul 2019 16:39:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=vVs0Yk8FY6FpyP9vvxAy7j9pNBA6zF28CQEfTLjrzs8=; b=H8Xvh71OsZ0dWbKwLWNrkP6zuy6oEJQKByyuZJrvED95R0DcZ3yUj2XcgzaBUflaP69R Po4x70iiPr/B29cp+NrxXI2Bihh9LwuQRPE00Je1ZFEZjUkCqmAWQHCS3ihlTqrSM9Zq UcxyNelWUbn6hzU2oX4L6Uch/GzflH91OD5rdK4JiO0ZAom+vAYewTDZQOo8VrwEaFjy hbR+Cy89p2lyfYRRF8yntdUIvG96pvT7/hN+pMK6hBjn+9X5B8GU+4rr3ppunxklatv5 /2JiihMDBul4isfuKPRk4wlFS+ywZVKuahSc/eAqQi89sCqlq0CIX2ioUkOeG1kAjCKb 2w== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2tjray5d06-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Jul 2019 16:39:58 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PUI00ESE4ELG0D0@mr2-mtap-s03.rno.apple.com>; Thu, 11 Jul 2019 16:39:57 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PUI000004AA3100@nwk-mmpp-sz10.apple.com>; Thu, 11 Jul 2019 16:39:57 -0700 (PDT) X-Va-A: X-Va-T-CD: daaeb3c9f137f7e0b5f8eb48c7abe785 X-Va-E-CD: 3c579badc8061719d024feec5a8178fb X-Va-R-CD: dac62b87d893430a0308504ef8763cad X-Va-CD: 0 X-Va-ID: a92f4f5d-4583-41d8-a462-fa42ea186ae3 X-V-A: X-V-T-CD: daaeb3c9f137f7e0b5f8eb48c7abe785 X-V-E-CD: 3c579badc8061719d024feec5a8178fb X-V-R-CD: dac62b87d893430a0308504ef8763cad X-V-CD: 0 X-V-ID: a11246a8-c377-4c2d-bf14-971060715418 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-07-11_07:,, signatures=0 Received: from [17.192.139.245] (unknown [17.192.139.245]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PUI00MGD4EKYMB0@nwk-mmpp-sz10.apple.com>; Thu, 11 Jul 2019 16:39:56 -0700 (PDT) Sender: cheshire@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Stuart Cheshire In-reply-to: Date: Thu, 11 Jul 2019 16:39:54 -0700 Cc: Ted Lemon , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Robert Sparks Content-transfer-encoding: quoted-printable Message-id: <6CCF9E3C-A153-401B-B5A7-5877FFFB4A85@apple.com> References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> To: Tom Pusateri X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-11_07:, , signatures=0 Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 23:40:05 -0000 On 11 Jul 2019, at 14:46, Tom Pusateri wrote: > 1. CLIENT receives SUBSCRIBE from server > 3. CLIENT receives PUSH with no change notifications > 4. CLIENT receives PUSH notification with =E2=80=98collective = remove=E2=80=99 TTL and non-zero RDLEN > 5. CLIENT receives PUSH notification with DNS message length larger = than 16k > 6. CLIENT receives UNSUBSCRIBE from SERVER Reviewing the list above, I realize that we state explicitly that = SUBSCRIBE and UNSUBSCRIBE sent from server are both invalid. But we = don=E2=80=99t enumerate the other bogus message directions. I have added some clarifying text around this, and will submit an = updated draft once they open for submissions again. Not that it was = every really unclear, but it doesn=E2=80=99t hurt to be abundantly = unambiguous. I have added: A server MUST NOT send a RECONFIRM message. A client MUST NOT send a SUBSCRIBE response. A client MUST NOT send a PUSH message. All three are fatal errors of the =E2=80=9Cthis should never ever = happen=E2=80=9D variety. Stuart Cheshire From nobody Thu Jul 11 17:32:36 2019 Return-Path: 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 BC956120155 for ; Thu, 11 Jul 2019 17:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 N7gTkR5KZisQ for ; Thu, 11 Jul 2019 17:32:32 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 6EDFD12009C for ; Thu, 11 Jul 2019 17:32:32 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id l9so6407924qtu.6 for ; Thu, 11 Jul 2019 17:32:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zFef4VNLqwF/7AA40P2uB2eiNiZqLBOIX9F0iyRFHO4=; b=TPo7nHD8h/KwBBeCDLxFzqe+PftabXezHtM/dDBdvPzc0tKLYdEE9qg0Rph8EgYsjr IelS55zb5w6ccBnqasi1oeiDbuUmV1go5bxQ1e+2du2Oy0GQ9g03Fl9LLfeBbG2WY0+y FkQL5KpKowFIW5Nk2JR0vK4j8HlyL/STmYbVhUJ8YOQp1/iAo1gGGbglAcIa4NcSTjMn z1jZkHkoyeElYyd7qay5T9Mov+F04Eo/H83BQkGU2T3IldkY8/rWM/hcjBQ4DuXqPfnY paNXkjyPe51VrfNtf9rKh4i6xqN8vYbCN+Ei6gPr0AwzicFA+Na1XvUQiKVj5DaNGLAN NQ0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=zFef4VNLqwF/7AA40P2uB2eiNiZqLBOIX9F0iyRFHO4=; b=H6EIwz4JT7C4Av0MuwbtJ0Q8hzE8E/iQmAdbL8Qc4TCZ3JAZDynwIq2CunAg1AhIzz O1e/ZviPso4bCwy1wKHCginKADk0kyN+tSTEhiDGiIwq2+AtS9Qea4Sy7+mC65xSpSGS b+xWN3ex53s4bskxxt1ULbkBPmp+STZ2iy1mYH6X3TUo8u9Kvr9wZWlsDlmoa7YAH3SA gfm1rZBrQLipkRCCMyJCZNTm9K+4+lzf453XMZCgPjt+4n7tvG9nlujnpoGm3IhGpSm4 x9iI6jaoigyDdOYFcyHxpQ6yC8cv5kxVGsuwpAEz7n2ozEJciQbIQYEeodrrJ7ZUVcxx Tw5Q== X-Gm-Message-State: APjAAAXjfKA4tWtaQFxIYtQawfLRSe7z5X7+VDSwGZjK1kv4HNPpAOP2 dEEfeT7Q9F3bYt3RrfCtOtw/6A== X-Google-Smtp-Source: APXvYqzF7PpTiM/8oDlXwD2V9XP7xK191GROEOjptsEeGFruhxEHHPNf2R53IKb1yVq/J085McfoUw== X-Received: by 2002:a0c:ad6f:: with SMTP id v44mr4344994qvc.40.1562891551474; Thu, 11 Jul 2019 17:32:31 -0700 (PDT) Received: from ?IPv6:2001:470:c1a2:1:1414:e90b:150f:bd61? ([2001:470:c1a2:1:1414:e90b:150f:bd61]) by smtp.gmail.com with ESMTPSA id f25sm3362893qta.81.2019.07.11.17.32.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 17:32:30 -0700 (PDT) From: Ted Lemon Message-Id: <56174A38-0D4A-4E77-BC30-3F99534C7337@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_987AC539-3ED2-4967-AA6E-1FE30766332E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 11 Jul 2019 20:32:26 -0400 In-Reply-To: <680C7A57-BBF9-4AD5-9E51-AA101CDDC751@bangj.com> Cc: Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Robert Sparks To: Tom Pusateri References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> <83331D7B-2853-4B5B-8350-ACD18922780E@fugue.com> <60198834-66F0-4CF0-BB09-B987684F3616@fugue.com> <680C7A57-BBF9-4AD5-9E51-AA101CDDC751@bangj.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 00:32:35 -0000 --Apple-Mail=_987AC539-3ED2-4967-AA6E-1FE30766332E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jul 11, 2019, at 7:39 PM, Tom Pusateri wrote: > There is no back to back reconnect in the #2 case. The server = shouldn=E2=80=99t accept the connection after sending a RETRY DELAY to = this client. The client may ignore the RETRY DELAY but this doesn=E2=80=99= t matter. It=E2=80=99s only a courtesy that the SERVER tells the client = how long it has to wait. I don=E2=80=99t know how the server refuses connections on a per-client = basis. We certainly don=E2=80=99t describe how to do that in the DSO = RFC. Practically speaking, unless the server is maintaining a list of = all the clients that connect to it, it has no idea that client X that it = just dropped is client Y that just connected. Even if it does maintain = such a list, it would be unusual for that to allow it to actually drop = the connection immediately. And supposing it does, that might just = make the client reconnect a bit faster. That is, if the SYN gets an = RST in response, the client will just get -1 from connect() and call = connect() again unless it has some kind of backoff strategy. --Apple-Mail=_987AC539-3ED2-4967-AA6E-1FE30766332E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Jul 11, 2019, at 7:39 PM, Tom Pusateri <pusateri@bangj.com> = wrote:
There is no back to back reconnect in the #2 case. The server = shouldn=E2=80=99t accept the connection after sending a RETRY DELAY to = this client. The client may ignore the RETRY DELAY but this doesn=E2=80=99= t matter. It=E2=80=99s only a courtesy that the SERVER tells the client = how long it has to wait.

I don=E2=80=99t know how the server refuses = connections on a per-client basis.   We certainly don=E2=80=99t = describe how to do that in the DSO RFC.  Practically speaking, = unless the server is maintaining a list of all the clients that connect = to it, it has no idea that client X that it just dropped is client Y = that just connected.   Even if it does maintain such a list, it = would be unusual for that to allow it to actually drop the connection = immediately.   And supposing it does, that might just make the = client reconnect a bit faster.   That is, if the SYN gets an RST in = response, the client will just get -1 from connect() and call connect() = again unless it has some kind of backoff strategy.


= --Apple-Mail=_987AC539-3ED2-4967-AA6E-1FE30766332E-- From nobody Thu Jul 11 17:32:46 2019 Return-Path: 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 4683512011B; Thu, 11 Jul 2019 17:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cBdJBhUJcExk; Thu, 11 Jul 2019 17:32:34 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 519601200C7; Thu, 11 Jul 2019 17:32:34 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id p17so7617126ljg.1; Thu, 11 Jul 2019 17:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FlAFn65gGGe1zMJz/Mzp5fViLkHj+NVL3aqANuDiArA=; b=nIR5XHy/Fc9v4WFYNljLdqeX3F/bGK+x0jRPKbP4nTuirJfb5aO6XmeCJlWqkuRjcB wkPb/xgjOtw+0Ykq8DqWFwZdzEIYiGz9GCakS4Sc32U1T7Qzv7PxiqkvCUIqKWw8b6+H FCzN7SVWCr3xEeWmUgweFkivN6hjFHMMp+ctxvozxZFPndAurWKxQCcH4uagdyXDQLmB x7YGfDRNfHOZGz3nixX3DY2fNEVoCYIJEDlWBG/fBoYXqQTUUzLLJljv7io6m3RjmYQ5 nSEOumiLR2NYO6fznxOjZyk9UabQJhthuLSGIyJC7jfchWh7OjsRe2F47LiNyamkSFDi xFjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FlAFn65gGGe1zMJz/Mzp5fViLkHj+NVL3aqANuDiArA=; b=Scwj/1TwUym//XLcnuz0ugrwnMekyq5JqQ8AJskwSIv+ZKsag8Qr/Ftyceonvkndq8 t2BncejwBYgm1/RC1o9SzCLMr62J+IzUVt8ex1gqUMBeQV+/oAqJTmCXd+oAKwzutaP/ LtcJAZHBNO1yMjMNz3X6Uxr/d7YBVXKR4x5tVJhX6E6aJR3C5JWvQp3EjesD/I4Q4O8g wCFjhKLeHv73YaljalcEoDXZApNrYi3IVSH5MbCgOCm2Kh09tBGIjVh+L9Ck72fyW7Nv zkjZ7ldM7gF2O7diSS7piHPyIOqGC0eWma81qzHsu0MClqqCcq1mumFX6O8yQHg3rEiJ t9Qw== X-Gm-Message-State: APjAAAV67jZYETQRJm0n8VMhsr65ncKX22gSdA6kK8HdL4kc2h+1GROw GLxnhJNw3rsXucGp58Nk3/ZLdTtCkkYA1m/hCCs= X-Google-Smtp-Source: APXvYqyEzcK6bB5iSgnjlqpg4Hcx67suBrsSPJUjV71a0Dw61I8VqrznluYdUQH5Sf8g9KYwZN8xWRMGILMWAFpWwVk= X-Received: by 2002:a2e:94cb:: with SMTP id r11mr3972865ljh.212.1562891552512; Thu, 11 Jul 2019 17:32:32 -0700 (PDT) MIME-Version: 1.0 References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> <6CCF9E3C-A153-401B-B5A7-5877FFFB4A85@apple.com> In-Reply-To: <6CCF9E3C-A153-401B-B5A7-5877FFFB4A85@apple.com> From: David Schinazi Date: Thu, 11 Jul 2019 17:32:21 -0700 Message-ID: To: Stuart Cheshire Cc: Tom Pusateri , Ted Lemon , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, Robert Sparks Content-Type: multipart/alternative; boundary="000000000000cf6018058d710b85" Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 00:32:37 -0000 --000000000000cf6018058d710b85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, You wrote: > There is no back to back reconnect in the #2 case. The server shouldn=E2= =80=99t > accept the connection after sending a RETRY DELAY to this client. The > client may ignore the RETRY DELAY but this doesn=E2=80=99t matter. It=E2= =80=99s only a > courtesy that the SERVER tells the client how long it has to wait. When you say that the server shouldn't accept the second connection, how does the server know that the new connection comes from the same client? Unless you're using TLS client certificates, you have no way of differentiating clients because of NAT. Or am I missing something? Thanks, David On Thu, Jul 11, 2019 at 4:40 PM Stuart Cheshire wrote: > On 11 Jul 2019, at 14:46, Tom Pusateri wrote: > > > 1. CLIENT receives SUBSCRIBE from server > > 3. CLIENT receives PUSH with no change notifications > > 4. CLIENT receives PUSH notification with =E2=80=98collective remove=E2= =80=99 TTL and > non-zero RDLEN > > 5. CLIENT receives PUSH notification with DNS message length larger tha= n > 16k > > 6. CLIENT receives UNSUBSCRIBE from SERVER > > Reviewing the list above, I realize that we state explicitly that > SUBSCRIBE and UNSUBSCRIBE sent from server are both invalid. But we don= =E2=80=99t > enumerate the other bogus message directions. > > I have added some clarifying text around this, and will submit an updated > draft once they open for submissions again. Not that it was every really > unclear, but it doesn=E2=80=99t hurt to be abundantly unambiguous. I have= added: > > A server MUST NOT send a RECONFIRM message. > A client MUST NOT send a SUBSCRIBE response. > A client MUST NOT send a PUSH message. > > All three are fatal errors of the =E2=80=9Cthis should never ever happen= =E2=80=9D variety. > > Stuart Cheshire > > --000000000000cf6018058d710b85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

You wrote:
There is no back to back reconnect in th= e #2 case. The server shouldn=E2=80=99t accept the connection after sending= a RETRY DELAY to this client. The client may ignore the RETRY DELAY but th= is doesn=E2=80=99t matter. It=E2=80=99s only a courtesy that the SERVER tel= ls the client how long it has to wait.

When= you say that the server shouldn't accept the second connection, how do= es the server know that the new connection comes from the same client? Unle= ss you're using TLS client certificates, you have no way of differentia= ting clients because of NAT. Or am I missing something?

Thanks,
David
=C2=A0

On Thu, Jul 11, 2019 at= 4:40 PM Stuart Cheshire <cheshire= @apple.com> wrote:
On 11 Jul 2019, at 14:46, Tom Pusateri <pusateri@bangj.com> wrote:

> 1. CLIENT receives SUBSCRIBE from server
> 3. CLIENT receives PUSH with no change notifications
> 4. CLIENT receives PUSH notification with =E2=80=98collective remove= =E2=80=99 TTL and non-zero RDLEN
> 5. CLIENT receives PUSH notification with DNS message length larger th= an 16k
> 6. CLIENT receives UNSUBSCRIBE from SERVER

Reviewing the list above, I realize that we state explicitly that SUBSCRIBE= and UNSUBSCRIBE sent from server are both invalid. But we don=E2=80=99t en= umerate the other bogus message directions.

I have added some clarifying text around this, and will submit an updated d= raft once they open for submissions again. Not that it was every really unc= lear, but it doesn=E2=80=99t hurt to be abundantly unambiguous. I have adde= d:

A server MUST NOT send a RECONFIRM message.
A client MUST NOT send a SUBSCRIBE response.
A client MUST NOT send a PUSH message.

All three are fatal errors of the =E2=80=9Cthis should never ever happen=E2= =80=9D variety.

Stuart Cheshire

--000000000000cf6018058d710b85-- From nobody Thu Jul 11 17:56:32 2019 Return-Path: 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 4AC1C1200C7; Thu, 11 Jul 2019 17:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 2vod9HmUH1Xk; Thu, 11 Jul 2019 17:56:27 -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 75CC3120086; Thu, 11 Jul 2019 17:56:27 -0700 (PDT) Received: from [172.16.25.146] (69-77-155-155.static.skybest.com [69.77.155.155]) (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 261C3347FA; Thu, 11 Jul 2019 20:56:26 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_29554589-F267-44E4-95C1-ACC0BD02656F" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3564\)) Date: Thu, 11 Jul 2019 20:56:25 -0400 In-Reply-To: <56174A38-0D4A-4E77-BC30-3F99534C7337@fugue.com> Cc: Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Robert Sparks To: Ted Lemon References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> <83331D7B-2853-4B5B-8350-ACD18922780E@fugue.com> <60198834-66F0-4CF0-BB09-B987684F3616@fugue.com> <680C7A57-BBF9-4AD5-9E51-AA101CDDC751@bangj.com> <56174A38-0D4A-4E77-BC30-3F99534C7337@fugue.com> X-Mailer: Apple Mail (2.3564) Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 00:56:31 -0000 --Apple-Mail=_29554589-F267-44E4-95C1-ACC0BD02656F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 11, 2019, at 8:32 PM, Ted Lemon wrote: >=20 > On Jul 11, 2019, at 7:39 PM, Tom Pusateri > wrote: >> There is no back to back reconnect in the #2 case. The server = shouldn=E2=80=99t accept the connection after sending a RETRY DELAY to = this client. The client may ignore the RETRY DELAY but this doesn=E2=80=99= t matter. It=E2=80=99s only a courtesy that the SERVER tells the client = how long it has to wait. >=20 > I don=E2=80=99t know how the server refuses connections on a = per-client basis. We certainly don=E2=80=99t describe how to do that = in the DSO RFC. Practically speaking, unless the server is maintaining = a list of all the clients that connect to it, it has no idea that client = X that it just dropped is client Y that just connected. Even if it = does maintain such a list, it would be unusual for that to allow it to = actually drop the connection immediately. And supposing it does, that = might just make the client reconnect a bit faster. That is, if the SYN = gets an RST in response, the client will just get -1 from connect() and = call connect() again unless it has some kind of backoff strategy. >=20 What is the point of the server sending a RETRY DELAY TLV if it isn=E2=80=99= t going to enforce it? The purpose of the RETRY DELAY TLV isn=E2=80=99t to say please be nice = and wait. It=E2=80=99s to say, I=E2=80=99ve put this filter in place that I am = enforcing for this period of time. You might as well wait until you try = to connect again because it won=E2=80=99t do any good to try before the = timer expires. So, yes, you have to keep state when you send a RETRY DELAY. When the = timer fires, you remove the filter and allow the connection to proceed. = You have state for the current connections and you have state for the = RETRY DELAY timers you have running. SYN attacks happen and those are = dealt with like any other SYN attack. As for NAT, you=E2=80=99re going to block everyone coming from the same = address. You should use IPv6 if you=E2=80=99re remote and don=E2=80=99t = want to get blocked because of a bad actor. If you don=E2=80=99t filter, you might was well not send a RETRY DELAY = because the clients you=E2=80=99re trying to throttle are the ones that = are going to ignore it. Tom= --Apple-Mail=_29554589-F267-44E4-95C1-ACC0BD02656F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 11, 2019, at 8:32 PM, Ted Lemon <mellon@fugue.com> = wrote:

On Jul 11, 2019, at = 7:39 PM, Tom Pusateri <pusateri@bangj.com> wrote:
There is no back = to back reconnect in the #2 case. The server shouldn=E2=80=99t accept = the connection after sending a RETRY DELAY to this client. The client = may ignore the RETRY DELAY but this doesn=E2=80=99t matter. It=E2=80=99s = only a courtesy that the SERVER tells the client how long it has to = wait.

I = don=E2=80=99t know how the server refuses connections on a per-client = basis.   We certainly don=E2=80=99t describe how to do that in the = DSO RFC.  Practically speaking, unless the server is maintaining a = list of all the clients that connect to it, it has no idea that client X = that it just dropped is client Y that just connected.   Even if it = does maintain such a list, it would be unusual for that to allow it to = actually drop the connection immediately.   And supposing it does, = that might just make the client reconnect a bit faster.   That is, = if the SYN gets an RST in response, the client will just get -1 from = connect() and call connect() again unless it has some kind of backoff = strategy.


What = is the point of the server sending a RETRY DELAY TLV if it isn=E2=80=99t = going to enforce it?

The purpose of = the RETRY DELAY TLV isn=E2=80=99t to say please be nice and = wait.

It=E2=80=99s to say, I=E2=80=99v= e put this filter in place that I am enforcing for this period of time. = You might as well wait until you try to connect again because it won=E2=80= =99t do any good to try before the timer expires.

So, yes, you have to keep state when you send a = RETRY DELAY. When the timer fires, you remove the filter and allow the = connection to proceed. You have state for the current connections and = you have state for the RETRY DELAY timers you have running. SYN attacks = happen and those are dealt with like any other SYN attack.

As for NAT, you=E2=80=99re going to block everyone = coming from the same address. You should use IPv6 if you=E2=80=99re = remote and don=E2=80=99t want to get blocked because of a bad = actor.

If you don=E2=80=99t filter, = you might was well not send a RETRY DELAY because the clients you=E2=80=99= re trying to throttle are the ones that are going to ignore = it.

Tom
= --Apple-Mail=_29554589-F267-44E4-95C1-ACC0BD02656F-- From nobody Thu Jul 11 21:43:26 2019 Return-Path: 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 5CF4D120182 for ; Thu, 11 Jul 2019 21:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 AEAqZR_ijmIU for ; Thu, 11 Jul 2019 21:43:22 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (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 0D4DA120168 for ; Thu, 11 Jul 2019 21:43:22 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id 16so7977740ljv.10 for ; Thu, 11 Jul 2019 21:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mK1/H9Oo1KBE0RZYsDmzGWRrT/z0H2JVpGOKe2yZ1Vs=; b=cWNtCKP7lMNvApWItym5UqTqkful0DbFMoMy5huxfFJXJbDSdcx6cBTOECHsTR74LS uCFWtAW5oTO5whdKxCYPP1OkqAn+zcWuTgshlvDUP72Dj9DD84uKz4aRD0KGK7Qd8f2Y Xt4mPPP2gTiQFTqexy1duw3vRppNPMnab6iQhXwqBNpihlvcQ8Qy7sUtikZaKW3wPh84 Ms7vxTgNl6rxF7EmyxeN+B9HeC7F76BCWydFSsDYXhbCjBBvKGcSAsbGeg1eU+DPis/Q k9LDN2SdZbQBiiDgfe0EVL8GHXhOYajFKyvG1i6sA756pOgbf+76bQpdxCJWTKjbnxXf PrGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mK1/H9Oo1KBE0RZYsDmzGWRrT/z0H2JVpGOKe2yZ1Vs=; b=rf7w+n0jAtnM2O9DjjIGYSw1HMSEJi71EIzbkmQI/Vf/pCEs83s5OzbLMFSyYDZnB8 oxTV2m1hWH8aYOr1VWmTGVPflifyiDnjPy374FZ6MhEm2b+VL0JRff/IleTQwsWwAqXs xlxevYX7EzhUBzR1ylEMWr/DMSbjQmnfTx1IkPudRIJUyFXRWSNL+EJ4FNPPiySUxgQD jj1FH8BWxhH/NjqMZSK1W3tFme/AG+SNaUlk0EpMzKi9OFcoAFnlFZ+51WdYpiGcXWw2 KvLt7jebELfgU2ntTRrwIz1gtW1X2jIrhLT6CA7pZlRFvn3cxV7K83/CMPAZhDyhExmB 8J6Q== X-Gm-Message-State: APjAAAUh+2o33151Df+6phdi8HHv/E/XQbZl0Vdzc/tuSmKZ4M1WVH4t wCli38UjUOwOcOa0dxwXwzqIzXPdkchp8VqESv4= X-Google-Smtp-Source: APXvYqy22gG+wYPmaScycj+J+yKNiMw0aexWs9NNBeush2pks+niCr0CJBSIp6LMmBxlrGGmu7CCY4P0SGR/Rx13FGg= X-Received: by 2002:a2e:9b84:: with SMTP id z4mr4646007lji.75.1562906600306; Thu, 11 Jul 2019 21:43:20 -0700 (PDT) MIME-Version: 1.0 References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> In-Reply-To: From: Eric Rescorla Date: Thu, 11 Jul 2019 21:42:42 -0700 Message-ID: To: David Schinazi Cc: Tom Pusateri , Ted Lemon , Stuart Cheshire , DNSSD , draft-ietf-dnssd-push.all@ietf.org, Robert Sparks Content-Type: multipart/alternative; boundary="000000000000ba8b3d058d748cb2" Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 04:43:25 -0000 --000000000000ba8b3d058d748cb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 11, 2019 at 2:44 PM David Schinazi wrote: > To reiterate my earlier point, TLS close_notify DOES NOT protect against > an attacker closing the connection by sending a FIN or RST. > Just to clarify: it allows the receiver to distinguish between closes which were initiated by the peer and those which were not The benefit of close_notify is to protect against truncation attacks: if an > attacker sends a FIN or RST in the middle of a stream, > the recipient application should ignore the current message instead of > considering it complete. > This is important for protocols such as HTTP/0.9 that rely on the TCP FIN > instead of using prefixed lengths. > Given that DSO messages contain a prefixed length, making sure > implementations do not act on partial messages is sufficient to prevent > truncation attacks. > If my understanding is correct, DNS-PUSH does not get ANY security > benefits from close_notify. > Well, maybe. You could, for instance, log an error if a finished was received without a close_notify. -Ekr > When a critical error occurs, a TCP RST should cause the other side to > tear down state more aggressively than a close_notify, which is what we > want. > > I'd recommend using close_notify for gracefully closes, and TCP RST for > any critical failures. > > I agree with Ted that if an implementation is broken it's best to have it > fail very visibly. > > David > > On Thu, Jul 11, 2019 at 11:20 AM Tom Pusateri wrote: > >> If a client implements PUSH, it implements DSO which means it implements >> KEEPALIVE and RETRY DELAY. >> >> That doesn=E2=80=99t mean it will honor every part and it might retry be= fore the >> delay expires. >> >> But the server sent the retry delay and knows the timeout value and so >> the server can filter this client for that period of time regardless of >> whether the client honors it or not. In fact, a server SHOULD do the >> filtering because the RETRY DELAY is really saying, I=E2=80=99m not goin= g to listen >> to you until after this timeout. >> >> Also, even if the client closes because of an error, that doesn=E2=80=99= t >> preclude it from using TLS session resumption for the next subscription. >> >> So I=E2=80=99m in favor of always using close_notify and sending a RETRY= DELAY >> for critical errors when needed. >> >> But I think it would be helpful to outline the actual errors that could >> occur on either end and verify this works in every case. Sending as much >> information to the other side as possible is helpful for determining bug= s. >> TCP RST signaling doesn=E2=80=99t convey much information. >> >> Tom >> >> On Jul 11, 2019, at 1:19 PM, Ted Lemon wrote: >> >> On Jul 9, 2019, at 10:22 PM, Stuart Cheshire < >> cheshire=3D40apple.com@dmarc.ietf.org> wrote: >> >> This is a fine observation. >> >> You then suggested changing TCP RST to TLS close_notify, not realizing >> (a) this is only for fatal errors, and (b) the precedent already set by = RFC >> 8490. >> >> We have in fact updated the document, but I think this was too hasty, an= d >> we should revert it back to the way it was before. >> >> If not, we at least need to have a thorough DNSSD Working Group >> discussion about this before making a last-minute change to the protocol= . >> >> >> To add some further nuance from a discussion that Stuart and I had today >> on this, there are actually several different cases where connection clo= ses >> are done, and how they should be done is something we should talk about. >> >> I think in all cases where the client is closing the connection, there= =E2=80=99s >> a case to be made that we *don=E2=80=99t* want to use close_notify. It= =E2=80=99s true >> that an attacker can kill our DNS Push connection in this case by forgin= g >> an RST to the server. We should discuss whether this is a serious conc= ern >> that we need to take into account. If it is, then using close_notify >> would protect against this iff the server ignores TCP RSTs for active TL= S >> sessions. >> >> But the main argument for using close_notify in this case is that we wan= t >> to be able to resume. This will not be the case if the client closed t= he >> connection because of a protocol error. It will be the case when the >> client is closing the connection due to inactivity. >> >> There is a case where the server closes the connection when the client >> sends a duplicate subscribe. That=E2=80=99s because this is a protocol= error: the >> client is broken, and cannot be expected to take corrective action. Th= en >> the question is, do we close the connection down with a retry-delay to m= ake >> the client go away, or do we just send an RST? >> >> Argument in favor of sending retry-delay: >> >> - if the client implements it, it will shut up for a while. >> >> >> Arguments against: >> >> - If the client doesn=E2=80=99t implement it, it won=E2=80=99t shut u= p, so we haven=E2=80=99t >> gained anything >> - Making things =E2=80=9Csort of work=E2=80=9D when the client is bro= ken isn=E2=80=99t all >> that helpful=E2=80=94we actually want the behavior in this case to be >> dysfunctional, so that it is noticed and fixed. >> >> >> I think that the working group should consider these issues and come to = a >> consensus. >> >> My own personal opinion is that we should always do close_notify, becaus= e >> if we can assume this, then an attacker can=E2=80=99t kill the connectio= n by >> sending an RST, if that behavior is implemented in the TLS/TCP stack. = My >> one doubt about this is that if we are going through a NAT, will the NAT >> drop its mapping when it sees the RST? If so, then close_notify doesn= =E2=80=99t >> protect against this attack for a majority of current users. It still >> might be worth doing for IPv6, of course. >> >> As to whether we should use retry-delay, I have really mixed feelings >> about this. I want implementations to be visibly broken when they are >> broken, but I don=E2=80=99t want to have to operate a server that has to= deal with >> broken clients. The question is whether forcibly disconnecting will >> actually cause implementors to take action, or whether it will not be >> noticed and contribute to dysfunction. >> >> My personal experience is that breaking badly is actually conducive to >> improvement, so that=E2=80=99s the direction I=E2=80=99m leaning at the = moment. >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> >> --000000000000ba8b3d058d748cb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 11, 2019 at 2:44 PM David= Schinazi <dschinazi.ietf@gm= ail.com> wrote:
To reiterate my earlier point, TLS close_notif= y DOES NOT protect against an attacker closing the connection by sending a = FIN or RST.

Just to clarify= : it allows the receiver to distinguish between closes which were initiated= by the peer and those which were not


The benefit of close_notify is to protect against truncation attacks:= if an attacker sends a FIN or RST in the middle of a stream,
the= recipient application should ignore the current message instead of conside= ring it complete.
This is important for protocols such as HTTP/0.= 9 that rely on the TCP FIN instead of using prefixed lengths.
Giv= en that DSO messages contain a prefixed length, making sure implementations= do not act on partial messages is sufficient to prevent truncation attacks= .
If my understanding=C2=A0is correct, DNS-PUSH does not get ANY = security benefits from close_notify.

<= /div>
Well, maybe. You could, for instance, log an error if a finished = was received without a close_notify.

-Ekr


When a critical error occurs, a TCP RST should caus= e the other side to tear down state more aggressively than a close_notify, = which is what we want.


<= br>
I'd recommend using close_notify for gracefully closes, a= nd TCP RST for any critical failures.

I agree with= Ted that if an implementation is broken it's best to have it fail very= visibly.

David

On Thu, Jul 11, 2019 at 11:20= AM Tom Pusateri <pusateri@bangj.com> wrote:
If a client implements PUSH, it implements DSO which means it implements= KEEPALIVE and RETRY DELAY.

That doesn=E2=80=99t mean it will honor every part and it might retry bef= ore the delay expires.

But= the server sent the retry delay and knows the timeout value and so the ser= ver can filter this client for that period of time regardless of whether th= e client honors it or not. In fact, a server SHOULD do the filtering becaus= e the RETRY DELAY is really saying, I=E2=80=99m not going to listen to you = until after this timeout.

= Also, even if the client closes because of an error, that doesn=E2=80=99t p= reclude it from using TLS session resumption for the next subscription.

So I=E2=80=99m in favor of al= ways using close_notify and sending a RETRY DELAY for critical errors when = needed.

But I think it wou= ld be helpful to outline the actual errors that could occur on either end a= nd verify this works in every case. Sending as much information to the othe= r side as possible is helpful for determining bugs. TCP RST signaling doesn= =E2=80=99t convey much information.

Tom

On Jul 11, 2019, at 1:19 PM, Ted Le= mon <mellon@fugue.= com> wrote:

= On Jul 9, 2019, at 10:22 PM, Stuart Cheshire <cheshire=3D40apple.com@dma= rc.ietf.org> wrote:
This is a fine observation.=

You then suggested changing TCP RST to TLS close_n= otify, not realizing (a) this is only for fatal errors, and (b) the precede= nt already set by RFC 8490.

We have in fact = updated the document, but I think this was too hasty, and we should revert = it back to the way it was before.

If not, = we at least need to have a thorough DNSSD Working Group discussion about th= is before making a last-minute change to the protocol.

To add some further nuance from a discussion that Stuar= t and I had today on this, there are actually several different cases where= connection closes are done, and how they should be done is something we sh= ould talk about.

I think in all cases where the cl= ient is closing the connection, there=E2=80=99s a case to be made that we <= i>don=E2=80=99t=C2=A0want to use close_notify. =C2=A0 It=E2=80=99s true= that an attacker can kill our DNS Push connection in this case by forging = an RST to the server. =C2=A0 We should discuss whether this is a serious co= ncern that we need to take into account. =C2=A0 If it is, then using close_= notify would protect against this iff the server ignores TCP RSTs for activ= e TLS sessions.=C2=A0

But the main argument for us= ing close_notify in this case is that we want to be able to resume. =C2=A0 = This will not be the case if the client closed the connection because of a = protocol error. =C2=A0 It will be the case when the client is closing the c= onnection due to inactivity.

There is a case where= the server closes the connection when the client sends a duplicate subscri= be. =C2=A0 That=E2=80=99s because this is a protocol error: the client is b= roken, and cannot be expected to take corrective action. =C2=A0 Then the qu= estion is, do we close the connection down with a retry-delay to make the c= lient go away, or do we just send an RST?

Argument= in favor of sending retry-delay:
  • if the client impleme= nts it, it will shut up for a while.

Arguments= against:
  • If the client doesn=E2=80=99t implement it, it won= =E2=80=99t shut up, so we haven=E2=80=99t gained anything
  • Making th= ings =E2=80=9Csort of work=E2=80=9D when the client is broken isn=E2=80=99t= all that helpful=E2=80=94we actually want the behavior in this case to be = dysfunctional, so that it is noticed and fixed.

I think that the working group should consider these issues and com= e to a consensus.

My own personal opinion is that = we should always do close_notify, because if we can assume this, then an at= tacker can=E2=80=99t kill the connection by sending an RST, if that behavio= r is implemented in the TLS/TCP stack. =C2=A0 My one doubt about this is th= at if we are going through a NAT, will the NAT drop its mapping when it see= s the RST? =C2=A0 If so, then close_notify doesn=E2=80=99t protect against = this attack for a majority of current users. =C2=A0 It still might be worth= doing for IPv6, of course.

As to whether we shoul= d use retry-delay, I have really mixed feelings about this. =C2=A0 I want i= mplementations to be visibly broken when they are broken, but I don=E2=80= =99t want to have to operate a server that has to deal with broken clients.= =C2=A0 The question is whether forcibly disconnecting will actually cause = implementors to take action, or whether it will not be noticed and contribu= te to dysfunction.

My personal experience is that = breaking badly is actually conducive to improvement, so that=E2=80=99s the = direction I=E2=80=99m leaning at the moment.

_________________= ______________________________
dnssd mailing listdnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd
--000000000000ba8b3d058d748cb2-- From nobody Fri Jul 12 09:16:37 2019 Return-Path: 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 E9CE812015D; Fri, 12 Jul 2019 09:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CwAV3Xh/; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yaQtov2c 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 AUCs09pj4TVD; Fri, 12 Jul 2019 09:16:27 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D66F1207E8; Fri, 12 Jul 2019 09:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2120; q=dns/txt; s=iport; t=1562948186; x=1564157786; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=upA7wtrpG04zXdsAdF7fytJPNF0NMti4y+US3tOQpjI=; b=CwAV3Xh/7I/tDs/8X0GOcyoYvmb7ukguzq0ruUgVeLALYVaikT76qfyh D1juXQZ2iZcH7dwxiIOdtE67Y8GhTSjmCjowmXTbA66BTywNP1Qeax0Qu tz54ARExw2G3BxKTht/eYkZX+0o91hS+OKH7wu+vIddWWCdeoMN6z6ngw k=; IronPort-PHdr: =?us-ascii?q?9a23=3ApYxW8RzZK4hPwXzXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuHCkr+LeXxZgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVAQANsShd/49dJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBVgQBAQsBgUNQA2pVIAQLKAqEEoNHA45MgjYll0yCUgNUCQEBAQwBARg?= =?us-ascii?q?LCgIBAYRAAheCPyM3Bg4BAwEBBAEBAgEFbYU8DIVLAQEBAgEBARAREQwBAQw?= =?us-ascii?q?gCwEPAgEIGgIIHgICAiUKARUQAgQBDQUdBAGDAAGBagMODwEOoFwCgTiIYHG?= =?us-ascii?q?BMoJ5AQEFhQkYghIDBoEMKAGLXheBQD+BEScME4JMPoJhAQECgUmDIDKCJo5?= =?us-ascii?q?JL5tuCQKCGZQLG5RVgzKNNJdNAgQCBAUCDgEBBYFmIoFYcBU7KgGCQYJBg3G?= =?us-ascii?q?FFIU/cgGBKI4gAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.63,483,1557187200"; d="scan'208";a="593037071" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jul 2019 16:16:23 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x6CGGN8G020922 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Jul 2019 16:16:23 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Jul 2019 11:16:23 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Jul 2019 11:16:22 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 12 Jul 2019 11:16:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=upA7wtrpG04zXdsAdF7fytJPNF0NMti4y+US3tOQpjI=; b=yaQtov2cnPdq4xJjmQ48oSxetR7aVA3dKZq7wv/N2OscVWhrJ615zPHjLLaSY2cgNAmesOOn8nCLJEMoAHhY248ipqx+tdCgCs/CazwOgZiWIT+rQnM4RmcY7KPunQI/kssD5lbliTwbY9DaynFFAO8PSGj3+13z09B/eEADIzw= Received: from BN6PR11MB4035.namprd11.prod.outlook.com (10.255.129.38) by BN6PR11MB1297.namprd11.prod.outlook.com (10.173.33.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Fri, 12 Jul 2019 16:16:10 +0000 Received: from BN6PR11MB4035.namprd11.prod.outlook.com ([fe80::8534:1b5d:5f72:1cab]) by BN6PR11MB4035.namprd11.prod.outlook.com ([fe80::8534:1b5d:5f72:1cab%4]) with mapi id 15.20.2073.008; Fri, 12 Jul 2019 16:16:10 +0000 From: "Jan Komissar (jkomissa)" To: Stuart Cheshire , Tom Pusateri CC: Eric Rescorla , DNSSD , Ted Lemon , "draft-ietf-dnssd-push.all@ietf.org" , David Schinazi , Robert Sparks Thread-Topic: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 Thread-Index: AQHVLeysJIBeM4NlDUmlbd4UdJUsmKa3rjcAgAAQu4CACaUjAIAAA0kAgAHJhgCAAoy9gIAAESwAgAA5mgCAAB+hAIAA00oA Date: Fri, 12 Jul 2019 16:16:10 +0000 Message-ID: <0B2B059C-77AC-4434-A26E-56296D240011@cisco.com> References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> <6CCF9E3C-A153-401B-B5A7-5877FFFB4A85@apple.com> In-Reply-To: <6CCF9E3C-A153-401B-B5A7-5877FFFB4A85@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=jkomissa@cisco.com; x-originating-ip: [173.38.117.71] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1767be20-1a89-4d59-1de2-08d706e440dd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN6PR11MB1297; x-ms-traffictypediagnostic: BN6PR11MB1297: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00963989E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(396003)(376002)(136003)(39860400002)(199004)(189003)(6506007)(53546011)(76116006)(446003)(186003)(2906002)(76176011)(102836004)(110136005)(316002)(26005)(58126008)(6246003)(11346002)(14444005)(2616005)(66446008)(5660300002)(64756008)(66556008)(476003)(14454004)(66476007)(99286004)(486006)(66946007)(256004)(36756003)(8936002)(53936002)(54906003)(68736007)(6306002)(66066001)(7736002)(6116002)(6436002)(3846002)(6512007)(229853002)(478600001)(86362001)(4326008)(966005)(33656002)(81156014)(8676002)(305945005)(81166006)(25786009)(6486002)(71190400001)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB1297; H:BN6PR11MB4035.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: blTDEzNUz2nWy6I7s04jvmq478DIUL5NoTVTU6adCz2nisOvNYQYccrx72+nQgx/3a432yt/QstFy/Ga/P2jnizK/hSLjXBi95xwYJ9I3/D9MQsO+JlOourcDXUIchh6jEcR7IvM4F1iEGoNMEIV3Nxzua0g2i3vLYCpbRPOXQGg6mStMWwHtpOQhXCZyZrWBcZbZmQ6qc4iTOpLfg3QMhIjJWp2Sqa9WthDO3R2jCgjd+Eki04mKe9ciw17CLlEwsVTee8+tutVk3Lt9I/2/EbZ+p02UnWnZQ/Q/NmDvPME/oYkAYP/MLCEnIo7w7CGOphCW+gXmg1pVMiD4q4y2oK4wveW0dRKFfot0Cj6B/+5HSXkK054z7w0BAfQAEdYWI8QuvpjllgNjurMjzH2cPP3ABWe3bM0Sc6uRQ9QOME= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1767be20-1a89-4d59-1de2-08d706e440dd X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2019 16:16:10.4269 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jkomissa@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1297 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 16:16:35 -0000 SGkgU3R1YXJ0LA0KDQpZb3UgbWF5IGFsc28gd2FudCB0byBtYWtlIHN1cmUgc2VjdGlvbiA2LjYg KEROUyBTdGF0ZWZ1bCBPcGVyYXRpb25zIFRMViBDb250ZXh0IFN1bW1hcnkpIGlzIHVwIHRvIGRh dGUuDQoNCkphbi4NCg0K77u/T24gNy8xMS8xOSwgNzo0MSBQTSwgImRuc3NkIG9uIGJlaGFsZiBv ZiBTdHVhcnQgQ2hlc2hpcmUiIDxkbnNzZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBj aGVzaGlyZT00MGFwcGxlLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBPbiAxMSBK dWwgMjAxOSwgYXQgMTQ6NDYsIFRvbSBQdXNhdGVyaSA8cHVzYXRlcmlAYmFuZ2ouY29tPiB3cm90 ZToNCiAgICANCiAgICA+IDEuIENMSUVOVCByZWNlaXZlcyBTVUJTQ1JJQkUgZnJvbSBzZXJ2ZXIN CiAgICA+IDMuIENMSUVOVCByZWNlaXZlcyBQVVNIIHdpdGggbm8gY2hhbmdlIG5vdGlmaWNhdGlv bnMNCiAgICA+IDQuIENMSUVOVCByZWNlaXZlcyBQVVNIIG5vdGlmaWNhdGlvbiB3aXRoIOKAmGNv bGxlY3RpdmUgcmVtb3Zl4oCZIFRUTCBhbmQgbm9uLXplcm8gUkRMRU4NCiAgICA+IDUuIENMSUVO VCByZWNlaXZlcyBQVVNIIG5vdGlmaWNhdGlvbiB3aXRoIEROUyBtZXNzYWdlIGxlbmd0aCBsYXJn ZXIgdGhhbiAxNmsNCiAgICA+IDYuIENMSUVOVCByZWNlaXZlcyBVTlNVQlNDUklCRSBmcm9tIFNF UlZFUg0KICAgIA0KICAgIFJldmlld2luZyB0aGUgbGlzdCBhYm92ZSwgSSByZWFsaXplIHRoYXQg d2Ugc3RhdGUgZXhwbGljaXRseSB0aGF0IFNVQlNDUklCRSBhbmQgVU5TVUJTQ1JJQkUgc2VudCBm cm9tIHNlcnZlciBhcmUgYm90aCBpbnZhbGlkLiBCdXQgd2UgZG9u4oCZdCBlbnVtZXJhdGUgdGhl IG90aGVyIGJvZ3VzIG1lc3NhZ2UgZGlyZWN0aW9ucy4NCiAgICANCiAgICBJIGhhdmUgYWRkZWQg c29tZSBjbGFyaWZ5aW5nIHRleHQgYXJvdW5kIHRoaXMsIGFuZCB3aWxsIHN1Ym1pdCBhbiB1cGRh dGVkIGRyYWZ0IG9uY2UgdGhleSBvcGVuIGZvciBzdWJtaXNzaW9ucyBhZ2Fpbi4gTm90IHRoYXQg aXQgd2FzIGV2ZXJ5IHJlYWxseSB1bmNsZWFyLCBidXQgaXQgZG9lc27igJl0IGh1cnQgdG8gYmUg YWJ1bmRhbnRseSB1bmFtYmlndW91cy4gSSBoYXZlIGFkZGVkOg0KICAgIA0KICAgIEEgc2VydmVy IE1VU1QgTk9UIHNlbmQgYSBSRUNPTkZJUk0gbWVzc2FnZS4NCiAgICBBIGNsaWVudCBNVVNUIE5P VCBzZW5kIGEgU1VCU0NSSUJFIHJlc3BvbnNlLg0KICAgIEEgY2xpZW50IE1VU1QgTk9UIHNlbmQg YSBQVVNIIG1lc3NhZ2UuDQogICAgDQogICAgQWxsIHRocmVlIGFyZSBmYXRhbCBlcnJvcnMgb2Yg dGhlIOKAnHRoaXMgc2hvdWxkIG5ldmVyIGV2ZXIgaGFwcGVu4oCdIHZhcmlldHkuDQogICAgDQog ICAgU3R1YXJ0IENoZXNoaXJlDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICBkbnNzZCBtYWlsaW5nIGxpc3QNCiAgICBkbnNzZEBp ZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zc2QN CiAgICANCg0K From nobody Sun Jul 14 14:05:15 2019 Return-Path: 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 A563912018A; Sun, 14 Jul 2019 14:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 tdWSVHbNvu8j; Sun, 14 Jul 2019 14:05:11 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF02120183; Sun, 14 Jul 2019 14:05:10 -0700 (PDT) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 04B3D1F44C; Sun, 14 Jul 2019 21:05:08 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 10E131301; Sun, 14 Jul 2019 17:05:26 -0400 (EDT) From: Michael Richardson To: Ted Lemon cc: Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Tom Pusateri , Robert Sparks In-reply-to: <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> Comments: In-reply-to Ted Lemon message dated "Thu, 11 Jul 2019 13:19:05 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 14 Jul 2019 17:05:26 -0400 Message-ID: <7784.1563138326@dooku.sandelman.ca> Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 21:05:14 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: > forging an RST to the server. We should discuss whether this is a > serious concern that we need to take into account. If it is, then usi= ng > close_notify would protect against this iff the server ignores TCP RS= Ts > for active TLS sessions. I'm unaware of TCP stacks that can turn off RSTs on a per-socket basis. Is this commonly available now and I'm just ignorant of it? I imagine that is the only way the application could inform the kernel that TLS is active. I guess a filter could drop RSTs to port 853, and assume it's always TLS. Securing TCP against fake RSTs is something the TCP-AO was designed to do. AFAIK, we never defined a way to key TCP-AO from TLS. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0rmRUACgkQlUzhVv38 QpAD2gf+NS7eNuYKJdBPBoDy0xQhgRxzu5xHbqgeaee6iYVluPQ8DzM0XThGJKfg bUkY1A/SmrhnUy3EDmNIJQ8kKO3+7I52GtnoXgM0YoFFOKyUIIfl8nB7FW7uyPGt rOaC+JhYXCS1kup6OAHWTdNHisV1BRiksQxUbExvW+0NDy+LFQDAt1GBjUtHy2yJ ssDsYvhOX/OHtoi7nmtA2GN3SuCaMFdAUInh44cXuFsCdS/LrItSGdYclNa10PQD P5sb4NpKE00oZ9H8vAjxqvo6ShoB0zGUicEdMXv59Dn6YjfAJiTN+Z5GDRhVbDKf T2ytT9SRQZTj00W5nMKcRbW8cDZ09g== =vyeR -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 14 14:08:59 2019 Return-Path: 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 2CF0A1202D0 for ; Sun, 14 Jul 2019 14:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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, URIBL_BLOCKED=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 UnfMWZ4oRXhL for ; Sun, 14 Jul 2019 14:08:44 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 1C69512018A for ; Sun, 14 Jul 2019 14:08:44 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id d17so13622078qtj.8 for ; Sun, 14 Jul 2019 14:08:44 -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=Q3f6hHAOzfDyxPPkjvURx6K9PGqxlTBfx50vXA0BSJY=; b=mAbJlcFPXuDpLRnBw3FZm5cSK1AZ9MMRip5Ff4Iw95S/S9RKBfMJBy7hpjQ0zMJm2f 6yUut4ATPW17KFqaumxlSiKbC3c73Isso7FtHtPGBTO+PWwhexeXUC9el+3qCXFRVyjc QFAzcRF8tV+S2Sn9Qsk75fmJuzOUtdvZQlcC+CEMGkUk8sr//56jnxns7b4nPiLcSxfH P4QjVJShiMvgVgOcbreupeGu6KvlyDtz5Dj+p5PNTZHA45TrWh1p78loTqGwSI8QbM2Q 7wwge4VU/LHuQH2V86vr/D9ZRnfqQrfvVPAf+iD5doELLJ6ENG3yILs+L9ft7SZnMh6p 74og== 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=Q3f6hHAOzfDyxPPkjvURx6K9PGqxlTBfx50vXA0BSJY=; b=sN4RwG8z3kdUvjdk5AqtfIz7sX582IevMXr/o6LaBO+8B1dByzDnv0c9hWJNWFN3C+ g92tCLX3XjcQ9w+tEgf8WfastDf9xm/lM2wuYcQmN1dHVYFnIoJC8xtiEIvZwu95npni 6tofAXgdh723TOnIL/RsvGsdPB2YXmDXUynGlSWmTnYoMQjjz5aMvt/Vcqr0FdLhwsz3 HlDUqcKuLKZUmihJMTCCaCRMzOdYNIZeYf+aeduibezOz7AYjaoqJ2bu0NUj3wCZOez9 AAkVnKKG6g4BZI+BWBN0Rd7xesIxJiGAxaJT/QTZbIzd7xnrR2XnUkDXkNP0me4kf4oC L4oQ== X-Gm-Message-State: APjAAAU2FNAF/IE+qu6cC9SEEzcQqzksAV9roZUFvavqfuqPob3s+jtz h8CPCkthc2ioRJA/FZ1b43U/GQ== X-Google-Smtp-Source: APXvYqxJgz0Xg/+e7RIYt8cgKHt1HZkES1zz+dMhzbgXPA/so9Muzm8YFTu9PxfIbeCJ4G96/o/qqQ== X-Received: by 2002:ac8:2fc8:: with SMTP id m8mr15474555qta.269.1563138523088; Sun, 14 Jul 2019 14:08:43 -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 i62sm6696422qke.52.2019.07.14.14.08.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 14 Jul 2019 14:08:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPhone Mail (16G69) In-Reply-To: <7784.1563138326@dooku.sandelman.ca> Date: Sun, 14 Jul 2019 17:08:41 -0400 Cc: Stuart Cheshire , Eric Rescorla , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Tom Pusateri , Robert Sparks Content-Transfer-Encoding: quoted-printable Message-Id: References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> <7784.1563138326@dooku.sandelman.ca> To: Michael Richardson Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 21:08:49 -0000 I don=E2=80=99t know if a stack that does this either. It could be done in p= rinciple. But it sounds like that wasn=E2=80=99t the goal.=20 Sent from my iPhone > On Jul 14, 2019, at 5:05 PM, Michael Richardson wr= ote: >=20 >=20 > Ted Lemon wrote: >> forging an RST to the server. We should discuss whether this is a >> serious concern that we need to take into account. If it is, then using >> close_notify would protect against this iff the server ignores TCP RSTs >> for active TLS sessions. >=20 > I'm unaware of TCP stacks that can turn off RSTs on a per-socket basis. > Is this commonly available now and I'm just ignorant of it? >=20 > I imagine that is the only way the application could inform the kernel tha= t > TLS is active. >=20 > I guess a filter could drop RSTs to port 853, and assume it's always TLS. >=20 > Securing TCP against fake RSTs is something the TCP-AO was designed to do.= > AFAIK, we never defined a way to key TCP-AO from TLS. >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh networ= ks [=20 > ] Michael Richardson, Sandelman Software Works | network architec= t [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 > =20 From nobody Sun Jul 14 14:28:37 2019 Return-Path: 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 CB67112003E for ; Sun, 14 Jul 2019 14:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 xFGLpKYIVjqz for ; Sun, 14 Jul 2019 14:28:34 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 8530D12019D for ; Sun, 14 Jul 2019 14:28:32 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id x25so14176596ljh.2 for ; Sun, 14 Jul 2019 14:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ixSScnDFpQzU1eGrJYpFEbTgp67NHfOQySLNPRL4Gtw=; b=SzZ3ziv/RAgWn1B83q3w35fpn5rcRK0unzXuBlyZOUqof28SC4vRWPya0vr2DnIY5M MqGYL+Rim12cz+h9W5YAaCjO+M6c7C8JDzie6pHnWzCevHdUiozO0qeq2AvnU6kK0oLj FVExL9ZY8X0LpZr5nqeJz5K6NHOrI1ij7dksj28Ip9bqtGghyFK9/N7L3K4SOahBpVKl fl2dYvsr9fSlfa7WI6ZuNr6y9iR9B03ryYFxaNhoEDX+5W0yuqfSePPIugM9+BhKDyCZ Yrml/Hwucym8g2Op3n/aS56s/JFLG9sQ6s55+25kGqM/VPRkCg2vjujlYuLJwBxjicyx YfmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ixSScnDFpQzU1eGrJYpFEbTgp67NHfOQySLNPRL4Gtw=; b=ckXmlZqYg4oCcgXp19SZ5sBlbGpSj9ulNSeXOiKL/R9G/jkJe11hEdxmoIJSrtWt38 /PldyDgwIxRSEkDxfvgsdsXw8xwMkO9NKbQSsoGZinj5aSTYzJQq0WLtC8G5kts8Ars5 2Zo5f1TtkkMz/Q/+aNaUOKNZhhnokzRPUY+kK2H8bSQ6DsxoM6Tn7eVf7QxabQdTYK/u qf/hXIgJA8dIF1MHaGI8RykKlxVto1KKB8UFBbaT9evp+hiM98IdmaFQXuzaO0XbMBgw 5q8qQWK+ETFzh84EC+0HKiAPz8mVeQhpGxN/D7jf6d6Y799tKaRv5P7DIEYr00K7nHz5 M6ZA== X-Gm-Message-State: APjAAAUJzWV0weV73wwmnVklUAScNTWoINgmnOpSRV/EzMPUwrXHv7Mf T3GYsVVm4GUo6vRAjcSDqwIJ7aopo3HOj1dyUnk= X-Google-Smtp-Source: APXvYqycaEjlgtrcbpGM1029DmRuzudAAwTy/Z19W/BDxX4Vd0rnBiueze6srkxJJgcea5zyHsqtEg5NaeGb3wrY2KU= X-Received: by 2002:a2e:8892:: with SMTP id k18mr12232447lji.239.1563139710637; Sun, 14 Jul 2019 14:28:30 -0700 (PDT) MIME-Version: 1.0 References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <270A8516-8BE8-441A-A6CC-4FDE8EFE2B10@fugue.com> <7784.1563138326@dooku.sandelman.ca> In-Reply-To: <7784.1563138326@dooku.sandelman.ca> From: Eric Rescorla Date: Sun, 14 Jul 2019 14:27:54 -0700 Message-ID: To: Michael Richardson Cc: Ted Lemon , Stuart Cheshire , DNSSD , draft-ietf-dnssd-push.all@ietf.org, David Schinazi , Tom Pusateri , Robert Sparks Content-Type: multipart/alternative; boundary="0000000000002fe83e058daad3e9" Archived-At: Subject: Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 21:28:36 -0000 --0000000000002fe83e058daad3e9 Content-Type: text/plain; charset="UTF-8" On Sun, Jul 14, 2019 at 2:05 PM Michael Richardson wrote: > > Ted Lemon wrote: > > forging an RST to the server. We should discuss whether this is a > > serious concern that we need to take into account. If it is, then > using > > close_notify would protect against this iff the server ignores TCP > RSTs > > for active TLS sessions. > > I'm unaware of TCP stacks that can turn off RSTs on a per-socket basis. > Is this commonly available now and I'm just ignorant of it? > > I imagine that is the only way the application could inform the kernel that > TLS is active. > > I guess a filter could drop RSTs to port 853, and assume it's always TLS. > I'm not sure how much this would help: if the attacker can inject an invalid data segment full of random data, then this will likely lead to TLS connection failure (i.e., you'll be able to detect the problem but it's not recoverable). I'm not sufficiently up to date on the state of TCP injection attacks to know whether off-path RST attacks are significantly harder than off-path data injection attacks (obviously, on-path attacks are straightforward in both cases). > Securing TCP against fake RSTs is something the TCP-AO was designed to do. > AFAIK, we never defined a way to key TCP-AO from TLS. > No, we did not. It's theoretically straightforward, but you know what they say about the difference between theory and practice. In this particular case, given the low level of deployment, it seems like it might be easier to just move to QUIC. -Ekr > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > --0000000000002fe83e058daad3e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Jul 14, 2019 at 2:05 PM Micha= el Richardson <mcr+ietf@sande= lman.ca> wrote:

Ted Lemon <mellon@= fugue.com> wrote:
=C2=A0 =C2=A0 > forging an RST to the server. We should discuss whether = this is a
=C2=A0 =C2=A0 > serious concern that we need to take into account. If it= is, then using
=C2=A0 =C2=A0 > close_notify would protect against this iff the server i= gnores TCP RSTs
=C2=A0 =C2=A0 > for active TLS sessions.

I'm unaware of TCP stacks that can turn off RSTs on a per-socket basis.=
Is this commonly available now and I'm just ignorant of it?

I imagine that is the only way the application could inform the kernel that=
TLS is active.

I guess a filter could drop RSTs to port 853, and assume it's always TL= S.

I'm not sure how much this would= help: if the attacker can inject an invalid
data segment full of= random data, then this will likely lead to TLS connection
failur= e (i.e., you'll be able to detect the problem but it's not recovera= ble).
I'm not sufficiently up to date on the state of TCP inj= ection attacks to know
whether off-path RST attacks are significa= ntly harder than off-path data injection
attacks (obviously, on-p= ath attacks are straightforward in both cases).
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> Securing TCP against fake RSTs is something the TCP-AO was designed to do.<= br> AFAIK, we never defined a way to key TCP-AO from TLS.
=
No, we did not. It's theoretically straightforward, but = you know what they say
about the difference between theory and pr= actice. In this particular case,
given the low level of deploymen= t, it seems like it might be easier to just
move to QUIC.

-Ekr


--
]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell me the o= dds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| ipv6 me= sh networks [
]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 =C2=A0 =C2= =A0 =C2=A0 | network architect=C2=A0 [
]=C2=A0 =C2=A0 =C2=A0= mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0ruby on rails=C2=A0 =C2=A0 [

--0000000000002fe83e058daad3e9-- From nobody Sun Jul 21 19:23:15 2019 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DDD12003F; Sun, 21 Jul 2019 19:23:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <156376219406.8834.2412454934382572833@ietfa.amsl.com> Date: Sun, 21 Jul 2019 19:23:14 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-23.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 02:23:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-23.txt Pages : 41 Date : 2019-07-21 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that are relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled, as long as the polling rate is not too high. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-push-23 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-23 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 25 12:16:50 2019 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B2F1201A0; Thu, 25 Jul 2019 12:16:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <156408220277.17641.4970373777742142170@ietfa.amsl.com> Date: Thu, 25 Jul 2019 12:16:42 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-prireq-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 19:16:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : DNS-SD Privacy and Security Requirements Authors : Christian Huitema Daniel Kaiser Filename : draft-ietf-dnssd-prireq-01.txt Pages : 17 Date : 2019-07-25 Abstract: DNS-SD (DNS Service Discovery) normally discloses information about devices offering and requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy respecting discovery service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-prireq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-prireq-01 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-prireq-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-prireq-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jul 25 14:12:27 2019 Return-Path: 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 A263A120233 for ; Thu, 25 Jul 2019 14:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 RR1uuw6vL9OP for ; Thu, 25 Jul 2019 14:12:19 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 A920B1201F1 for ; Thu, 25 Jul 2019 14:12:18 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id k18so49347661ljc.11 for ; Thu, 25 Jul 2019 14:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xjlTfvr4iWXZrIQeJHBT9OZlsbfrp2lx68MnBrfa1OU=; b=X08HiuuFa0tqevIuqK8mLrovOBLbGeb4PUlU22kszNs2hFlmMac6ek6Cqj7WLVZa9O u0hsnEK8sikWuuaw0bk92QlpYf1nPiBZXbcbbmAVV127CLiB3y8Ix1b43izcby6/ij0K 4LT0xzgbaHMMR7ZbrjMFaEZKUa/7DBfj6Eog2dT67k8gzkRs+U25qizN6tpkkbsQ8OVT 8bjuG8HrN+looZhnIceflaVDfPry/x6pJQjLt7cw3Ds6HqEscG4bOrJEjzFszZYJL9hi PZ93yi/8VAQtScWIJF85JQQe0C8/JWJX16n6mjf+Ue0ZRv/O/PAUn99+hW2z6dbVa7QZ gK0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xjlTfvr4iWXZrIQeJHBT9OZlsbfrp2lx68MnBrfa1OU=; b=B+eAg4HoeZJmsh8s9R9ku6ODXCXFVLIFPykWDU6P5aU85MfJd79X5pwfCwOPcCLAqi zEykesOYYIpQoqXP23HagDERMsNSRiXtjTh8lgORVs2VkUvI/PSap/vr4lHAusbbqTWP +AZB1JfE62WY9lsQbPvoVqcSsdj8AWS2PJtbmxvtvGwIfzsRttF0Ah/B+aV9buILCEbB C80gnokD3t/XtUveGtaXzYuY5wWdA32wLQp9/FHWWpKZcdakniPaY3zQdTm0egE2xK2V 1Gd3byh7bBt+0WGej2weErKeIsbjozfZHsgrdz82k0r1StK/g/A9fCmSKEGtZtKj2dA8 xPBw== X-Gm-Message-State: APjAAAUvdcbXkm6/sNzpSHEuH1SCXRgYuQcweE92RIV3biQlVvg8E0pT G6Ku9p2OGy/xAmWZkTZgMV8mN2ivT1gLFupsTFpMAuoETnU= X-Google-Smtp-Source: APXvYqx/qxIQVcCAiW5yvv7bJUP1xRvOeN+e1KEtkStMhmaoYm8EzB8ZL12ih8hVpjUTPcv+RtywGi636nlLzB18Bh4= X-Received: by 2002:a2e:96d5:: with SMTP id d21mr9838734ljj.170.1564089136577; Thu, 25 Jul 2019 14:12:16 -0700 (PDT) MIME-Version: 1.0 From: David Schinazi Date: Thu, 25 Jul 2019 17:12:05 -0400 Message-ID: To: DNSSD Content-Type: multipart/alternative; boundary="00000000000061ffce058e87e106" Archived-At: Subject: [dnssd] DNSSD Minutes at IETF 105 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 21:12:21 -0000 --00000000000061ffce058e87e106 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, Thanks for attending the session today, and in particular thanks to Michael Richardson and Christian Ams=C3=BCss for recording minutes and to Tim Watte= nberg for Jabber-scribing. The minutes have been uploaded here: https://datatracker.ietf.org/meeting/105/materials/minutes-105-dnssd Please take a look and make sure your contributions were recorded correctly= . Thanks, David --00000000000061ffce058e87e106 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

Thanks for attending the s= ession today, and in particular thanks to=C2=A0Michael Richardson and Chris= tian Ams=C3=BCss for recording minutes and to=C2=A0Tim Wattenberg for Jabbe= r-scribing.

The minutes have been uploaded here:

Please take a look and make sure = your contributions were recorded correctly.

Thanks= ,
David

--00000000000061ffce058e87e106-- From nobody Thu Jul 25 14:15:19 2019 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F861201F1; Thu, 25 Jul 2019 14:15:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dnssd@ietf.org Message-ID: <156408931714.17615.11401057000851343283@ietfa.amsl.com> Date: Thu, 25 Jul 2019 14:15:17 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-prireq-02.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 21:15:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF. Title : DNS-SD Privacy and Security Requirements Authors : Christian Huitema Daniel Kaiser Filename : draft-ietf-dnssd-prireq-02.txt Pages : 17 Date : 2019-07-25 Abstract: DNS-SD (DNS Service Discovery) normally discloses information about devices offering and requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy respecting discovery service. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-prireq/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnssd-prireq-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-prireq-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-prireq-02 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/