Subject: [TLS] NPN, ALPN and the case of renegotiation

From: Fabrice Gautier <[email-masked]>
Date: Fri, 10 Jan 2014 11:16:51 -0800

Hi,

When reading both NPN and ALPN drafts,  I notice they both have this paragraph:

   Unlike many other TLS extensions, this extension does not establish
   properties of the session, only of the connection.  When session
   resumption or session tickets [RFC5077] are used, the previous
   contents of this extension are irrelevant and only the values in the
   new handshake messages are considered.

However, only NPN has that one, immediately following:

   For the same reasons, after a handshake has been performed for a
   given connection, renegotiations on the same connection MUST NOT
   include the "next_protocol_negotiation" extension.

On the other hand, ALPN has this one a little further down:

   The protocol identified in the
   "application_layer_protocol_negotiation" extension type in the
   ServerHello SHALL be definitive for the connection.  The server SHALL
   NOT respond with a selected protocol and subsequently use a different
   protocol for application data exchange.

The question is: Should/can NPN/APLN extensions be sent/processed
during a renegotiation handshake ?

So far I'm only confidently interpreting the above as:
0) If NPN protocol was successfully selected during a handshake, the
client should not send a NPN extension in its next client hello.

I'm unsure of those other details though:
1) If client sent an NPN extension in a ClientHello and did not get
back an NPN  extension in the ServerHello, should/may the NPN client
try the NPN extension again in a re-handshake?

I'm assuming it should not.
But somebody might come up with a reason for not wanting to provide
the supported protocols in the clear. Although one would argue that if
Application Data is sent between the two handshake, then a protocol is
selected and you should not be able to change it with NPN extensions,
so the client must not send the NPN extension in the renegotiation if
they already received or sent some application data.

2) If a client sent an ALPN extension in the first ClientHello, can it
send it again in a further negotiation ?

I'm assuming it may, unless protocol was selected explicitly with a
ALPN ServerHello extension, or implicitly by sending/receiving some
application data.

3) If a client didn't send an NPN extension in the first ClientHello,
may it send it in the next handshake ?

I'm assuming it should not. and I don't really see a privacy angle in that case.

4)  If a client didn't send an ALPN extension in the first
ClientHello, may it send it in the next handshake ?

I'm assuming yes. This is useful in case you want to hide the
protocols supported and selected in a renegotiation (as indicated in
Section 4 of ALPN draft) Although again, if a protocol was implicitly
selected by sending/receiving data, it probably should not.

Are my assumptions mostly correct ?

Thanks

-- Fabrice

---

From: Andrei Popov <[email-masked]>
Date: Fri, 10 Jan 2014 21:08:48 +0000

Hi Fabrice,

I cannot speak to the design of NPN, but will answer the ALPN questions:

2) If a client sent an ALPN extension in the first ClientHello, can it send it again in a further negotiation ?
Yes, the client\server can renegotiate the application protocol at any time.

4)  If a client didn't send an ALPN extension in the first ClientHello, may it send it in the next handshake ?
Yes, this can be used e.g. to make the application protocol negotiation confidential.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Fabrice Gautier
Sent: Friday, January 10, 2014 11:17 AM
To: <[email-masked]>
Subject: [TLS] NPN, ALPN and the case of renegotiation

Hi,

The question is: Should/can NPN/APLN extensions be sent/processed during a renegotiation handshake ?

So far I'm only confidently interpreting the above as:
0) If NPN protocol was successfully selected during a handshake, the client should not send a NPN extension in its next client hello.

I'm unsure of those other details though:
1) If client sent an NPN extension in a ClientHello and did not get back an NPN  extension in the ServerHello, should/may the NPN client try the NPN extension again in a re-handshake?

I'm assuming it should not.
But somebody might come up with a reason for not wanting to provide the supported protocols in the clear. Although one would argue that if Application Data is sent between the two handshake, then a protocol is selected and you should not be able to change it with NPN extensions, so the client must not send the NPN extension in the renegotiation if they already received or sent some application data.

2) If a client sent an ALPN extension in the first ClientHello, can it send it again in a further negotiation ?

I'm assuming it may, unless protocol was selected explicitly with a ALPN ServerHello extension, or implicitly by sending/receiving some application data.

3) If a client didn't send an NPN extension in the first ClientHello, may it send it in the next handshake ?

4)  If a client didn't send an ALPN extension in the first ClientHello, may it send it in the next handshake ?

I'm assuming yes. This is useful in case you want to hide the protocols supported and selected in a renegotiation (as indicated in Section 4 of ALPN draft) Although again, if a protocol was implicitly selected by sending/receiving data, it probably should not.

Thanks

-- Fabrice
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Fabrice Gautier <[email-masked]>
Date: Fri, 10 Jan 2014 13:25:41 -0800

> Yes, this can be used e.g. to make the application protocol negotiation confidential.

Then I suggest that the following sentence in the ALPN draft be
reworded to clarify this:

  "application_layer_protocol_negotiation" extension type in the
  ServerHello SHALL be definitive for the connection.

At least something like: "SHALL be definitive for the connection,
until renegotiated”

This raise another question: if the Application Protocol is
renegotiated when does the new application protocol starts?
I’m assuming that it would be for new Application Data received after
the ChangeCipherSpec and Finished messages, and that any Application
that may be interleaved with the earlier handshake message should
still use the previous application protocol.

— Fabrice

---

From: Adam Langley <[email-masked]>
Date: Fri, 10 Jan 2014 16:43:10 -0500

> client should not send a NPN extension in its next client hello.

Correct.

> try the NPN extension again in a re-handshake?

It probably could. Although for sanity's sake I hope that there was no
application data sent in the first handshake.

I think you'll find that actual implementations of NPN just reject it
on renegotiation and I don't ever recommend that anyone uses
renegotiation, but one could make an argument for doing it under
encryption.

In any case, NPN is not a going concern at this point.

> send it again in a further negotiation ?

Assuming that the server answers: Andrei thinks yes, but I think the
answer is no :)

If the first application protocol could synchronise the switch then it
could possibly work but, at that point, just negotiate the new
protocol at the application layer. For simplicity's sake I would
ignore ALPN in a renegotiation.

> may it send it in the next handshake ?

See answer to (1)

> ClientHello, may it send it in the next handshake ?

Yes, although again, for sanity's sake I hope that there was no
application data sent in the first handshake.

You can ignore all these problems and several more by simply not
supporting renegotiation :)

Cheers

AGL

---

From: Andrei Popov <[email-masked]>
Date: Fri, 10 Jan 2014 21:58:32 +0000

Yes, both of these clarifications make sense to me. I think we should consider clarifying this in the draft.

Thanks,

Andrei

-----Original Message-----
From: Fabrice Gautier [mailto:[email-masked]] 
Sent: Friday, January 10, 2014 1:26 PM
To: Andrei Popov
Cc: <[email-masked]>
Subject: Re: [TLS] NPN, ALPN and the case of renegotiation

> Yes, this can be used e.g. to make the application protocol negotiation confidential.

Then I suggest that the following sentence in the ALPN draft be reworded to clarify this:

At least something like: "SHALL be definitive for the connection, until renegotiated"

This raise another question: if the Application Protocol is renegotiated when does the new application protocol starts?
I'm assuming that it would be for new Application Data received after the ChangeCipherSpec and Finished messages, and that any Application that may be interleaved with the earlier handshake message should still use the previous application protocol.

- Fabrice

---

From: Fabrice Gautier <[email-masked]>
Date: Fri, 10 Jan 2014 14:11:00 -0800

> supporting renegotiation :)

You mean not supporting TLS renegotiation in general? I'm afraid I
can't do that until there is an RFC obsoleting it. But yeah, that
would simplify a lots of things.

If you mean renegotiating the application protocol, the draft opens
the door to it, so I think it is important for TLS implementer to know
how to handle those cases.

---

From: Fabrice Gautier <[email-masked]>
Date: Fri, 10 Jan 2014 14:17:50 -0800

> Yes, both of these clarifications make sense to me. I think we should consider clarifying this in the draft.

Also consider clarifying that, in the case of a renegotiation without
ALPN extensions, after an initial handshake with ALPN extensions, the
application protocol should remain the same, and not fall back to the
"sane default".

Thats probably obvious, but you would not want a browser to fall back
to http 1.1 instead of http 2.0 or spdy because of a TLS
renegotiation.

-- Fabrice

---

From: Andrei Popov <[email-masked]>
Date: Fri, 10 Jan 2014 23:12:35 +0000

Regarding the "sane default", I could see this both ways, and I don't think this  belongs in a document produced by the TLS WG. 

ALPN allows applications negotiate (and renegotiate) an application protocol. What application protocol should be used in the absence of ALPN, whether it's a "sane default", whether it's the same application protocol previously negotiated with this server, etc. - all this is highly application-specific, and belongs in the corresponding application RFC. In your example of HTTP/1.1 vs. HTTP/2, I would expect the HTTP/2 spec to define this.

-----Original Message-----
From: Fabrice Gautier [mailto:[email-masked]] 
Sent: Friday, January 10, 2014 2:18 PM
To: Andrei Popov
Cc: <[email-masked]>
Subject: Re: [TLS] NPN, ALPN and the case of renegotiation

> Yes, both of these clarifications make sense to me. I think we should consider clarifying this in the draft.

Also consider clarifying that, in the case of a renegotiation without ALPN extensions, after an initial handshake with ALPN extensions, the application protocol should remain the same, and not fall back to the "sane default".

Thats probably obvious, but you would not want a browser to fall back to http 1.1 instead of http 2.0 or spdy because of a TLS renegotiation.

-- Fabrice

---

From: Fabrice Gautier <[email-masked]>
Date: Fri, 10 Jan 2014 15:28:01 -0800

> ALPN allows applications negotiate (and renegotiate) an application protocol. What application protocol should be used in the absence of ALPN, whether it's a "sane default", whether it's the same a…

True, since the TLS renegotiations are normally triggered by something
at the application level anyway.

-- Fabrice

---

From: Martin Thomson <[email-masked]>
Date: Sat, 11 Jan 2014 13:45:00 -0800

> Regarding the "sane default", I could see this both ways, and I don't think this  belongs in a document produced by the TLS WG.

That's right.  For HTTP, it's fairly obvious that absent ALPN, we get
HTTP/1.1 (or predecessors).  It might be different for new protocols,
but new protocols also get to consider the option of making ALPN "MUST
use".