Pasi,

Thanks for a good and clarifying mail.

Yes, all proposals are currently using extensions for the server to client
signaling and all proposals are currently using the magic CipherSuite only
for client to server signaling on initial handshakes.

This will also be reflected in the new alternative draft to be posted,
hopefully within 24 hours from now.

In this sense the two approaches are a lot closer now.

The major difference now is that one proposal includes the data in the
extensions and is fail-unsafe, while the alternative feeds that data
directly into the handshake hash calculation and is fail-safe.

There are minor differences also in the signaling on renegotiations, but I
regard that as minor.

/Stefan



On 09-11-30 9:38 PM, "Pasi.Eronen@nokia.com" <Pasi.Eronen@nokia.com> wrote:

> <wearing Area Director hat>
> 
> Stefan Santesson wrote:
> 
>>> 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 made a count through all people that has raised their voice on
>> this list and included all e-mail that was sent the past week. I
>> don't think it is fair to include any statements older than that.
>> 
>> This is my count:
>> 
>> Support an alternative solution: 6 people
>> Open for an alternative solution: 3 people
>> Neutral: 4 People
>> Support the current tls draft: 7 people
>> Conditional support for the current draft: 2 people
>> 
>> Looks fairly even to me.
> 
> I think this depends very much on what you mean by the "alternative
> solution" -- it seems you're not referring to, for example,
> draft-mrex-tls-secure-renegotiation-01.
> 
> In my quoted text above, the "large majority" referred mostly to
> people who've said using TLS extensions (in one way or another) is OK,
> and the "small minority" was objecting to proposals involving TLS
> extensions in any way. (In this question, I do not think ignoring
> opinions expressed more than 7 days ago is a reasonable way to judge
> the situation.)
> 
> However, in your later email (on Monday) you seemed to say that we
> have settled this issue already:
> 
>> 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.
> 
> This surprised me a bit (but possibly the surprise is a positive one).
> I would be interested in hearing from folks who've earlier opposed the
> use of extensions whether this reflects their current views, too.
> 
> If it does, I think we've made a lot of progress, and can still tweak
> the final difference (whether to send verify_data over-the-wire or not)
> based on discussion during the IETF last call.
> 
> I do not claim that a large majority currently strongly prefers
> sending the old verify_data over-the-wire in the extension data. Much
> smaller number of people (compared to the signalling issue) have
> expressed any opinions about this, and also, I would expect that a
> smaller number of people care very strongly either way.
> 
> And BTW, in this question I agree that counting opinions expressed
> much more than a week ago probably isn't that good. So if someone
> (any reader of this message) cares very strongly either way,
> I would suggest saying so on the list (if you haven't done so
> already recently).
> 
> Best regards, 
> Pasi