Re: [TLS] Redefine Finished message for TLS 1.3 ?

[Nicolas Williams <[e-mail]>]

On Sat, Nov 14, 2009 at 11:13:23AM -0800, Nelson B Bolyard wrote:
> On 2009-11-13 08:46 PDT, Nicolas Williams wrote:
> > The post with message-ID <[e-mail]>, subject
> > "Comments on draft-rescorla-tls-renegotiate", sent at 18:54:19 -0600
> > yesterday most certainly described no Hello extensions, only a Finished 
> > message verify_data computation change.
> 
> EKR and Marsh Ray and some others will recall that I proposed essentially
> the same proposal that Nico is now proposing in the meeting meeting in
> Mountain View on September 29, 2009 to which Marsh Ray invited EKR, myself
> and numerous others from this working group.
> 
> I proposed that a change in the computation of the TLS Finished message
> to include some value derived from the master secret previously in use on
> the connection before the current renegotiation (such as the Finished
> message contents or some other value "extracted" from the master secret)
> would avoid the overhead of the new extensions on the wire.  My goal was
> to avoid the extra bandwidth and memory cost of those extensions, which
> might be deemed too costly in certain low memory or bandwidth constrained
> applications.
> 
> Others in the meeting responded that changing the definition of the
> computation of the Finished messages was a change to the base protocol
> specification (which adding an extension is not), and thus the change
> I proposed would make TLS become (say) TLS 1.3.

All things considered, I bet that the finished message verify_data
computation change is the simplest one to make.  Saying that because it
falls outside the spectrum of extensions that can be considered in TLS
1.0-1.2 it can't be considered is a bit of a stretch.  Imagine if we had
no client hello extensions, or that we couldn't use them because in
practice support for them was very spotty, then we'd have to resort to
this approach and no one would say "but we can't unless we call it TLS
1.3"!

That said, I don't think we need to change EKR's proposed fix.  My
purpose in throwing it out, with the big caveat that I included, was to
get those who are worried about SSLv3 to provide specific rationales for
why an extension-less approach should be preferable.  I.e., I was trying
to condense the SSLv3 sub-threads.

> But perhaps we should regard the new extension as a short term expedient,
> and plan to change the definition of the Finished message in TLS 1.3,
> so that the extension will no longer be necessary at some point in the
> future (when TLS 1.3 has become common place, maybe 10 years hence).

There's a certain, er, desire for something like a "secure bit" that can
be used to passively detect broken implementations.  With EKR's fix we
get that bit.  I don't really care for that bit: servers should be
patched, period, rejecting re-negotiations from unpatched clients, and
clients should be patched and should refuse to complete re-negotiation
with unpatched servers and complain _loudly_ about them -- that is the
least that we need, and IMO also all we need.

> Does the Working Group share interest in redefining the Finished message
> computation for TLS 1.3?

I doubt it.  Once the use of hello extensions is demonstrated to work
even for critical cases and when server hello extensions are needed,
then there's no need to change to using an unsignalled fix as in your/my
proposals.

However, I personally very much like the idea of a generic channel
binding facility in TLS, not so much for the purpose of channel binding
TLS to other channels (since EKR's fix takes care of the one case where
we need that) but for providing support to StartTLS-style applications
for authenticating pre-StartTLS negotiations.  For that, your/my
proposals will do (only using application-provided data as the "channel
bindings").

Nico
--