Re: [TLS] Next steps for draft-ietf-tls-renegotiation

[Stefan Santesson <[e-mail]>]

Nico,

I think your characterization is very good.
And I would also much rather have a fail-safe solution.

As you say, no approach today is totally extension less, so the big
difference remaining IMO is:

1) The fail-unsafe approach based on sending verify_data in extensions.

2) The Fail-safe approach based on injecting varify_data into the handshake
hash calculation, but not sending them over the wire. (This approach uses
extensions for signaling but with absent data)

Everything else is more or less the same.

I think we have demonstrated that the fail-safe alternative can be designed
in a secure manner.


/Stefan



On 09-11-30 6:07 PM, "Nicolas Williams" <[e-mail]> wrote:

> On Fri, Nov 27, 2009 at 11:26:34PM +0100, [e-mail] wrote:
>> <wearing Area Director hat>
>> 
>> I have asked the secretariat to start IETF Last Call for
>> draft-rescorla-tls-renegotiation-01.
>> 
>> I've gone through the list archives for the past month, and it seems a
>> large majority of the WG members support the overall approach in this
>> draft (with a small, but very vocal, minority preferring a totally
>> extension-less approach to signalling).
> 
> I don't think that's a fair nor complete characterization of the current
> differences of opinion.  A more complete and correct characterization
> might be:
> 
>  - The RI proposal has a fail-unsafe requirement that peers check the
>    contents of the extensions sent.
> 
>    NOTE: A fix for this wouldn't require an extension-less signalling
>          solution.
> 
>    [IMO: This is serious objection that goes beyond protocol design
>          aesthetics or ease of retrofitting for SSLv3.  I think we can
> live without a fix for this problem, but I'd much rather have a
> fail-safe solution.]
> 
>  - There seems to be a desire, among some, for a signalling solution
>    that is somehow easier to retrofit for SSLv3 implementations.  This
>    couldn't be an extension-less scheme, since some bits are needed to
>    signal the use of the fix in the client's initial hello, but it might
>    avoid the use of server hello extensions.
> 
>    [IMO: This is a concern that we can safely ignore.]
> 
> Nico