Re: [TLS] Request for review: Next Protocol Negotiation Extension

["Brian Smith" <[e-mail]>]

Marsh Ray wrote:
> On 08/17/2010 04:00 PM, Brian Smith wrote:
> > Following these guidelines would subject the client and server to very
> > simple and effective DoS attacks, which are already so common that we
> > accept them as part of the status quo. Relying on these guidelines
> > would subject the client and server to cross-protocol attacks unless
> > everybody else in the world follows them.
> 
> I don't get it, it's basic stuff. What part of those recommendations
"subject the
> client and server to simple and effective DoS attacks" in a way that they
weren't
> already?

TLS is used to protect the end entities from MitM's. If a MitM is filtering
the endpoints' traffic based on the port number or any other criteria, then
that is a denial of service. Whether the end entities are the good guys or
the MitM is the good guy, or whether the end entities are abusing the MitM's
network isn't relevant. 

> Port 443 isn't magic. It's just as DoS-able as others, if not more so.

> Never pick a fight with the guy who's holding your power cord.
> He wins every time.

It isn't practical to disable port 443 for most ISPs for a variety of
business and political reasons.

> By definition, it cannot be an attack if it's by the equipment's rightful
owner. 

The rights of the participants are outside the scope of the discussion. TLS
protects the end entities from everybody else, even if the end entities are
actively, criminally, attacking the network they are using or worse, and
even if the network administrator is the cutest puppy in the world.

> > For example, currently it isn't
> > possible to build a system that uses SMTP and IMAP but which hides the
> > user's action (sending or
> > receiving) from a MitM; this extension (or a similar one) would enable
> > implementations to make such traffic analysis significantly more
> > difficult and hopefully prohibitively expensive, especially if used in
> > conjunction with  a careful padding scheme.
> 
> This is expected to make it hard for TA to distingush between HTTP, SMTP,
and
> IMAP? Really?

Yes, I think it is easy to make it prohibitively expensive for a MitM to use
TA to recognize what application protocol is in use with actionable
certainty for many use cases.

> In this simple example we already have the protocol "HTTP" stated
explicitly or
> associated by convention ten times!
> 
> One might think this would be good enough to indicate what the intended
> protocol is, but as you say there are apparently people with
unauthenticated
> SMTP and IMAP servers listening on port 443.
> 
> My question is this: What's going to be different this time?
> 
> If we really need another protocol identifier because the ones we have
don't
> hold up under attack, let's do it right this time! It needs to be treated
just as
> security-critical as checking the name on a server certificate.

Yes, This is definitely something that needs work in the NPN draft.

> How is client cert auth to be performed? Is it a problem that it's not
configurable
> per-protocol?

I would say the server shouldn't ask for a client certificate until after
the first handshake, for a variety of reasons, some of which aren't specific
to this extension.

> Insecure (without RFC 5746) renegotiation can now easily be a
cross-protocol
> attack. Should this spec forbid it?

I think any implementation can and should require that if the other end
implements this extension, then the other end also supports secure
renegotiation--simply because it is stupid to add support for this extension
but ignore secure renegotiation.

> Could it be made an option to get the server's list of protocols while
under a
> basic encrypted session, providing that confidentiality like for client
certificates?

The TLS WG should work on a general way of securing the information
transmitted in the handshake, by doing key exchange first and transmitting
everything else afterwards. The results presumably would have the effect you
are looking for.
 
> Would it be advantageous for the client-selected protocol to be allowed to
> influence the cert presented by the server? It's not unusual to need
different
> certs for different protocols after all. Can this be accomplished through
> renegotiation? Wouldn't that leak information about what protocol was
> chosen?

If you have different certs for different protocols, then that leaks
information about the protocol, unless you transmit the protocol-specific
certs during a renegotiation and everything is worked out perfectly to
prevent traffic analysis. More realistically, the service provider probably
needs to make a choice between using this extension and per-protocol
certificates, to avoid the latency that a double handshake would require,
and to avoid traffic analysis if nondisclosure of the protocol in use is a
consideration.

> My concern is that at the end of the day we end up with no great victory
in
> transport neutrality. Instead we get might just get another layer of
redundant
> indirection, more protocol complexity, and worst of all, TLS-intercepting
MitM
> proxies sprouting all over the net like dandelions.

If nothing else, this TLS with this extension would reduce protocol
complexity for all other protocols that it is used with because it would
provide a standard mechanism for preventing cross-protocol attacks.

> > Many service
> > providers do not care about their users' privacy enough to spend any
> > extra money to protect it. If this extension becomes the standard way
> > to enable interoperable WebSockets support, then even service
> > providers that are apathetic about MitM protection might having a
compelling
> reason to use TLS.
> 
> But if it requires a software (if not hardware) upgrade to support the
extension,
> wouldn't that just encourage deployments to use plain HTTP?

I think soon we'll see HTTP/Websockets/SPDY over TLS outperform plain
unprotected HTTP for less cost for a variety of reasons in a lot of common
applications, and the benefits will outweigh the costs, even from a purely
financial standpoint.

> As appealing as the idea sounds to me, "encouraging" a transition before
people
> would choose it on their own is likely to lead to a lot more self-signed
certs out
> on the web.

I don't think it is valid to argue that a change to TLS makes it useful to
more people, but those people might not understand the security issues well
enough to use it safely, so the changes must not be made. It's better to
find ways of improving the safety and usability of TLS when it is being
managed by users with little understanding of proper security procedures or
who have little motivation to follow proper security procedures. That's a
topic for another thread.

Regards,
Brian