Re: [dnssd] Mirja Kühlewind's No Objection on draft-ietf-dnssd-push-23: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Tue, 06 August 2019 21:46 UTC

Return-Path: <kaduk@mit.edu>
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 A2BC7120047; Tue, 6 Aug 2019 14:46:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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 m6J6LvouoznY; Tue, 6 Aug 2019 14:46:25 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E95D0120033; Tue, 6 Aug 2019 14:46:24 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x76LkJO2006908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 6 Aug 2019 17:46:22 -0400
Date: Tue, 6 Aug 2019 16:46:19 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Mirja =?iso-8859-1?Q?K=FChlewind?= <ietf@kuehlewind.net>
Cc: The IESG <iesg@ietf.org>, tjw.ietf@gmail.com, dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-push@ietf.org
Message-ID: <20190806214618.GN59807@kduck.mit.edu>
References: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/6FUJ21bd0_mXOHYIyiqR6IyqarM>
Subject: Re: [dnssd] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_dra?= =?iso-8859-1?q?ft-ietf-dnssd-push-23=3A_=28with_COMMENT=29?=
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: Tue, 06 Aug 2019 21:46:27 -0000

On Mon, Aug 05, 2019 at 07:55:20AM -0700, Mirja Kühlewind via Datatracker wrote:
> 
> 3) Section 6.7:
>    "If the session is forcibly closed at the TCP level by sending a RST
>    from either end of the connection, data may be lost and TLS session
>    resumption of this session will not be possible."
> I would think that TLS session resumption might still be possible even if a RST
> is received (as long as the TLS handshake was completed and the client received
> a session ticket). Or what's the assumption here?

It's hard for me to be sure, but I note that previous versions of TLS
mandated that the session be invalidated on receipt of a TLS fatal alert,
after which other existing connections using that session could continue
but new ones would not be allowed to be established.  However, a TCP RST is
not a TLS fatal alert, so I don't think even a strict reading of RFC 5246
would imply this stated behavior, but I could see it being easy for someone
to have internalized "TLS connection error implies the session is no longer
resumable".  (Many implementations ignored this requirement, and it is
relaxed in RFC 8446 anyway.)

-Ben