Subject: [TLS] In ALPN, why is server response a MAY?

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Oct 2014 15:08:27 -0500

In the ALPN definition (RFC 7301), section 3.1, 
	Servers that receive a ClientHello containing the
	 "application_layer_protocol_negotiation" extension MAY return a
	 suitable protocol selection response to the client. 

Why isn't that a MUST? 

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 Oct 2014 13:51:56 -0700

>          suitable protocol selection response to the client.

I'm guessing that servers are able to pretend not to support ALPN at
their convenience.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Oct 2014 16:03:54 -0500

> I'm guessing that servers are able to pretend not to support ALPN at their
> convenience.

So then a client should assume that ALPN isn't supported and their request wasn't honored?\

---

From: Andrei Popov <[email-masked]>
Date: Wed, 8 Oct 2014 21:07:43 +0000

Also, servers and clients have more than one application negotiation mechanism available. As long as this is the case, servers get to choose which application negotiation mechanism to use. E.g. if a server receives a list of ALPN IDs and does not like any of them, the server might choose to give NPN a try rather than terminating the handshake right away.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Wednesday, October 8, 2014 1:52 PM
To: Salz, Rich
Cc: [email-masked] ([email-masked])
Subject: Re: [TLS] In ALPN, why is server response a MAY?

>          suitable protocol selection response to the client.

I'm guessing that servers are able to pretend not to support ALPN at their convenience.

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

---

From: Andrei Popov <[email-masked]>
Date: Wed, 8 Oct 2014 21:23:12 +0000

If the server does not reply to ALPN, I think a client can:
a) Attempt to proceed with some default application protocol (likely HTTP/1.1 for Web browsers), or
b) Use alternative application protocol negotiation mechanism, if available (e.g. application-specific negotiation after TLS handshake), or
c) Terminate the handshake if there is no useful default and no alternative protocol negotiation mechanism.

Cheers,

Andrei

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 9 Oct 2014 01:37:56 +0400

Backward compatibility is one of the main reasons
Best regards
Badra

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Oct 2014 16:39:22 -0500

> Backward compatibility is one of the main reasons

I don't understand that.  The client SENT an ALPN.  So what is the compatibility issue?
--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 9 Oct 2014 01:48:19 +0400

This means that TLS clients that support the extension can talk to TLS
servers that do not support the extensions, and vice versa. TLS extensions
are designed to be backwards compatible.

Best regards
Badra

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Oct 2014 16:53:09 -0500

That doesn't make sense.  TLS already says is the server doesn't know an extension it should ignore it. So why have an extension and define a response that is a MAY?  As Andrei suggested, you might want to defer to other negotiation.  Well, okay, but it seems hacky.  By making the response a MAY, the client doesn't know if it's unsupported, or supported, or supported and request was granted.  So it seems like if the response doesn't come back, the client MUST treat it as if the server does not support ALPN.

--
Principal Security Engineer, Akamai Technologies
IM: [email-masked]<mailto:[email-masked]> Twitter: RichSalz

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 09 Oct 2014 09:53:30 +0200

On Wed, 2014-10-08 at 16:53 -0500, Salz, Rich wrote:
> That doesn’t make sense.  TLS already says is the server doesn’t know
> an extension it should ignore it. So why have an extension and define
> a response that is a MAY? 

This is how all extensions are being defined. That way the backwards
compatibility is explicit as Mohamad said.

regards,
Nikos