Subject: Re: [Netconf] Fw: Last Call: <draft-ietf-tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard

From: Randy Presuhn <[email-masked]>
Date: Sat, 14 Dec 2013 14:49:45 -0500 (EST)

Hi -

>From: Mohamad Badra <[email-masked]>
>Sent: Dec 14, 2013 2:51 AM
>To: Randy Presuhn <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [Netconf] Fw: Last Call: <draft-ietf-tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
...
>> By using a single port for multiple types of (encrypted)
>> traffic, traffic analysis attacks, such as those associated
>> with pervasive monitoring, may be made somewhat more difficult.
>
>
>
>This is currently not provided by the draft. The client sends a list of
>applications type in a TLS extension and the server selects ONLY one from
>the list. Moreover, the negotiation of application types is achieved in
>clear text and available for traffic analysis and monitoring.

Thus the "somewhat".  However, it does require the attacker to
intercept and record connection requests and maintain that
state information, rather than just tracking IP destination port
numbers. This makes traffic analysis from bulk monitoring
*somewhat* more expensive and annoying.

>It is true that multiple type of traffic could be negotiated (in clear
>text) but only one type will use the TLS session.

Think *pervasive* monitoring over the set of *all* sessions
involving that port, not just a single one that happens to
carry management traffic.

Is this an ideal tool?  Clearly not, but since it is
intended to address a problem very similar to one that has
troubled this WG, we need to consider whether it's up to
the job.

Randy

---

From: Mohamad Badra <[email-masked]>
Date: Sun, 15 Dec 2013 00:30:23 +0400

On Sat, Dec 14, 2013 at 11:49 PM, Randy Presuhn <
[email-masked]> wrote:

>  since it is

Sorry Randy, what kind of problems you are talking about? Is this related
to rfc5539bis?
Best regards
Badra​​

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 14 Dec 2013 12:56:33 -0800

Hi -

> From: "Mohamad Badra" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, December 14, 2013 12:30 PM
> Subject: Re: [Netconf] Fw: Last Call: <draft-ietf-tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application Layer
Protocol Negotiation Extension) to Proposed Standard
...
> Sorry Randy, what kind of problems you are talking about?

(1) The need to reserve a port.
(2) The need to reserve a different port for call home.

It clearly addresses (1).
As Jurgen indicated, (2) needs some thought.

> Is this related to rfc5539bis?

Yes.

Randy

---

From: Mohamad Badra <[email-masked]>
Date: Sun, 15 Dec 2013 01:41:27 +0400

> It clearly addresses (1).

It is not clear to me how does the document address the need to reverse a
port. AFAIK, the document resolves the issue of not assigning a port number
for a service, but negotiating it via a TLS extension.  However, I cannot
see how this document reverse the role of the client and the server in the
context of rfc5539bis

​​

> ​
> ​

 ​
> As Jurgen indicated, (2) needs some thought.

This could be done by using a TLS extension and send the port number in a
way similar to FTP pasv command.
The client and the server establish a TLS with call_home extension (TBD).
When it is sent by the TLS client, the content of the extension contains a
port number in which the client will be listening for an incoming TCP
connection from the server.

Best regards,
Badra​​

---

From: "Randy Presuhn" <[email-masked]>
Date: Sat, 14 Dec 2013 13:51:56 -0800

Hi -

> Sent: Saturday, December 14, 2013 1:41 PM
> port.

It appears you may have mis-read what I wrote.
"reserve", not "reverse".  Big difference.

Randy