Subject: [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: Fri, 13 Dec 2013 11:20:50 -0800 (GMT-08:00)

Hi -

*If* this is approved (some issues have been raised on
the IETF list) are there any plans to make use of this
for netconf?

Randy

-----Forwarded Message-----
>From: The IESG <[email-masked]>
>Sent: Dec 13, 2013 9:16 AM
>To: IETF-Announce <[email-masked]>
>Cc: [email-masked]
>Subject: Last Call: <draft-ietf-tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard
>
>
>The IESG has received a request from the Transport Layer Security WG
>(tls) to consider the following document:
>- 'Transport Layer Security (TLS) Application Layer Protocol Negotiation
>   Extension'
>  <draft-ietf-tls-applayerprotoneg-03.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2013-12-27. Exceptionally, comments may be
>sent to [email-masked] instead. In either case, please retain the
>beginning of the Subject line to allow automated sorting.
>
>Abstract
>
>
>   This document describes a Transport Layer Security (TLS) extension
>   for application layer protocol negotiation within the TLS handshake.
>   For instances in which the TLS connection is established over a well
>   known TCP/IP port not associated with the desired application layer
>   protocol, this extension allows the application layer to negotiate
>   which protocol will be used within the TLS session.
>
>
>
>
>The file can be obtained via
>http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/
>
>IESG discussion can be tracked via
>http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/ballot/
>
>
>No IPR declarations have been submitted directly on this I-D.
>
>

---

From: Mohamad Badra <[email-masked]>
Date: Sat, 14 Dec 2013 02:24:56 +0400

> the IETF list) are there any plans to make use of this

NETCONF dosn't have the issue of version negotiation as with the case of
HTTP1&2, so how can this document be useful for this WG?

Best regards
Badra​​

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 13 Dec 2013 14:53:50 -0800

Hi -

> From: "Mohamad Badra" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, December 13, 2013 2:24 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
...
> HTTP1&2, so how can this document be useful for this WG?

Abstract claims:

Seems directly applicable to 5539bis, reducing or possibly eliminating
the need for a separate port.

Randy

---

From: Mohamad Badra <[email-masked]>
Date: Sat, 14 Dec 2013 03:08:08 +0400

On Sat, Dec 14, 2013 at 2:53 AM, Randy Presuhn <[email-masked]
> wrote:

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

​But there is already a port assigned for NETCONF over TLS since years.

​Best regards
Badra​

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 14 Dec 2013 17:08:04 +0100

> the need for a separate port.

At the next to last IETF, we got input from security folks that
swapping roles after the secure channel has been established is not a
good idea. I assume this document does the negotiation after the
security work, hence this would have the same issues, no?

/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: Sat, 14 Dec 2013 22:29:36 +0400

On Sat, Dec 14, 2013 at 8:08 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

> good idea.

Sometimes security folks say anything :)

​​

> I assume this document does the negotiation after the

The negotiation is done during the TLS handshake, not after the secure
channel has been established!
​​
​Best regards,
Badra​

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 14 Dec 2013 20:05:03 +0100

> Sometimes security folks say anything :)

I can't tell but they did point out that client/server certificates can
have very different properties.

> channel has been established!

Yep, so I took a quick look at the I-D. This allows everybody to read
which protocol is negotiated - not sure everybody will like this (but
won't matter here). I am not sure about the port number - we would
change the client/server role and I still believe assuming a
management system's call home port is different form the port used by
the netconf server on the management system - these might be very
different products and assuming they will be easy to configure to
share a port may not necessarily be true.

That said, are there any implementations of this ALPNE thing to play
with?

/js

---

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

> That said, are there any implementations of this ALPNE thing to play

MS Open Tech has contributed an open-source reference implementation of
ALPN.
Available as OpenSSL, Apache and mod_spdy patches:
http://html5labs.interopbridges.com/prototypes/alpn/alpn/info

Reference: http://www.ietf.org/proceedings/86/slides/slides-86-tls-1.pptx

Best regards
Badra​​