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

[Marsh Ray <[e-mail]>]

Martin Rex wrote:
> Marsh Ray wrote:
>>> But as I described,
>>> these are going to be servers that do not renegotiate anyway,
>> TLS does not define such a thing as a "server that does not
>> renegotiate". There may be in fact some application protocols or servers
>> which do not, but TLS provide no way to indicate this in the handshake.
> 
> As evident from rfc-5246 Appendix D. renegotiation is an optional
> feature of the SSLv3/TLS protocol family and not available in all
> implementations of SSLv3/TLS.
> 
> Since you are still listed as an author of the spec,

(Shhh...I'm hoping they don't catch on.)

> I consider
> your interpretation fairly authoritative for what the spec intends
> to say.

As you wish, I shall interpret this matter to the full extent of my
authority.

> --which means that there is a defect, because it does currently
> _not_ specify the behaviour for non-renegotiating servers

A protocol spec that says "this is how an initial handshake is to be
done" and "this is how a renegotiating handshake works" is not defective
simply because some uses of the protocol choose not to do renegotiation.

> (which you incorrectly assumed to not exist).

I have done nothing of the sort. I am quite sure there are TLS clients
and servers which absolutely do not renegotiate. I don't think any of
the widely used general purpose implementations are in that category.

But the TLS specs don't define this in the protocol such that it can
communicated as part of the handshake which establishes the security
parameters. Therefore it is not useful in making security decisions at
the TLS level.

> Please fix this defect _before_ publishing this specification.

I don't see it, sorry.

> The only reason why secure TLS renegotiation can be considered
> an update to the existing installed base at all (and not a different
> non-interoperable protocol), is that renegotiation has never been
> a core element of SSLv3/TLS and is optional-to-implement.

That doesn't make sense to me.

> Essentially, the secure renegotiation spec is deprecating the
> old renegotiation and defining a new, optional, secure renegotiation.

Don't forget the initial handshake has new requirements, too.

> Describing potential vulnerabilities from using backwards-interoble
> renegotiation with the installed base and discouraging the use of
> that old optional feature is fine.  Encouraging the use the
> new optional and secure renegotiation is also no problem.
> Describing security implications of old TLS peers that still
> offer old renegotiation is also no problem.
> 
> Discouraging the interoperability with compliant but
> not updated SSLv3->TLSv1.2 on the core protocol elements
> (aka initial TLS handshake) is inacceptable,

Yes, my personal and professional mission is to discourage
interoperability where such interoperability does not deliver the stated
and implied guarantees for the security of the data. Too bad if you
don't like it.

My own livelihood, as well as that of most of my friends, depends pretty
directly on the security of this protocol. I have personally recommended
enough SSL/TLS-based soultions at this point that I feel quite obligated
to work on keeping it healthy.

Nevertheless, the wording of the current spec leaves the option of
interoperating (possibly insecurely) with unpatched endpoints up to
vendors and their customers to decide. My personal recommendation is to
be in this compatible mode for as short a time as possible because it
does not offer the full security guarantees intended for TLS. And I'm
not letting folks go around making misrepresentations about the security
of broken versions of it.

> because it would
> make updated TLS peers non-compliant with the original TLS spec,
> which implies these peers are using a different protocol.

As well they should, because the current SSLv3 and TLS specs are broken,
in a worse way even than SSLv2.

- Marsh