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

Tom Pusateri <pusateri@bangj.com> Tue, 06 August 2019 22:03 UTC

Return-Path: <pusateri@bangj.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 6826712008B; Tue, 6 Aug 2019 15:03: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bangj.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 imZfKWeo5wxT; Tue, 6 Aug 2019 15:03:02 -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 DF39312006E; Tue, 6 Aug 2019 15:03:01 -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 02686319F0; Tue, 6 Aug 2019 18:03:01 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1565128981; bh=6jncNcz82EVAfUO+zWsFcL3v6oWCllhIxVGBwoZPRWo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Ed76fTBKo4a/OR6UWASE36jhddHXOjxYmERHxB0eyush6Y3XuYpHQisYPPPK8y1r1 UhsnvGUseR+cvjfgl5IJ1i9L9t/dihhQmd8Zp7J9oi3wwQEVqEG6Rcl6GfG4BPRPQc WyHlCkJD7I7oSPTKqMsntUcL0TwrL2rNV9a8X7tbck/terOaLIRMVvnlJrKwfoUsGi W7N1+m/E9Uj3UCwg1nO0w5JC1JoPT8BwRz2pChoHTkMsmgEPU2U2ffR7e7RD1slYPf EYzjEcmimFuI4Dv1RurqMBq8mVHey92D1ipKyC4LAJIiYqavZlZ+kticvLPLPwhAES ECpcjBqg+UQJQ==
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3570.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <20190806214618.GN59807@kduck.mit.edu>
Date: Tue, 6 Aug 2019 18:03:00 -0400
Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, tjw.ietf@gmail.com, dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-push@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1FB39EE-5AAF-4A01-A5F7-C14A17179E38@bangj.com>
References: <156501692084.24510.12940236096030192014.idtracker@ietfa.amsl.com> <20190806214618.GN59807@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3570.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/ZxPc31pCnA5tx_1cOdg-BldALSU>
Subject: Re: [dnssd] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-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 22:03:04 -0000


> On Aug 6, 2019, at 5:46 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> 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

Yes, thanks for the background. This was a misunderstanding on my part and I will remove the resumption clause.

Tom