Re: [TLS] TLS, PKI,

[Kyle Hamilton <[e-mail]>]

 On 7/13/10 6:41 PM, Robert Relyea wrote:
> On 07/13/2010 05:06 PM, Martin Rex wrote:
>> Robert Relyea wrote:
>>   
>>> It seems these are complaining about yesterday's UI. Most browsers no
>>> longer use pop-up menus. You have to be quite aggressive to get through
>>> the current screens.
>>>
>>> The real problem, of course, is those sites that don't have valid certs.
>>> Continuing to ratched down the ability to get to those sites is good for
>>> the internet as a whole. Sites with invalid certs are just as dangerous
>>> for the internet as MITM sites.
>>>     
>> If SSHv1 would have required CA-signed X.509 certs in its initial
>> shipment, it would have taken MUCH longer to become popular, if at all.
>>   
> Compared to SSL, SSH is still not popular, which sort of negates your point.
>
> SSL is designed to allow you to make secure connections for the masses.
>> -Martin
>>   

Note that I'm writing this as a reply to Martin, but not directly *to*
Martin.  This is a major issue that I'm seeing, going through the archives.

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

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.

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.

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

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.

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

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

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.

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.

(Granted, I'd rather teredo wasn't necessary, and I'd prefer that
everyone move to IPv6.  But still, we need to convince the US ISPs that
IPv6 is actually necessary.)

-Kyle H