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

Tom Pusateri <> Tue, 06 August 2019 22:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6826712008B; Tue, 6 Aug 2019 15:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id imZfKWeo5wxT; Tue, 6 Aug 2019 15:03:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DF39312006E; Tue, 6 Aug 2019 15:03:01 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 02686319F0; Tue, 6 Aug 2019 18:03:01 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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 <>
In-Reply-To: <>
Date: Tue, 6 Aug 2019 18:03:00 -0400
Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= <>, The IESG <>,,,,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Benjamin Kaduk <>
X-Mailer: Apple Mail (2.3570.1)
Archived-At: <>
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-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, 06 Aug 2019 22:03:04 -0000

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