Re: [dnssd] Genart last call review of draft-ietf-dnssd-push-20

Stuart Cheshire <cheshire@apple.com> Wed, 10 July 2019 02:23 UTC

Return-Path: <cheshire@apple.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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 <cheshire@apple.com>
In-reply-to: <CAPDSy+6V+ooWDe7XezmWA_XKNQXRAOex8DE5CiTnZdz8zc-9CA@mail.gmail.com>
Date: Tue, 09 Jul 2019 19:22:50 -0700
Cc: Tom Pusateri <pusateri@bangj.com>, Robert Sparks <rjsparks@nostrum.com>, draft-ietf-dnssd-push.all@ietf.org, DNSSD <dnssd@ietf.org>, Eric Rescorla <ekr@rtfm.com>
Content-transfer-encoding: quoted-printable
Message-id: <F6DD5CEF-E644-46E3-84B5-18309F6B44C5@apple.com>
References: <156175221593.21875.9525138908968318905@ietfa.amsl.com> <9E6DE124-9262-4870-A920-4E707A38DC08@bangj.com> <CAPDSy+7om=cBW51cyuPea9nabgJuRV3M+++gA7sy8VzfNpkn6Q@mail.gmail.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <CAPDSy+6V+ooWDe7XezmWA_XKNQXRAOex8DE5CiTnZdz8zc-9CA@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
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: <https://mailarchive.ietf.org/arch/msg/dnssd/DYvG7XNreWRL_rylKYl-Ep_GExI>
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." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 02:23:03 -0000

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 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.

This is a great candidate for some serious discussion in Montréal.

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>om>, draft-ietf-dnssd-push.all@ietf.org, DNSSD <dnssd@ietf.org>
> 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>om>, 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 truncation 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 discussion about this before making a last-minute change to the protocol.

Stuart Cheshire