Re: [TLS] draft-ietf-tls-renegotation: next steps

[Martin Rex <[e-mail]>]

[e-mail] wrote:
> 
> - Whether to prohibit sending the extension (in initial ClientHello),
> or require the magic cipher suite even if the extension is sent (in
> initial ClientHello): The consensus is again a bit rougher than we'd
> normally hope to see, but the current text (either is allowed) has
> more support (about 2/3 vs. 1/3), so we keep it. And again, I believe
> most participants prefer make some decision over continuing the
> discussion.

I'm sorry for creating a confusion and dispute about this.
Allowing the sending of an empty extension RI on initial ClientHello
should not be a problem and I would find a MAY perfectly acceptable.

The real important thing is, that the inclusion of the MCSV is
a MUST, because it will reduce the procotol complexity and robustness
and allow absolutely _every_ implementer to save code.


> - There was some discussion on whether to add the magic cipher suite
> to patched renegotiation ClientHellos (in addition to the extension),
> too. I believe rough consensus is not to do this.

I have a VERY strong objection to leave out the MCSV from any
ClientHellos.  It will save everyone code if we mandate the
use of MCSV on all ClientHellos including secure renegotiation
ClientHellos, and it will make the protocol *MUCH* more foolproof.

 
> 
> - The current draft doesn't clearly say what should be included in
> legacy (insecure) renegotiation ClientHellos. I am not sure if we have
> enough clear opinions to call consensus, but keeping it aligned with
> the initial ClientHello (either MSCV or extension) seems to be one
> simple approach (but I hope to see the actual text).

Again, the choice is obvious: MCSV, *NO* extension.

Anything else just makes no sense and may obviously cause interop
problems for some backwards interop scenarios, because it is
a backwards-incompatible change.


About the backwards interop scenarios in general:

Can we please discontine the misleading terminology "lenient client/server"
and instead refer to the specific backwards interop scenarios that
we address with a recommendation?

(1)  updated client allowing initial handshakes with old servers
(2)  updated client allowing renegotiation handshakes with old servers
(3)  updated server allowing initial handshakes with old clients
(4)  updated server allowing renegotiation handshakes with old clients

As i previously mentioned, I think that we want to get rid of
(4) as fast as we can (SHOULD NOT), hope to get rid of (2)
at the end of the transition period (MAY), and leave (1) and (3)
completely to the consumers of the technology.

I'm strongly opposed to any suggestions to impair (1) or (3) in
the solution we ship.


> 
> I realize that not everyone will be happy with these decisions, but in
> my judgment as Security Area Director, the choices are in line with
> the rough community opinion, and are technically reasonable (many
> other choices would have been reasonable, too). In particular, I
> believe that continuing these discussions until some indeterminate
> time in 2010 would not be in the best interest of the community (many
> of whom have expressed that they prefer an OK solution this year,
> instead of possibly-slightly-improved one next year).


I do not agree to your determination of rough consensus.

rfc4677, 5.2 Getting Things Done in a Working Group

   Another aspect of Working Groups that confounds many people is the
   fact that there is no formal voting.  The general rule on disputed
   topics is that the Working Group has to come to "rough consensus",
   meaning that a very large majority of those who care must agree.

   The lack of formal voting has caused some very long delays for some
   proposals, but most IETF participants who have witnessed rough
   consensus after acrimonious debates feel that the delays often result
   in better protocols.  (And, if you think about it, how could you have
   "voting" in a group that anyone can join, and when it's impossible to
   count the participants?)  Rough consensus has been defined in many
   ways; a simple version is that it means that strongly held objections
   must be debated until most people are satisfied that these objections
   are wrong.


It just doesn't feel right if some peoples feelings about aesthetics
are considered more important than other peoples technical issues.


-Martin