Subject: [TLS] comments on draft-ietf-tls-applayerprotoneg-00

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 10 Apr 2013 10:16:47 +0200

Hello,
 Some comments on the ALPN document.

* At some point the document explains the term Protocols as: "are  named by
IANA registered, opaque, non-empty byte strings."

This is not very explanatory. The first question that arises, is which IANA
registry are these registered at? By reading the IANA considerations
section I see a new registry being created with protocol entries, so at
that point I can assume that this is the IANA registry intended, or not?
Anyway I think the text should clarify that the IANA registry it refers to
is defined in the same document.

* In section 3.1, the server replies with the same extension and sends a
ProtocolNameList containing a single Protocol. Why is then a list sent by
the server? Why not send a single Protocol instead? Is there any use case
where the client would accept more than one protocols? In that case should
clients be prepared for servers that send more than one protocols?

* In the same section it is mentioned: "The additional content associated
with this extension MUST be included in the hash calculations associated
with the "Finished" messages.". Why is that mentioned at all? Is there an
option in TLS not to include that data in the TLS finished message hashes?

regards,
Nikos

---

From: Andrei Popov <[email-masked]>
Date: Wed, 10 Apr 2013 17:40:21 +0000

Hi Nikos,

* Section 6 “IANA Considerations” says:

… We propose that this new registry be created in a new page entitled:
"Application Layer Protocol Negotiation (ALPN) Protocol IDs" beneath
the existing heading of "Transport Layer Security (TLS)".

Protocol IDs are first introduced in section 3.1 “The Application Layer Protocol Negotiation Extension”. Here we can add a reference to section 6 to make this more clear.

* In ALPN, the server cannot select more than one protocol (see sections 3.1 and 3.2). The reason the server is sending a protocol_name_list is that keeping client-side “extension_data” structure identical to the server-side “extension_data” structure simplifies both the documentation and the implementation.

* The text about the hash calculations was intended to make it absolutely clear that the content of the new extension is included in the hash calculations, and avoid any ambiguity. The need for this clarification arises from the fact that ALPN, unlike many other TLS extensions, negotiates parameters that have nothing to do with the TLS protocol itself.

Thanks,

Andrei

From: Nikos Mavrogiannopoulos [mailto:[email-masked]]
Sent: Wednesday, April 10, 2013 1:17 AM
To: [email-masked]; [email-masked]; Andrei Popov
Subject: comments on draft-ietf-tls-applayerprotoneg-00

Hello,
 Some comments on the ALPN document.
* At some point the document explains the term Protocols as: "are  named by IANA registered, opaque, non-empty byte strings."
This is not very explanatory. The first question that arises, is which IANA registry are these registered at? By reading the IANA considerations section I see a new registry being created with protocol entries, so at that point I can assume that this is the IANA registry intended, or not? Anyway I think the text should clarify that the IANA registry it refers to is defined in the same document.

* In section 3.1, the server replies with the same extension and sends a ProtocolNameList containing a single Protocol. Why is then a list sent by the server? Why not send a single Protocol instead? Is there any use case where the client would accept more than one protocols? In that case should clients be prepared for servers that send more than one protocols?

* In the same section it is mentioned: "The additional content associated with this extension MUST be included in the hash calculations associated with the "Finished" messages.". Why is that mentioned at all? Is there an option in TLS not to include that data in the TLS finished message hashes?

regards,
Nikos

---

From: [email-masked] (Martin Rex)
Date: Wed, 10 Apr 2013 22:26:10 +0200 (CEST)

Andrei Popov wrote:
> 
> Nikos Mavrogiannopoulos wrote:
> >
> > * In the same section it is mentioned: "The additional content
> >   associated with this extension MUST be included in the hash
> >   calculations associated with the "Finished" messages.".
> >   Why is that mentioned at all? Is there an option in TLS not
> >   to include that data in the TLS finished message hashes?
> 
> * The text about the hash calculations was intended to make it
>   absolutely clear that the content of the new extension is included
>   in the hash calculations, and avoid any ambiguity. The need for this
>   clarification arises from the fact that ALPN, unlike many other
>   TLS extensions, negotiates parameters that have nothing to do with
>   the TLS protocol itself.

I absolutely agree with Nikos, that this paragraph (4th pagagraph on)

   http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00#page-4

   The additional content associated with this extension MUST be
   included in the hash calculations associated with the "Finished"
   messages.

is completely bogus and has a creates several new ambiguities where
originally (rfc2246) non existed.

To the authors defense, a vaguely related (but different, and no less
bogus) paragraph is part of rfc3646/rfc4366/rfc6066  (TLS Extensions):

  http://tools.ietf.org/html/rfc3546#section-3
  http://tools.ietf.org/html/rfc6066#page-4

   Note that any messages associated with these extensions that are sent
   during the TLS handshake MUST be included in the hash calculations
   involved in "Finished" messages.
  
but that doesn't make it any less bogus nor less non-sensical
this time around.  ;-)

The governing part is the forward compatibility note
at the end of rfc2246 section 7.4.1.2, which was retroactively
added to the SSLv3 spec in November 1996:

   http://tools.ietf.org/html/rfc2246#page-36

   Forward compatibility note:
       In the interests of forward compatibility, it is permitted for a
       client hello message to include extra data after the compression
       methods. This data must be included in the handshake hashes, but
       must otherwise be ignored. This is the only handshake message for
       which this is legal; for all other messages, the amount of data
       in the message must match the description of the message
       precisely.

A similar note was retroactively inserted into the SSLv3 spec somewhere
around Oct-Nov. 1996 _after_ SSLv3 implementations had been widely deployed:

  http://tools.ietf.org/html/rfc6101#page-27

   Forward compatibility note: In the interests of forward
   compatibility, it is permitted for a client hello message to include
   extra data after the compression methods.  This data must be included
   in the handshake hashes, but must otherwise be ignored.

  http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0038.html

Neither excluding the entire "extra data after the compression methods"
in ClientHello, nor excluding specific subsets of such extra data
would be interoperable with mere "forward compatible" SSLv3 and TLS peers,
so it is simply **NO** option (and therefore no ambiguity).

The paragraph in rfc3546/rfc4366/rfc6066 is bogus, because

  - none of the TLS extensions defined in these documents adds/defines
    any (new handshake) messages, only (optional) "extra data following
    compression_methods" in the existing ClientHello and ServerHello
    messages.

  - the fact that the handshake message hash covers all data in the
    (Extended)ClientHello and (Extended)ServerHello handshake messages
    is in no way limted to the specific extensions defined in
    rfc3546/rfc4366/rfc6066, but a strict requirement to any conceivable
    TLS extension, different to what Section heading "3. Secific Extensions"
    and wording "any messages associated with these extensions" suggest.

  - the information is incorrect in that it alleges that it is involved
    (only) in hash calculations of the "Finished" messages.
    The truth is, that it is involved in all hash calculations involving
    "the handshake message hash", and that includes the "CertificateVerify"
    handshake message!

The paragraph in draft-ietf-tls-applayerprotoneg-00 is not just wrong,
but also ambiguous:

   The additional content associated with this extension MUST be
   included in the hash calculations associated with the "Finished"
   messages.

   http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-00#section-3

   enum {
       application_layer_protocol_negotiation(16), (65535)
   } ExtensionType;

   The "extension_data" field of the
   ("application_layer_protocol_negotiation(16)") extension SHALL
   contain a "ProtocolNameList" value.

   opaque ProtocolName<1..2^8-1>;

   struct {
       ProtocolName protocol_name_list<2..2^16-1>
   } ProtocolNameList;

What would "additional content associated with this extension" mean:
   - ProtocolNameList ?
   - protocol_name_list ?
   - extension_data (http://tools.ietf.org/html/rfc3546#section-2.3)
   - Extension      (http://tools.ietf.org/html/rfc3546#section-2.3)

In the original SSLv3 and TLS architecture, ALL contents of ALL
TLS handshake messages, with the explicit exception of the
"ClientHelloRequest" handshake message, are included in the
handshake message hash, and therefore in calculations that use
the handshake message hash, for CertificateVerify and Finished,
and this is not (really) an option at discretion of TLS extensions
specifications.

-Martin

---

From: Andrei Popov <[email-masked]>
Date: Wed, 10 Apr 2013 21:21:08 +0000

The purpose of the paragraph was disambiguation, and the paragraph obviously failed at this, so I am OK with removing it.

Thanks,

Andrei

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, April 10, 2013 1:26 PM
To: Andrei Popov
Cc: Nikos Mavrogiannopoulos; [email-masked]; [email-masked]
Subject: Re: [TLS] comments on draft-ietf-tls-applayerprotoneg-00

is completely bogus and has a creates several new ambiguities where originally (rfc2246) non existed.

  
but that doesn't make it any less bogus nor less non-sensical this time around.  ;-)

The governing part is the forward compatibility note at the end of rfc2246 section 7.4.1.2, which was retroactively added to the SSLv3 spec in November 1996:

A similar note was retroactively inserted into the SSLv3 spec somewhere around Oct-Nov. 1996 _after_ SSLv3 implementations had been widely deployed:

Neither excluding the entire "extra data after the compression methods"
in ClientHello, nor excluding specific subsets of such extra data would be interoperable with mere "forward compatible" SSLv3 and TLS peers, so it is simply **NO** option (and therefore no ambiguity).

The paragraph in draft-ietf-tls-applayerprotoneg-00 is not just wrong, but also ambiguous:

   enum {

   struct {

In the original SSLv3 and TLS architecture, ALL contents of ALL TLS handshake messages, with the explicit exception of the "ClientHelloRequest" handshake message, are included in the handshake message hash, and therefore in calculations that use the handshake message hash, for CertificateVerify and Finished, and this is not (really) an option at discretion of TLS extensions specifications.

-Martin

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 10 Apr 2013 14:33:22 -0700

> The purpose of the paragraph was disambiguation, and the paragraph obviously failed at this, so I am OK with removing it.

In the IKEv2 spec, the way we found to disambiguate what is and isn't covered by a signature or hash was to show it in ASCII art without explaining that the art was there for people who thought there were options when there were not.

--Paul Hoffman

---

From: "Stephan Friedl (sfriedl)" <[email-masked]>
Date: Wed, 10 Apr 2013 21:41:00 +0000

Agreed, dropping the paragraph is 100% fine with me.  I consulted a number of TLS extension RFCs, including RFC6066, and saw that point made a couple times so I included it as well.  It struck me as superfluous at the time but I agree that it raises ambiguities that ought not be raised.

Thanks for the feedback!

Best Wishes,

Stephan

-----Original Message-----
From: Andrei Popov [mailto:[email-masked]] 
Sent: Wednesday, April 10, 2013 3:21 PM
To: [email-masked]
Cc: Nikos Mavrogiannopoulos; [email-masked]; Stephan Friedl (sfriedl)
Subject: RE: [TLS] comments on draft-ietf-tls-applayerprotoneg-00

Thanks,

Andrei

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Wednesday, April 10, 2013 1:26 PM
To: Andrei Popov
Cc: Nikos Mavrogiannopoulos; [email-masked]; [email-masked]
Subject: Re: [TLS] comments on draft-ietf-tls-applayerprotoneg-00

  

   enum {

   struct {

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 11 Apr 2013 12:48:21 +0200 (CEST)

Ooops -- I need to correct my previous posting:

>     compression_methods" in the existing ClientHello and ServerHello

rfc3546/rfc4366/rfc6066 _do_ define two new TLS handshake
messages:  "certificate_url(21)" and "certificate_status(22)",
for use by the TLS extensions "client_certificate_url(2)" and
"status_request(5)" respectively, not just "extra data following
compression_methods" in the existing ClientHello and ServerHello
handshake messages.

I'm sorry for the confusion.

-Martin