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

[Benjamin Kaduk <[e-mail]>]

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