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

[[e-mail] (Martin Rex)]

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