Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
> Uri Blumenthal wrote:
> 
> > OK. Karlsruhe server time-outs on me, so no chance to get enlightened
> > by checking that thread. Please indulge me: the one short compelling
> > reason why we don't want to say "when two signals are present use this
> > one and ignore the other" instead of "when two signals are present -
> > abort connection" - is...?
> 
> Well, if the spec says "the client MUST not send two signals", then if
> two signals are present, it's probably safer to abort (since the
> client is not following the spec anyway, it's hard to guess
> what its intent was...)

There would only be an ambiguity when the signal could indicate
two different semantics.


The description of the semantics of TLS_RENEGO_PROTECTION_REQUEST
in draft-tls-renegotiation-02 is defective and needs to be fixed.

The currently flawed defintion for TLS_RENEGO_PROTECTION_REQUEST
is what caused this:

  http://www.ietf.org/mail-archive/web/tls/current/msg05155.html
  http://www.ietf.org/mail-archive/web/tls/current/msg05186.html

and resulted in this text in draft-tls-renegotiation-02.txt:

  6.1  Client Considerations

   [TODO:  this needs a discussion of what signal to send in legacy
   renegotiation to match the resolution of the paired TODO in Section
   4.]


The purpose of TLS_RENEGO_PROTECTION_REQUEST is to request _ONLY_ the
new handshake semantics (which first-of-all concerns those peers
in the communication that are performing a renegotiation handshake).

The resistence to adopting the correct semantics for
TLS_RENEGO_PROTECTION_REQUEST is probably because from the viewpoint
of formal correctness proofing, the correct definition implies that
this signal MUST be asserted on every ClientHello (because the absence,
that would then indicate "old handshake semantics" would be incompatible
with the presence of an TLS extension RI.

But for the old renegotiation scenario, the result of the correct
definition of TLS_RENEGO_PROTECTION_REQUEST would provide an obvious,
intuitive and fully backwards interoperable solution.  
In addition, everyone would save code, and the solution would
become less complex.


What makes me feel slightly uneasy is that some people think the
above is a special case that needs to be seperately addressed
in the document.  With a clean architecture, that is no special
case.  The problem with draft-tls-renegotiation-02 is, that it
comes without architecture.  It is an implementation of an
unspecified solution architecture.  And that leads to discussions
about belief, rather than characteristics of a specific
(spec-level) implementation of a solution architecture, where
it is possible to check implementation details with methodologies
used in formal correctness proofs.


The reason why the TLS renegotiation vulnerability was not noticed
for so long is quite related to this.  The SSL and TLS protocols
completely failed to describe its architecture, otherwise the
defect would have been obvious.  Once I had described the
architecture of TLS renegotiation to Larry and Nico in the
discussion about channel bindings early November, it became
obvious to me, from last paragraph of this:

  http://www.ietf.org/mail-archive/web/tls/current/msg03922.html

to this:

  http://www.ietf.org/mail-archive/web/tls/current/msg03928.html


And that applies to all other problems recently discussed.
The lack of an (explanation of) the architecture hides most
of the problems, like identity change during renegotiation,
the possibility of application data interleaved with renegotiation
handshakes, the effect of TLS session resumption and TLS session
caching strategies on certificate path validation.


-Martin