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 11:33:22 -0800 (GMT-08:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Dec 14, 2013 8:08 AM
>To: Randy Presuhn <[email-masked]>
>Cc: [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
>
>On Fri, Dec 13, 2013 at 02:53:50PM -0800, Randy Presuhn wrote:
>> 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
>> ...
>> > 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?
>> 
>> Abstract claims:
>>    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.
>> 
>> Seems directly applicable to 5539bis, reducing or possibly eliminating
>> 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?

The client requests the protocol in the clear, before the
key exchange.  

Randy