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

[Tom Pusateri <[e-mail]>]

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