Re: [TLS] TLS, PKI,

[Marsh Ray <[e-mail]>]

On 07/15/2010 08:52 PM, Kyle Hamilton wrote:
>
> TLS has several modes which are unsupported by the members of this list:
>
> 1) A supported (by the standard) mode of "unauthenticated TLS" (neither
> the server nor the client offer or demand certificates).

I for one fully support the use of anon-anon TLS, as long as its 
limitations are clearly understood by those using it.

> 2) Mutual Authentication -- it's supported by this group in the
> protocol, *except* that very few clients who actually have certificates
> typically don't have the marketing acumen to show just why they might be
> useful.

I fully support the use of client certs. I think they're great and use 
them in several production contexts.

> 3) The classic "server authenticates, client doesn't" issue -- which
> relates to the massive "secure renegotiation" effort which could have
> been avoided had the TLS group coordinated with the PKIX group to figure
> out how to increase the use of initial-mutual-authentication -- and

Renegotiation needed to be saved, not abandoned. Some important non-web 
systems depended on it, like Tor.

> which would, at the least, require the PKIX group to realize that the
> adoption rate for publicly-useful (i.e., issued by publicly-recognized
> CAs) identity certificates is so low that their specification for them
> just happens to be useless for the Internet PKI, instead being useful
> only for the Corporate PKI.

Maybe I don't have a very good imagination, but I can't think of a lot 
of places on the net I'd really want to strongly authenticate to with my 
photo ID and US passport class of identity. When I occasionally buy 
something online the merchant and card network are more interested in 
authenticating the card than cross referencing my own identity. And for 
everything else I prefer casual, weakly authenticated accounts with 
throwaway usernames.

> 4) There is a mode which is starkly, abjectly forbidden by the TLS
> specification (if the 'server' does not authenticate to the 'client',
> then any request by the 'server' for the 'client's certificate is closed
> with an unexpected_message alert.)

It does seem rather asymmetric. For the current protocol design I 
suspect it wouldn't be secure for the client to validate with his 
certificate to an anonymous party, he could be subject to credentials 
forwarding attacks. Maybe a protocol extension could support it, but 
it'd take a lot of work to prove it's secure and there doesn't seem to 
be a huge demand for it.

> I find it telling that the last time
> I brought this issue up, someone had the gall to suggest "well, in your
> application, just tell the connecting process that it's the server."  I
> shouldn't have to, and the fact that a programmer must initiate a
> workaround means that it's a bug in the protocol.  (Among other things,
> Nelson Bolyard said, when I mentioned implementing it, "That wouldn't be
> TLS, that'd be "Kyle Hamilton's TLS-like protocol".)

Here's what the spec says:
>    client
>        The application entity that initiates a TLS connection to a
>        server. This may or may not imply that the client initiated the
>        underlying transport connection. The primary operational
>        difference between the server and client is that the server is
>        generally authenticated, while the client is only optionally
>        authenticated.
>    server
>        The server is the application entity that responds to requests
>        for connections from clients. See also under client.

I don't see anything wrong with it.

The true abomination is optional STARTTLS. Anybody catch my blog post 
about just how eager Mozilla Thunderbird is to give my plaintext 
password to an anonymous TCP server?
http://extendedsubset.com/?p=22

> You can place the blame for the failures of PKIX on the PKIX Working
> Group -- but you can't shift the blame for fact that you're forcing
> implementors to essentially create "the TLS-based protocol that has the
> property that the connector sends its certificate first" if they want to
> have their software use the same semantics that ipsec has had since its
> inception.

IMHO, one can't implement something truly interesting without pushing 
the boundaries a little bit and putting up with the inevitable criticism 
from those who are (perhaps legitimately) concerned that you're on 
untested ground. But really that's nothing compared to the criticism 
you'll get if you bend the rules and the result turns out to suck.

> Robert, you're right -- today's browsers no longer raise pop-up
> windows.  Instead, they take you to a scary page that gives options to
> either "get me out of here" or "pop up the scarier window".  This is a
> step *backwards* in usability.

I don't want usability for the broken cases.

>  From my NPOV over the last 5 years that I have archives I can reach only
> a trio of conclusions: TLS WG has failed.  PKIX WG has failed. IPsec WG
> has failed.  And the reason for the failures has nothing to do with the
> quality of the work put out -- TLS WG, in particular, has done amazing
> things with what it's been given -- but because a system cannot be put
> together without a holistic, full-system integration of security,
> according to the policies which must be implemented (and which are *NOT*
> the purview of the protocol working group to pretend to know about ahead
> of time).  These three WGs have failed to work together, and have failed
> to come up with a useful, usable, and interoperable infrastructure that
> grants maximum choice to the actual end-administration implementor.
> (Preferably with preconfigured "best practices" options, for different
> environments.)

I'll buy that. I've been studying TLS pretty intensively over the last 
year and I feel like I've learned next to nothing about PKIX and IPsec.

> There's few, if any, "Best Practices" that have come out of any of these
> three groups -- all that have come out have been either Informational or
> Standards-Track RFCs.  The last time I saw anything informational come
> out of the PKIX group, it was in order to put out a framework for
> guiding the creation and auditability of Certification Practice
> Statements and Certificate Policies -- which, by the way, doesn't
> provide ANY guidance to any sysadmin.

Right. My sense is that the mission of these WGs is to ensure that the 
wire protocols perform as advertised and interoperate well and evolve in 
an orderly fashion. That's enough of a challenge that I don't see 
anything wrong with stopping there.

> I'll note, just for reference, and only because I did the count:
>
> X.509:08/2005 is 174 pages long, including 39 pages of text that is not
> characterized as being contained within any RFC ('non-normative annexes'
> and the roman-numeral pages at the beginning, a blank page, and the
> title page).  That's 135 pages of actual normative content.
>
> RFC 5280, on the other hand, is 152 pages.  This means... THE NORMATIVE
> INTERNET PROFILE FOR X.509 IS LARGER THAN NORMATIVE X.509 ITSELF.  This
> is as close to 'insane' as I can find myself thinking about standards
> bodies (in this case, the PKIX WG).

I bought these thick books about the implementation of IPv6, 2000 pages 
down to the source code and everything. Can you guess how many pages 
were about security? About 80 (the last chapter of the last book).

> Please.  Find a way to interact more with the other working groups that
> also use PKIX.  Find a way to create a less-haphazard security
> infrastructure.

The public, commercial PKI sucks. Increasingly, influential people in 
the data security field believe it's time for this to change, and it 
will, once it really sinks in to people just how screwed they are.

My advice to the current CA industry is to lead or follow. It will not 
occur to anyone to ask them to get out of the way once they drift past 
the event horizon of the black hole of irrelevance.

> Find a way to let either end "elect" to provide its
> certificate first, regardless of what role (listener/server or
> connector/client) it thinks it is.  And find a way to let either end
> "elect" to request a certificate first.

That's incredibly difficult to do well in a protocol because it's 
inherently vulnerable to downgrade attack. Encryption is useless without 
authentication (in the presence of an active attacker). When the 
authenticated parameters are negotiated, the attacker gets to pick the 
weakest authentication methods compatible with each endpoint.

For example, what stops bad guy from telling the server he doesn't want 
a certificate - and telling the client the same thing in the other 
direction? There are solutions to this, but they generally involve more 
round trips, trusted 3rd parties, and/or additional work on the part of 
the appliction code. Considering the success rate apps have in 
implementing the current server cert checking properly it may be a 
little optimistic that they would get a negotiated authentication scheme 
secured very often.

> VNC paved the way for a new connection paradigm: let the server contact
> the client, and then the client acts as a client and the server acts as
> a server.  This was typically useful for situations where there's no
> outbound firewall but there is an inbound firewall.

Yeah that's handy. I also tunnel stuff around with SSH a lot.

> So why can't we set something up like that?  This would create something
> like the "push server" concept (remember 1995, how that was going to be
> the next big thing?  It got supplanted by RSS, then ATOM), but we also
> have teredo IP NAT traversal nowadays so we can have peers behind
> firewalls talking with each other.

By and large, people don't want their systems exchanging connections 
freely with external systems. That's how the internet was originally 
designed, but that design has been flatly rejected. There are likely far 
more home and office routers doing NAT than straight internet routers. 
AFAICT, only SMTP and the core routing protocols still work that way. IP 
source routing - gone. FTP - passive mode only. Games and IM go through 
backend servers and P2P file sharing runs in degraded mode without 
special exceptions.

If you want to make a new protocol today, the key is flexibility. The 
endpoints need to appear to the transport layer as client or server as 
necessary. Even big guys like Microsoft have largely given up on making 
anything new that doesn't tunnel over HTTPS on TCP port 443.

But even outgoing connections are increasingly filtered. Deep packet 
inspection gear is even MitMing TLS connections by forcing installation 
of a trusted root cert on every client. It's probably only a matter of 
time before some vendor buys themselves a trusted root or intermediate 
signing key, if that hasn't happened already.

- Marsh