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

David Schinazi <dschinazi.ietf@gmail.com> Wed, 10 July 2019 17:33 UTC

Return-Path: <dschinazi.ietf@gmail.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 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> <CAPDSy+7om=cBW51cyuPea9nabgJuRV3M+++gA7sy8VzfNpkn6Q@mail.gmail.com> <9F8CFF4A-ABC1-4005-AE65-6CE64940B59F@apple.com> <CAPDSy+6V+ooWDe7XezmWA_XKNQXRAOex8DE5CiTnZdz8zc-9CA@mail.gmail.com> <F6DD5CEF-E644-46E3-84B5-18309F6B44C5@apple.com>
In-Reply-To: <F6DD5CEF-E644-46E3-84B5-18309F6B44C5@apple.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Wed, 10 Jul 2019 10:32:53 -0700
Message-ID: <CAPDSy+4xfo46oJNc7Qxk2NqQCWDKB8LyvzdpFu=9MFRXBwFf3A@mail.gmail.com>
To: Stuart Cheshire <cheshire@apple.com>
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-Type: multipart/alternative; boundary="000000000000d7f748058d571106"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/D4YzebxNaDSkhzct0-XzAUHbmRs>
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 17:33:16 -0000

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 <cheshire@apple.com> 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 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
>
>