Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> At Thu, 3 Dec 2009 01:38:10 +0100 (MET), Martin Rex wrote:
> > 
> > Nelson B Bolyard wrote:
> > > > 
> > > > Hold on now, is there any reasonable interpretation of
> > > > draft-ietf-tls-renegotiation which "codifies the behavior of those
> > > > non-conformant servers"?
> > > 
> > > Any proposal which would have us send the "Magic Cipher Suite" *INSTEAD OF*
> > > (rather than in addition to) the RI extension is such an attempt.
> > > Such proposals now exist.
> > 
> > It is not the first of it's kind.
> > 
> > The first is called rfc-5246, which is at proposed standard for a year
> > and contains a broken TLS extensions definition called signature_algorithm,
> > where the Server _uses_ the extension but MUST NOT confirm its use
> > through ServerHello.
> 
> To be honest, I don't recall the discussion that led to us prohibiting
> the server from sending this extension at all, however I don't believe
> it was about codifying the behavior of nonconformant servers. Rather,
> (and my vague memory is that Pasi proposed this text so maybe he
> remembers better) it was that this was a signal from the client to the
> server and there was an existing method for the server to signal its
> preferences when it wanted a signature, so there didn't seem to be
> much point in the server sending anything back.
> 
> Note that I'm not saying this was necessarily the best design decision
> in the history of the universe, but I'm not sure why you're saying it's
> broken.

It breaks the negotiation architecture:
   C->S   (Extended)ClientHello
   S->C   (Extended)ServerHello

I think that this negotiation architecture is useful.

And I don't mind when MCSV is going to be the only cipher suite value
that is given the "I'm an extension" status for the forseeable future
(we do require WG consensus and IESG approval for this anyway).

What I do not like is an overly religious attitude that is against
the intention and spirit of TLS extension described by this
previously quoted statement from rfc-3546:

   Clients typically request the use of extensions via the extended
   client hello message described in Section 2.1.


Trying to avoid vagueness in a spec is OK, but the choice of very
restrictive wording in order to avoid vagueness might turn out to
be too restrictive for some real world requirements, and then
it is sometimes necessary to apply common sense and re-focus on
the intent behind a restriction and not hopelessly stick to the
words (that were chosen with a different mindset).


Too restrictive words for the "change of identities" during
renegotiation may also do a lot of harm.


-Martin