Re: [Netconf] Updating RFC 5539 WAS:FW: New version of draft-badra-netconf-rfc5539bis

[Kent Watsen <[e-mail]>]

> RFC5246 doesn't support reverse proxy as well, and all RFCs' Applications over TLS have the same above language.
>
> However, what about rewriting it as follow:
>
> The peer actively opens the TLS connection, and the server passively
> listens for the incoming TLS connection.

Yes, this leaves the door open better


Section 2.2: what about <close-session>?  - why define another mechanism?  If important, then why doesn't RFC6242 require the client to send SSH_MSG_CHANNEL_CLOSE and/or SSH_MSG_DISCONNECT.   Regardless, I disagree with the intent of forcing graceful closures - in reality, devices MUST be coded to support ungraceful closures and, once the code is written, there isn't much value to a graceful close anymore.  Also the second paragraph seems out of place - shouldn't it be in the TLS RFC? [Note: this language was also in RFC5539]

I didn't see a response to this comment...


> I would prefer not moving it to the "Security Considerations" and I will replace the 1st paragraph with
>
> If the server's presented certificate has passed
> certification path validation [RFC5280] to a configured
> trust anchor, the client MUST carefully examine the
> certificate presented by the server to determine if it meets the
> client's expectations. Particularly, the client MUST check its
> understanding of the server hostname against the server's identity as
> presented in the server Certificate message, in order to prevent man-
> in-the-middle attacks.

Better, thanks



Kent