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

From: Kent Watsen <[email-masked]>
Date: Tue, 3 Apr 2012 13:57:06 -0700

> 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

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 4 Apr 2012 23:54:45 +0200

On Tue, Apr 3, 2012 at 10:57 PM, Kent Watsen <[email-masked]> wrote:

> 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…****
>
>
>

Juergen already commented on this point:
"Proper closure of the TLS session is important to be able to
distinguish a proper closing of the session from a potentially
malicious closing of the session. I guess the same applies for
SSH. Sure, you can't prevent arbitrary TCP failures but a proper
shutdown procedure tells the other end that the closure was done by
intention. In other words, from a security point of view, I think
RFC6242 should have also encouraged proper SSH shutdown."

Moreover, in RFC5246, Section 7.2.1:

  The client and the server must share knowledge that the connection is

   ending in order to avoid a truncation attack

Also:

      Note that as of TLS 1.1,
      failure to properly close a connection no longer requires that a
      session not be resumed.  This is a change from TLS 1.0 to conform
      with widespread implementation practice.

Some TLS1.0 implementations which receive a connection close without first
receiving a valid closure alert MUST NOT reuse the TLS session.

Best regards,
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Apr 2012 12:19:54 +0200

> RFC6242 should have also encouraged proper SSH shutdown."

Perhaps we need to add an explanation (e.g. to the security
considerations) so that implementors realize that proper closing of a
session has merits and that improper session aborts can be a sign of
an attack.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 5 Apr 2012 23:25:53 +0200

> session has merits and that improper session aborts can be a sign of

What about adding the following to the Security Considerations:

To help prevent a truncation attack, the peer that is closing the NETCONF
session MUST send a TLS close_notify alert and MUST receive a responding
close_notify alert from the other peer before terminating the underlying
TCP connection.

Best regards
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Apr 2012 00:26:23 +0200

> close_notify alert from the other peer before terminating the underlying

Well, this does not really _prevent_ a truncation attack. Using a
close_notify allows the peer only to recognize that it was not facing
a potential truncation attack.

/js

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 6 Apr 2012 09:51:26 +0200

> a potential truncation attack.
in RFC5246, The client and the server must share knowledge that the
connection is ending in order to avoid a truncation attack.

What about:

To help avoid a truncation attack, the peer that is closing the NETCONF
session MUST send a TLS close_notify alert and MUST receive a responding
close_notify alert from the other peer before terminating the underlying
TCP connection.

Kindly don't hesitate to send text that matches better the situation
Best regards
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Apr 2012 12:01:55 +0200

> close_notify alert from the other peer before terminating the underlying

I would prefer to minimize the text we have in this document and
instead we should simply refer to Section 7.2.1 in RFC 5246. The
wording in RFC 5246 is indeed irritating as welll since close_notify
does not "avoid" truncation attacks.

The real questions is: What should an implementation running over TLS
do if there is no close_notify. I do not think we have an answer to
this question and if at the end the implementations do proceed pretty
much in the same way regardless whether there has been a close_notify
or not, then Phil is at the end effectively right.

/js

---

From: Mohamad Badra <[email-masked]>
Date: Sat, 7 Apr 2012 19:22:21 +0200

> does not "avoid" truncation attacks.
TLS close_notify is integrity protected and has a final result. In this
optic, close_notify helps to avoid truncation attack.

In RFC4422:
A protocol can defend against these attacks by ensuring that each
information exchange has a clear final result and that each protocol
session has a graceful closure mechanism, and that these are
integrity protected.

> or not, then Phil is at the end effectively right

If thenwhat about replacing Section 2.2 of the document with (extracted
from rfc6242)

   Exiting NETCONF is accomplished using the <close-session> operation. A
   NETCONF server will process NETCONF messages from the NETCONF client
   in the order in which they are received.  When the NETCONF server
   processes a <close-session> operation, the NETCONF server SHALL
   respond and close the TLS session channel.  The NETCONF server MUST
   NOT process any NETCONF messages received after the <close-session>
   operation. The TLS session is closed as described in RFC5246 Section
   7.2.1

Comments?

Best regards,
Badra

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 7 Apr 2012 22:46:42 +0200

>    operation. The TLS session is closed as described in RFC5246 Section

This looks good and sufficient to me.

/js

---

From: Kent Watsen <[email-masked]>
Date: Mon, 9 Apr 2012 12:04:26 -0700

>  ending in order to avoid a truncation attack
 
I don't think it's possible for a TCP-based protocol to avoid a truncation attack (unless using IPSEC) - a protocol can only detect that a truncation occurred, by having an explicit close message (e.g. close_notify).  I checked RFC5246's Errata page and didn't see a clarification, do you think it should be reported?

> Some TLS1.0 implementations which receive a connection close without first receiving a
> valid closure alert MUST NOT reuse the TLS session.

Unwinding the double-negative and what not, it says "a TLS session MAY be resumed if it was closed improperly" (i.e. via SSL_set_session()).   Session resumption is an optimization primarily for HTTPS servers as it enables the RSA/DH steps to be skipped as the browser connects/disconnects the server throughout a user's session.  Bringing this to NETCONF, it means that NETCONF clients MAY try to resume a TLS session and that NETCONF servers MUST support session resumption (ideally via rfc5077).  I wonder how much app-level coding is required - looking at OpenSSL source, it seems that the resumption logic must be coded into the app-layer...

---

From: Kent Watsen <[email-masked]>
Date: Mon, 9 Apr 2012 12:09:22 -0700

>> If then what about replacing Section 2.2 of the document with (extracted
>> from rfc6242)
>> 

Agreed

---

From: Mohamad Badra <[email-masked]>
Date: Mon, 9 Apr 2012 21:40:58 +0200

On Mon, Apr 9, 2012 at 9:04 PM, Kent Watsen <[email-masked]> wrote:

> I don't think it's possible for a TCP-based protocol to avoid a truncation
> attack (unless using IPSEC) - a protocol can only detect that a truncation
> occurred, by having an explicit close message (e.g. close_notify).  I
> checked RFC5246's Errata page and didn't see a clarification, do you think
> it should be reported?

I totally agree with you, and I believe it should be reported.
Best regards,
Badra