Martin Rex wrote:
> Marsh Ray wrote:
>>
>> That is interesting information. Would you happen to have a copy of the
>> last "official" spec you can send me?
> 
> Netscape's official SSLv3 spec as of 2005:
> http://web.archive.org/web/20050207004652/wp.netscape.com/eng/ssl3/3-SPEC.HTM

Thanks.

That's pretty clear, SSLv3 did not have a provision for extending Client
Hello.

> As obvious from it's name that spec is a product of the TLS WG and
> the TLS WG decided to completely abandon (instead of publishing as
> informational RFC) that document so that it expired and vanished
> from the I-D repository 6 month later.

Seems like SSLv3 was simultaneously one of the most critical protocols
for net security and orphaned.

>> Servers receiving an initial connection request without a request for RI
>> will soon know some things:
>>
>> 1. The client software is not patched for security.
>>
>> 2. There's a good chance the client is vulnerable to one or more
>> variants of this basic attack.
> 
> If that is the impression that the current draft-ietf-tls-renegotiation-01
> leaves with you, then this draft needs MAJOR updates of the description,
> because it is not correct.

I meant "request for RI" in the general sense which also includes MCSV.

> One obvious problem with draft-ietf-tls-renegotiation-01.txt is that
> is extremely underspecified.  The TLS extension RI is overloaded in
> semantics, and the spec doesn't spell it out.

You're way overstating it. Sure, there will be a few things added to the
next version.

> In the original definition (without MCSV) TLS extension RI conveys
> three distinct pieces of information:
> 
>   1.) indication that the TLS peer is updated for secure renegotiation
>       (1 bit of information)

Yes.

>   2.) indication of whether the TLS peer is performing an initial
>       or a renegotiation handshake
>       (1 bit of information)
> 
>   3.) identification of the previous TLS session the TLS peer
>       assumes to be renegotiating

These are not separate. "The ID of the previous state on the connection"
is quite naturally expressed as a zero length renegotiated_connection field.

This is not overloading.

> Since all of this information is carried in the same TLS extension,
> a correct spec and a correct implementation is a little complex.
>
> Since the current document does not make this clear, the decision
> what to send, in particular for backwards interop scenarios,
> is non-obvious -- and obviously some people on this list, which
> I believe to be experienced engineers, seem to have gotten this wrong.

Oh good grief.

> The reason why my proposal is actually much simpler to explain
> in full detail and simpler to implement, is that it uses two
> completely seperate mechanisms to convey (1) and to achieve (3)

I just don't see that as a big deal.

> and it doesn't do (2) at all.
> (Not doing 2 means that MitM attacks
> can not be distinguished from other finished MAC errors im my I-D).

This is not any advantage, in fact it is a disadvantage.

MitM clearly knows who's doing renegotiation and who's not. Aside from
the fact that he's the one orchestrating it all, it's observable from
unencrypted data on the wire.

The only parties who can't determine that there is a MitM attack going
on are the legitimate client and server under attack!

That's bad, they would be better off if they could log or alert about
that sort of thing.

> For interop scenarios with old servers, and as currently used by
> conservative clients and reconnect fallbacks (extension-less ClientHellos,
> SSLv3 ClientHellos and SSLv2 ClientHellos), sending a TLS extension
> in the initial ClientHello would be a change with a significant
> disruptive potential.  Not sending any indiciation of the update
> for TLS renego protection leaves vulnerabilities, therefore MCSV
> is used.
> 
> From the server reply (ServerHello), the client can determine whether
> it is talking to an old or an updated server--the updated Server will
> return a TLS extension RI in ServerHello.
> 
> When the client has established a TLS session with a presumably
> old server,

That was their first mistake. Hope they weren't using TLS for anything
important.

> and that server asks for renegotiation

Now they know their connection is vulnerable and if they supplied a
client cert it may have been forwarded.

> for whatever
> reason (or maybe the client wants renegotiation for client identity
> protection), then TLS extension RI is of *NO* use at all.

Neither is MCSV of any use with an unpatched server. What's your point?

> The only thing that TLS extension RI on the renegotiation ClientHello
> with an old server is interop problems.

Then don't send it if you prefer interop to security. You had the chance
to negotiate it interoperably on the first handshake.

> But not sending anything
> would make the renegotiation vulnerable to a "downgrade attack"
> with an updated server.  Therefore we need to use MCSV for the
> renegotiation with an old server.
>
> MCSV will allow an updated
> server in an MitM scenario to prevent a renegotiation handshake
> from succeeding.
> 
> If the updated server receives the MCSV on an initial handshake,
> it will reply with an empty TLS extension RI, which will allow
> the client to determine whether his renegotiation with an
> presumably old server is proxied into the initial handshake
> of an updated server, so the client MUST abort.

You do raise an interesting case here. One which does seem to support
the idea of sending MCSV on every Client Hello.

There are still multiple ways that its security is broken though, so I'm
hesitant to agree that it's a significant improvement.

> If the updated server receives the MCSV in a renegotiation handshake,
> but no accompanying TLS extension RI with the client_verify data,
> then the server MUST abort the renegotiation handshake because
> this is likely an updated's clients initial handshake that is
> proxied into the renegotiation handshake of an updated server.

This is the standard use of MCSV in every proposal I've seen.

>> Clients receiving a request for renegotiation without having previously
>> negotiated RI can expect that the server is vulnerable to MitM and they
>> may have already been pwned on this connection state.
> 
> The client should not try to rationalize what and what not a server
> might be doing.  The client should look at the handshake reply,
> look at its policy/configuration and either abort the handshake
> or continue.

OK, I'll put it differently.

A vendor, admin, or user who configures a client implementation of TLS
to operate in "compatible mode" is still insecure when connecting to
unpatched systems. They are making a conscious decision that
interoperability with unpatched systems is more important to them
obtaining the security guarantees advertised by SSL/TLS.

We must not judge them for that.

However, neither can we give them security on renegotiation which was
not present on the initial handshake. Suggesting that we do that somehow
could be quite misleading.

There might be room for multiple opinions on this though.

>> Servers receiving a client-initiated renegotiation without having
>> previously negotiated RI can not know that it is the same party they
>> have on the current connection state.
> 
> Similarly, servers should not try to rationalize about clients, but
> instead rely on policy/configuration and implement behaviour that
> is mostly failsafe.
> 
> If an updated server receives a ClientHello on a renegotiation handshake
> that carries an MCSV, but lacks the TLS extension RI containing the
> Client.Finished.verify_data, then that server MUST abort the handshake.

Agreed, I believe that will be in the next version the draft.

>> Starting soon, the absence of RI on a hello is going to be an
>> increasingly strong indicator of "broken and insecure". Eventually, it
>> will just be discarded along with SSLv1 and v2.
> 
> Nope, it will be an MitM on backwards interopble clients, and many
> of those clients will be updated and capable to send MCSV.

I meant "request for RI" in the general sense which also includes MCSV.

>>> If we do not provide provisions for smooth interop for at least the 
>>> transition period, it will hurt _everyone_!
>> If you really want to renegotiate with old, broken, unpatched, and
>> extension-intolerant servers so badly that you're willing to do it
>> insecurely <em>then don't send them the freaking extension</em>!
>>
>> Sending them an MCSV is at best going to be ignored by such a server, no
>> matter what semantics some document attaches to it.
> 
> You're _not_ sending the MCSV for use by that old server,
> you're including it so that this ClientHello can not be diverted/proxied
> into the handshake of an updated server and result in a successful
> handshake if that server is backwards interoperable.

I get what you're saying now. I tend to dismiss that case because it's
already fundamentally broken in multiple ways.

Are there useful "degrees of brokenness" in this kind of case?

It's an interesting philosophical and practical question.

>> Not relevant. What matters is the number of servers that hang in a slow
>> fail condition when sent an extension.
> 
> During my tests with openssl-0.9.8l I noticed that a client sending
> a renegotiation ClientHello to openssl-0.9.8l will hang.  An openssl-0.9.8l
> server seems to _not_ reply to this ClientHello (with a no_renegotiation
> alert), but instead completely ignore the handshake message.  Not good.

Wasn't 0.9.8l the version patched to simply disable client-initiated
renegotiation?

>> Look, SSLv3 is broken.
> 
> SSLv3 isn't broken.

I think I've proven that it is.

> It was just _not_ designed to be extensible.

That's proving to be a big problem now. The best thing would be to just
retire it, except we want to be kind and accommodating to implementors.

> If you look at TLS, it is not that much better.

It is infinitely better in the extensibility department.

> It took them 7 years
> to define extensibility.

They made a spot for it from the beginning.

> They could have simply added a 4-octet bitfield
> for future assignment as the first piece of TLS extensions right into
> the TLSv1.0 spec.  If all you need to convey is a single bit of information,
> then a single bit in a relatively fixed location of a handshake message
> is _so_ much easier to use than the generic TLS extensions carriage.

Yes, I would have probably done it that way (in addition to extensibilty
via TLVs).

In my experience though, no matter how well you document how certain
bits should be initialized and how they should be ignored, some
implementors are just going to doing wrong.

This is not an argument against doing it and documenting it well,
however. It just says you shouldn't have naive expectations about how
smooth it will go when it comes down to it.

>> Sure there is: some clients get a positive benefit from the use of
>> extensions. How to manage the tradeoff between that benefit vs.
>> potential interactions with intolerant servers is something app
>> developers and admins/users currently manage.
> 
> As long as there are extensions-intolerant servers still in use,
> only clients that have a re-connect fallback mechanism can benefit.

Three web browsers are the only clients I'm aware of that implement
fallback reconnect and they would love to dump it. There are probably more.

My impression is that many modern TLS clients get by just fine without
catering to extension-intolerant servers.

> You may ship completely new products without fallbacks, but if
> you are a software vendor, you definitely can not hotfix disruptive
> changes into the installed base unless it is absolutely unavoidable
> and your customers are willing to accept this.
> 
> For secure TLS renegotiation, the use of TLS extensions in a
> disruptive fashion is easily and clearly avoidable.

Apparently, you feel that any use of TLS extensions would be "disruptive"?

> I'm sorry for that.  It is not my intention to confuse.

It's not necessarily you, this material is inherently difficult.

>>> This requirement is about protection from MitM-attacks, it is _NOT_
>>> about successful secure renegotiations (which are not possible when
>>> talking to an old server in backwards interop mode).
>> Sorry, which requirement was that?
> 
> Sending the MCSV on _every_ ClientHello (initial *AND* renegotiations).

OK. There is new wording expected in the next draft. Probably something
like this:

vvvvvvvvvvvvvvvvv
5.  Requirements for Sending and Receiving

TLS clients which support this draft MUST generate either the
"renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
cipher suite with every ClientHello.

TLS servers which support this draft MUST generate the
"renegotiation_info" extension in the ServerHello in response to any
client which offers either "renegotiation_info" or Client Hello
TLS_RENEGO_PROTECTION_REQUEST in the ClientHello.

Note that these requirements still apply even after previous handshakes
of the same the connection or session did not negotiate the use of RI.
Every handshake is to be treated independently in this respect.
^^^^^^^^^^^^^^^

Does this address your point?

> One signaling mechanism (MCSV) to for conveying Client->Server that the
> client is updated is perfectly sufficient.

I have found it tricky to think in terms of "the client is this" or "the
server is that", because the essence of these attacks is that MitM
breaks your assumption about who you are talking to across a renegotiation.

>> Patched clients and servers must validate the content of the (now
>> required to be present and nonempty) RI extension received on subsequent
>> Hellos. The MCSV field on subsequent Client Hellos is now redundant in
>> all cases (both valid and attack).
> 
> No, it isn't.  It enables RI-minimal implemementations of old TLS servers
> to detect proxied handshakes with updated MitMs.

By "RI-minimal" I take you to mean "one which does not implement
renegotiation".

Do you have any examples of these servers which are proven to never
renegotiate?

> You might want to take the position, that it is the client who is
> being fooled, so only the client needs to be aware of the attack,
> but *I* think that would be an incomplete fix. 

No, I have said repeatedly that both the client and server have a
critical interest in the security of the protocol.

That is why I haven't spent much time thinking about scenarios where a
client is willing to operate in compatible mode.

>>> There is even brand new code under active maintenance without support
>>> for TLS extensions.
>> Well, guess what! The protocol now needs to be extended.
> 
> No, it doesn't.  It needs to be fixed!

Your proposal uses an extension whether you admit it or not.

Pretending that it's not only leads to partial implementations of
extension handling which do things like depend on the order and number
of total extensions. Maybe today in a few cases you can show that
variations can't happen.

It's trivial to implement correctly so there is absolutely no gain to
not doing so.

On the contrary, we've all seen the cost of having half-assed protocol
implementations build up over time.

>>> TLS extensions is purely optional, not part of the vulnerability
>>> and does not need to be part of the solution.
>> No one came up with any other less-impactful way to do the required S->C
>> signaling, and not for lack of trying.
> 
> Plain Wrong.  My proposal works without TLS extensions, that is

Baloney.

> clearly explained.  It just happens to use a S->C signaling scheme
> that looks like TLS extensions to TLS-extensions aware implementations
> and can be parsed with TLS extensions parsers, for those who prefer
> to do it that way.

That must be why my extension parsing code parses the example out of
your document just fine.

Tell me, how can I fix my extension code so that it correctly identifies
your non-extension as not an extension?

By that logic, "renegotiation_info" described in
draft-ietf-tls-renegotiation isn't an extension either.

Or is it just "extra bytes that look like TLS extensions" on Server
Hello that aren't extensions?

> But my draft explains clearly how to do it without TLS extensions,
> and the OpenSSL patch I posted contains an extension-less implementation
> of the signaling -- and the Client side of the extension-less code
> is actually used for server_version==SSL3_VERSION.

No, what you have is a half-baked minimally-compatible extension
mechanism in denial.

It only works because of the long chain of reasoning required to prove
that it will never be asked to share the protocol space with real
extensions.

It will break as soon as someone else does the same thing, thinking they
can make assumptions about number and ordering on extensions appearing
on certain Hello messages. If your design can't tolerate the possibility
of someone else reasoning the exact same way, it's not very good is it?

Protocol designers and implementers have been through this a countless
number of times.

Just admit you're extending the Hello message and use the standard and
interoperable mechanism like everyone else. The only global-scope
coordination it requires for correctness is handled through the IANA and
they seem to do a decent job of it.

> Look at the last two paragraphs of Section 4.4 which describe
> how extension-less clients and extension-less servers can implement
> this with <10 LoC each.  And my openssl-patch contains exactly
> that code.

It is exactly this kind of foolish false economy that has put SSL/TLS
interoperability in the state it is in today.

>> By the way, do you of any TLS implementations that do not "implement
>> renegotiation"?
> 
> There are two possibilities with the same effect:
> Do not implement it in the fashion of "have never contained it"
> and do not implement it in the fashion that it is hardwired to disabled.
> 
> openssl-0.9.8l is one of the latter.

Yes, it's an emergency patch that is not suitable for everyone.

> What you currently see is a lot of customers asking for patches
> that reliably disable renegotiation for the servers, because most
> servers do _not_ need it.
> 
> And once you've come to the conclusion that you don't really need
> it, there is no use to implement full secure TLS renegitiation.

Again, do you know of any modern, maintained TLS implementations that
have decided that they do not need to ever support renegotiation?

> RI-minimal  would be just fine, and much easier to test and ship
> as a hotfix for an old installed base.

>> If you write the spec that way, the world is married to the MCSV
>> forever. And we waste three bytes on every handshake.
> 
> Cipher suite values in SSLv3/TLS are two bytes,

Well it changed a while back, would be interesting to know why.

> and if you're really
> concerned about that, you should go for draft-mrex-tls-secure-renegotiation,
> because it will need even less bytes on every handshake, in particular
> on the renegotiation handshakes.

No.

> If TLS extension RI specifies to NOT send an empty TLS extension RI
> on the initial handshake EVER, only MCSV, and additionally include
> MCSV on every renegotiation handshake, then you save 3-5 bytes
> on every initial handshake and pay 2 bytes extra on every
> renegotiation.  That means for >95% of the usage scenarios you
> will save.

It's not worth one bit of extra complexity to me.

To me, the MCSV hack and your proposed subset of the current extension
mechanism are extra complexity.

> I can imagine that it takes quite some time to implement an MitM attack
> on TLS renegotiation.
> 
> I'm sorry for just thinking about it for an hour, checking the TLS spec
> for flaws in my line of thought for 20 minutes and then posting it
> publicly to tls@ietf.org that TLS renegotiation is susceptible
> to MitM attacks.

Well I did the same thing initially, but my process was to bug it
internally. Not being an expert, I felt I had to prove it thoroughly
before I went around making (what I saw as) extraordinary claims.

>>> Have you worked for a software company with 5000+ software developers
>>>  during the last three years?
>> No, would you like me to write the 80 LoC for you?.
> 
> I don't have problems with writing that code.  But you certainly
> could help me with the weeks of paperwork and automated test-cases
> necessary to get official permission to ship that change into an
> installed base in maintenance mode.

I suspect that your paperwork increases sub-linearly with LoC.

> Some 10 LoC changes require 300+ LoC test tools.  If you look at
> my openssl patch, it does not create a lot of new code pathes
> that can only be reached with test tools.  98% of that new
> code is fully covered during regular use/interop, and works
> in a failsafe fashion -- i.e. if it didn't work as designed, it
> would result in interop problems.

That's all good.

It would certainly be simpler to just break interop with SSLv3 and
broken TLSv1 servers. That's a form of fail-safe.

>> So why would a legitimate server renegotiate a connection and switch
>> certificates in a way that could surprise a client and be manipulated
>> for evil? The renegotiation fix proves it's the same server with no
>> MitM.
> 
> It _only_ proves there is no MitM acting without consent of that
> server.

There's no such thing as an attack with the consent of the server. The
server can do anything he wants without involving the complexity of a
3rd party MitM.

> If that server changes his certificate during renegotiation,
> it is DEFINITELY not the same server as before.

If that were the case, you would be unable to say "server changes his
certificate".

"Server" is an increasingly nebulous term, what with shared IP load
balancing, "cloud", "ssl offload", and all.

Here's what one relevant RFC says it is:
> The server is the application entity that responds to requests for
>       connections from clients.  See also under client.

I wouldn't go around saying it "DEFINITELY" is this or that.

> Depending on what
> the new cert looks like, the client may accept this change, but
> the assumption that a client must not care is flawed, and can
> by itself become a security problem for some situations.
> 
> If you're doing security-related stuff, it is extremely important
> that you are staying clean at the abstract level.  Some of the
> risks that one creates by sloppiness at the abstract level may
> lead to mostly theoretical vulnerabilities (like adding arbitrary
> data to the handshake message hash instead of handshake messages),
> and sometimes it can create very practical risks (like ignoring
> identity changes).

I'm saying you have some unsubstantiated assumptions and "unclean
abstractions".

> There are some apps on top of TLS that "tie" certs to hostnames, but
> as previously discussed, that is entirely an apps issue, and the
> TLS implementation can _NOT_ force re-authentication on the application
> caller!

Until the SNI extension can be made mandatory, in practice a TLS server
can't present different server certs from the same IP and port. That's
all I was saying.

> In the IETF security area we try to avoid this kind of approach:
> worrying about vulnerabilities only when exploits have been published.

I'm saying it's probably not a protocol vulnerability if it was a
documented feature of the protocol.

There need to be seriously good reasons before removing functionality in
a protocol spec.

That a few knowledgeable people have found it surprising on first glance
is relevant, but not persuasive.

Finding an actual system that misinterpreted the spec and plausibly had
a vulnerability would be even more useful.

Finding many systems which were vulnerable to having made the same
mistake interpreting the spec would make it worth considering removing
or restricting the protocol feature.

But so far nobody has described even a hypothetical (but plausible) example.

> We want to move away from MD5 in online authentication even though
> nobody has demonstrated real-time second preimage attacks against MD5 yet.

You'd better be looking to move away from SHA-1 as well.

>>> A client that has not been previously
>>> authenticated performs a client cert authentication.  That is a
>>> highlander operation.
>> I'm not familiar with that term. Searching for it results in some NSA
>> wiretapping gone wrong.
>> http://www.wired.com/threatlevel/2008/10/kinne/
> 
> You mean the term "highlander"?
> 
> Look here: http://en.wikipedia.org/wiki/Highlander_%28film%29

OK, I remember hearing about that movie/TV show. I didn't watch it.

> "in the end, there can be only one."

Only in your preconceptions. It's not in any TLS protocol spec I've seen.

> To have more than one client cert listed for an authenticated TLS session
> would be a pretty dumb idea.

Just because you can't imagine how it might be useful doesn't make it a
dumb idea.

> There are platforms that offer such mechanisms more like a feature
> of the "Trusted Computing Base", which allows to pass of ACL checks
> in a Posix-ACL style to the underlying OS (ImpersonateSecurityContext()).
> 
> These functions would likely have difficulties dealing with a set-of
> instead of a single client identity, and they would be faced with the
> problem that Access Control and auditing/audit logs can deal only
> with a single Access Token (identity).

So what?

>>> The secure renegotiation is provided by "authenticating" the verify
>>> data from the previous finished messages.
>> I wouldn't describe it that way. It's just checking that two values are
>> in agreement. These values were authenticated by the previous handshake
>> process.
> 
> That is what is supposed to happen.  I know that TLS extension RI
> uses an unconventional way to perform this authentication -- it

Which is why I wouldn't describe it as authentication.

> exchanges the data in an integrity-protected fashion and needs to
> memcmp() the contents.  Which is why TLS extension RI is not failSAFE.

Where fail = crypto code is buggy.

It's probably not what any of us would designed if we could do it from a
clean sheet, but we don't have that option. On balance, I think it's an
effective fix and is the most deployable on an urgent basis.

- Marsh