Marsh Ray wrote:
> 
> > 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.

Primarily at first look.  It is a characteristic of the TLS handshake
that tampering with the handshake will result in a Finished MAC failure
and maybe the optional CertificateVerify verification failure.

It would be helpful when those who are vulnerable would log attacks,
but unfortunately, they don't (can't).  For those who are _not_ vulnerable,
that information is no longer this much different from other tampering
with the TLS handshake messages.

In recent years several previously distinct error situations were
re-specified to make the finished MAC fail rather to point to an
implementiation bug with a distinct Alert message (wrong protocol
version in rsa premaster secret is one of those).


> 
> >> 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.

Only if one of them (or both) allow old _renegotiation_.  Most "interesting"
scenarios that users/consumers worry about currently require the server
to be the one offering old renegotiation.


>
> >> 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 is a _possible_ scenario.  My proposal fixes all possible scenarios,
and does _NOT_ need to iterate them.  If you have to iterate through
scenarios, then your solution is more complex than necessary.

> 
> > 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?

I'm not sure.  To me it looks like it disables renegotiation in general.
Although it tests for a flag value in the session flags, there is
only a control-function to retrieve that flags value, but the function
to set these flags seems to be missing.

The problem is that openssl-0.9.8l fails to return an SSL alert.
So the client who has sent a ClientHello is waiting for a ServerHello,
and the server also seems to get stuck (s_server and s_client).


> 
> > 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.

SSLv3 was the enabling technology for TLS.

Sounds like murdering your parents silently and collecting their pension.

The ethical behaviour is to wait until it dies of age all by itself.


> 
> > 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.

Nope, that beginning was in November 1996.  TLS WG decided to
leave forward extensibility an unused and untested protocol
feature for several years.  There would not be any broken TLSv1.0
servers if that protocol feature had been appropriately tested.


> 
> 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.

Documenting it is insufficient.  The three most important things
that you need is  Testing, Testing and Testing.

You need that to check a spec for consistency, and you need that
to check implementations for interoperability and compliance.  And writing
good test tools can be more work than implementing the technology itself.


> 
> > 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.

Many modern TLS clients get by just fine without sending TLS extensions.

But we're not talking about what the fix means for "modern" clients.

We're talking about what this fix means for "old" clients and servers,
which outnumber the "modern" clients by a factor of at least 50x (probably
500x if you count all the individual codelines under maintenance).


> 
> > 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"?

Yup, definitely.  For a large amount of the installed base it
will would be a backwards incompatible change with *known* interop
problems to suddenly have clients send TLS extensions.

And a lot of software vendors can not afford to put a change with
such a disruptive potential into a hotfix for the installed base.


> 
> 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?

No, unfortunately not.


Conforming TLS clients MUST include the TLS_RENEGO_PROTECTION_REQUEST
on _every_ ClientHello they send.  TLS clients SHOULD NOT include
an empty TLS extension RI in a ClientHello.  TLS clients MUST NOT send
an renegotiation_info extension containing Client.Finished.verify_data
in a renegotiation ClientHello in backwards interoperability situations
when (a) old renegotiation is permitted and (b) no TLS extensions had
been sent in the ClientHello that established the enclosing TLS session.



> 
> > 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.

I'm sorry, I can not follow at the moment.
The MitM attack has no influence on whether you are client or server.


> >> 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?

Proven to not need it?  All of the servers that we shipped so far.
Proven to not accidentally provide it.  Less than the previous.


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

I admit that what my proposal uses is fully compatible with
TLS extensions.  You may remeber that I do care for all existing
usage scenarios.  That includes scenarios that use TLS extensions today.
Therefore I insisted when adding anything into ServerHello behind
compression_method that it be gentle to real TLS extensions that
may need to get stuffed there.

For simplicity, I even refer to this signal as a TLS extension
in my document.  It is just sufficiently simple that it not
more complicated to implement than re-purposing a bit from server_version
or compression_method -- for those old or constrained implementations
that do not have any TLS extensions code.


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


I'm sorry that I'm more worried about hundreds of old implementations
that _only_ need to get fixed, by maintenance persons who are sometimes
just vaguely familiar with the code, rather than the two dozen
modern full-fledged TLS implementations where the maintainers are
in best training, constantly experimenting with the newest features
and no installed base to worry about.


My approach is conservative and pragmatic.


> 
> > 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?

My design can tolerate that perfectly well.  If you need more than
one extension to be carried, you'll have to implement TLS extensions,
that is obvious.

If that extra data in those other situations is not compatible
with TLS extensions, then that other data is a half-assed protocol
extension, and it wouldn't fly with TLS extension RI either.

I never claimed that my approach was perfect.  I only claimed
it was less complex than TLS extension RI, less code to implement,
less testing necessary and highly interoperable with installed base.


> 
> 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.

I admit that I'm extending ServerHello with a TLS extension for
everyone that implements TLS extensions, that should be rather obvious
from "4.4 New protocol elements" and "6. IANA considerations".

For extension-less implementations, it's a simple 6-octet binary
appendix to ServerHello that is used for Server->Client signaling
and trivial to implement, this is what the last two paragraphs
of section "4.4 New protocol elements" describe.


What it is therefore depends on your point of view.

UTF8 can be interpreted as Unicode for Unicode-aware applications,
can be interpreted as US-ASCII for applications that only store
US-ASCII characters in there, and can be treated like traditional
0-terminated strings by string-functions of ANSI/ISO-C (c89).


> 
> > 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.


Nope.  It is the lack of testing!  If those guys who developed TLSv1.0
had spent their time on developing test suites and getting the installed
base fixed while that software was still under maintance, or had performed
a security review on the design of the renegotiation, then we would not
be in the current situation, having to patch 14 years back into the past.


Many protocols in the IETF have seen a huge feature creep over the
past 10 years, meaning that the recycled the IETF process at
"proposed" with several revisions instead of fixing the defects
in the specs, getting the implmenentations to interoperate on all
specified protocol features and advancing the protocol to
draft standard.  TLS is definitely one of those.


> 
> > 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.

Having MCSV adds complexity.  Mandating its use actually reduces
complexity--you don't need a conditional for adding it -- that
obviates an extra test case.


> 
> > 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.

The paperwork is linear with the number of additional test cases
for each new code path.  This is why I prefer to _not_ add new
code pathes, but instead only modify existing code pathes
-- in which case the existing test cases cover the changed
functionality already.

How may test cases do you need to verify the implementation of
a secure hash functions?   Very few.  A few test vectors and
some invalid input parameter calls are sufficient.  It is
extremely unlikely to get a correct results for a certain
amount of test vectors by "accident".
A kind of implicit fail-safe design.


> 
> > 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.

I don't have a problem if you do _not_ add backwards interop into
your implementation.  I will leave that to "market pressure".

However I do have a problem if you insist on a spec that makes
backwards interop difficult for _me_, because I'm paid to provide
that interoperability for the installed base.


> 
> > 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.

I looked at the SNI spec, and that thing is a big mess!  It appears
to be an completely out-of-sync proposal.

The first thing that should have been done is define a standard
how to perform server authentication.  One could have used rfc-2818
(HTTP over TLS, informational), which itself refers to PKIX
X.509 subjectAltName dNSName and iPAddress.

dNSName is an IA5String
iPAddress is an OctetString, but there are canonical string
representations in some specs.

The hostname in SNI is defined as UTF8String which looks pretty weird!

The client should send exactly that canonical hostname that it
will use to verify the ServerCertificate.  In order to implement
SNI correctly, a TLS implementation will _now_ need to implement
transforms of UTF8Hostnames into the thing that you find in
Server Certificates -- which could have been completely avoided,
since the client MUST ALSO implement this, and could have been
passing the _result_ of this operation to the server instead!

There's simple rule that says: If you have one clock, you
are pretty confident to know which time it is.  If you have
two clocks, you are unsure.  The SNI design looks like poor
engineering to me.


And explicitly prohibiting literal iPAddresses in rfc3546
without _ANY_ kind of justification while their use in
rfc2818 is explicitly permitted for HTTP over TLS seems
also a little strange/inconclusive.


> > In the IETF security area we try to avoid this kind of approach:
> > worrying about vulnerabilities only when exploits have been published.
> > 
> > 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.

We can not drop SHA-1 that easily.  First we must upgrade the
installed base to support something better than SHA-1, then we
must migrate the users to use that better-than-SHA-1 hash,
and then we can think about disabling SHA-1 support.


> >>> A client that has not been previously authenticated performs a
> >>> client cert authentication.  That is a highlander operation.
> > 
> > You mean the term "highlander"?
> > 
> > Look here: http://en.wikipedia.org/wiki/Highlander_%28film%29
> > 
> > "in the end, there can be only one."
> 
> Only in your preconceptions. It's not in any TLS protocol spec I've seen.

On the contrary, it is in all of the specs.  Each peer in
the TLS handshake can send at most one Certificate handshake message
within one handshake.

This is probably why none of the implementations I know uses an
aggregate set of certificates of TLS peers.

And as we all know by now, TLS renegotiation results in an entirely
independent session.  :-/   So you can not claim that TLS renegotiation
supports a change in the identity.  TLS renegotiation has been a
completely new and independent handshake all the time.


-Martin