Re: [TLS] Proposal for hybrid solution using most of the ideas

[Martin Rex <mrex at sap.com>]

Nasko Oskov wrote:
> 
> Yes. The idea is to have an specially defined "empty" certificate that will
> indicate to the client support for the new running hash computation.
> 
> >I think (a) would be a bad idea. Not sure about (b) either, but at least it
> >wouldn't bring a whole new bunch of parties to the table (CA product
> >vendors and service providers) when something quick is what's needed.
> 
> (a) and (b) will be too complex of changes and unnecessary complications.


Somehow it seems that the discussion are diverging more and more.


Personally, I'm OK with what TLS extension RI does at an abstract level.
I just don't like how it is added into the existing protocols because
of the interop issues of TLS extensions with existing usage scenarios.


I'm getting slightly beaten up for "modifying the handshake message
hash algorithm" because it is a change of the protocol and next
I getting slightly beaten up for conveying this protocol change
in through the ProtocolVersion server_version field.


You are now proposing to put something in a list of certificates
that is not a certificate, in a handshake message that is not
sent in some of the handshakes to modify the message hash computation.


Inserting the Finished messages as the first data before ClientHello
into the handshake message hash seems problematic,
because:

  -    it doesn't work for scenarios where the client wants to use
       renegotiation for client identity protection and sends the
       next ClientHello piggy-backed on the ClientFinished message
       of the initial handshake.

  -    it is much more difficult for vendors/suppliers to offer
       a backwards interop for renegotiation for whatever reason,

if the finished messages are inserted directly following the
ServerHello handshake messages, then these two problems don't exist.


I'm going back to work on my I-D now.

-Martin