Subject: Re: [pkix] Privacy of TLS client certificates

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 22 Mar 2011 19:48:21 -0700 (Pacific Daylight Time)

On Tue, Mar 22, 2011 at 6:29 PM, Matt McCutchen <[email-masked]> wrote:
> Without commenting on the proposal as a whole...
>
> On Tue, 2011-03-22 at 18:17 -0700, Kyle Hamilton wrote:
>> On Tue, Mar 22, 2011 at 2:16 PM, Anders Rundgren <[email-masked]> wrote:
>> > As I understand IIS can create an encrypted channel
>> > before doing client auth.  If IIS can do that any
>> > server should be able to do it as well.
>>
>> This is true, and it's called "Ephemeral Diffie-Hellman", or DHE.
>
> That is not correct.  Regardless of the cipher suite being negotiated,
> the client certificate is transmitted as a Certificate message,
> encrypted only by the current TLS cipher suite, which in the case of an
> initial handshake is TLS_NULL_WITH_NULL_NULL.  The trick to keep the
> client certificate private is for the server to complete one handshake
> without requesting a client certificate and then immediately
> renegotiate, requesting the client certificate.  See RFC 4680 section 4.

I appreciate the correction, thank you.  (I've moved away from TLS for most of my development, because it simply does not meet my needs.  I'm doing message-based processing now.)

This doesn't mean that TLS isn't an appropriate use-case -- if anything, it simply reinforces that there is a problem which must be addressed.

I propose to resolve that problem completely within the legitimate purview of PKIX, without requiring any changes to its client protocols (such as TLS's "OCSP Stapling").

>> Currently, browsers have no feedback mechanism describing whether
>> their credentials will be transmitted in clear-text or under cover,
>> which prevents the client from taking appropriate security precautions
>> and making appropriate security choices.
>
> Indeed.  Want to file a bug against Mozilla?

I see you've done so.  I believe, though, that it is missing the point.  There should be no need for the user at the endpoint -- the consumer -- to have to worry about it.  The consumer's software must protect his privacy regardless of what the server says, does, or offers.  (it's much like the current plethora of privacy policies on all of the commercial websites that people put their personal information on -- the server mandates that it will do things one way, and the only option for the consumer is to choose to not consume the service.)

There are many reasons why I believe that PKIX is the appropriate place to resolve these issues.  There are many reasons why I believe that passing encrypted credentials around is a good thing.  There are many reasons why I believe that PKIX is the only body which has a chance of preventing Facebook from owning my identity.

'Identity' can be seen as the collection of characteristics used to assign reputation to an entity within any particular context.  This includes state identity to match against credit reports, for example.  This means that identity is not necessary to oneself, but only to others.  Since 'others' are independent entities which make their own decisions based on what they know about a given entity, they usually also pass reputation information about that entity to other others.  That reputation has value both to the identified entity (if it's good) and to the context within which the entity is identified (if it's bad -- for example, a bank relying on a credit report), and must be protected.

Any information which relates to an identified entity must be considered "personal" and is thus confidential.  Currently, the only way that the entity can retain that privilege in the US (EU privacy directives are better here) is if the entity asserts copyright protection over that information.  The double-encryption in the proposed protocol has all of the necessary characteristics to permit this to be done with actionable consequences if it's violated.

There are many reasons why I believe that this is semantically correct.  The consumer is authoritative for how he presents himself.  He's responsible for having any given identity (including for example "XBox Live gamertag" or "member of this band", as well as "state identity" and "fiscal identity").  However, because the determination of characteristics and reputation are always external, the consumer is not authoritative for any given identity.  (Con men work on the violation of this principle.)  This means that the user is an authority, and must be able to exhibit his signature to prove it -- which means that the "single Subject model", where the user has no capacity to sign assertions, is fatally flawed.

In addition, with such things as SCEP, PKIX-WG is facing challenges where it created something and now must support it.  TLS-WG has the same issue, which is why they had to retroactively patch every version of TLS back to 1.0 with the "secure renegotiation indication" extension.  With this proposed protocol, that renegotiation indicator is almost obviated (as both ends of the link would be authenticated in almost every transaction).  This can reduce the number of non-IETF third parties upon whom the IETF imposes mandates to change their Security-area protocol implementations.

With this proposed protocol, the underlying reasons that SCEP exists in the first place can be asserted by the consumer user.  Since current Identity CAs don't offer automatic certificate enrollment, this means that they will have to write code for what they're trying to accomplish (once this becomes ubiquitous enough) -- which means that they're working from essentially a blank slate when they go to add support for automated enrollment.  If PKIX waits, it will lose the capacity to interoperate with the long-term-deployment products that other companies put out.

The only thing that the members of the PKIX-WG must do is realize that it's no longer shackled -- it's free to do things which don't exhibitionistically tag the communications which occur under cover indelibly with their parties.  The shackled mindset is a holdover from Netscape's pre-Wassennar Arrangement US ITAR days -- in retrospect, the prevailing dogma in PKIX and TLS seems to have been "If we can't let the state know what's being said, we at least have to let the state know who's talking."  This was appropriate for developing under the attitude of "it's an armament which can be used against the state"; it is no longer appropriate for a world where "it's an armament which can be used against information thieves", the EU mandates privacy protections for every consumer, and where every citizen of the state should be a free, independent sovereign over who he chooses to share his information with.

Perhaps more importantly, the citizen should prevent any of his information from being shared with parties he doesn't choose to share with.  This includes the information of "who he's sharing information with".

> --
> Matt

I'm not predicting doom and gloom from generalities, I'm implementing a protocol like this regardless.  I'd rather have the design input of systems designers who have practical technical experience, rather than idealistic views of how everything should be from people who haven't implemented it and don't have a clue how things really work (which is how PKIX and and SSL/TLS got their impositions).

I'm working from existing legal principles which I have been trained on, but I am not a lawyer.  Few if any others in this WG are, either.  It was the attempt to create something that the court system couldn't mess up -- bypassing the dispute-resolution processes of the sovereign state by encoding policy into standard, imposing dogmatic adherence to the rules -- which led to the current state of affairs.  I'm proposing a protocol and system which simply and effectively utilizes and dovetails nicely with the capabilities and requirements of the state, while still providing complete privacy protections for the consumer user.  It's easier to do when recognition of the authority of the state is made part and parcel of the standards -- and it's also easier to do when the authority of the consumer is recognized as well.

-Kyle H

---

From: Matt McCutchen <[email-masked]>
Date: Fri, 25 Mar 2011 12:24:17 -0400

On Tue, 2011-03-22 at 19:48 -0700, Kyle Hamilton wrote: 
> I see you've done so.  I believe, though, that it is missing the
> point.  There should be no need for the user at the endpoint -- the
> consumer -- to have to worry about it.  The consumer's software must
> protect his privacy regardless of what the server says, does, or
> offers.

Ultimately, the user will have to decide what they are willing to send
to whom.  But the process should be much more streamlined than requiring
the user to make a decision based on an indicator in the client
certificate dialog, agreed.

> (it's much like the current plethora of privacy policies on all of the
> commercial websites that people put their personal information on --
> the server mandates that it will do things one way, and the only
> option for the consumer is to choose to not consume the service.)

Yes, and I don't understand why you think automation alone will shift
the market power in favor of consumers in this space.  I expect you'll
just end up automating the above.

> In addition, with such things as SCEP, PKIX-WG is facing challenges
> where it created something and now must support it.  TLS-WG has the
> same issue, which is why they had to retroactively patch every version
> of TLS back to 1.0 with the "secure renegotiation indication"
> extension.  With this proposed protocol, that renegotiation indicator
> is almost obviated (as both ends of the link would be authenticated in
> almost every transaction).

Please leave the renegotiation issue out of this.  As I said last time
(https://www.ietf.org/mail-archive/web/pkix/current/msg28211.html), it
is a mistake that has been corrected.  It is not a reason not to use
server-only-authenticated TLS.

Are you proposing that clients visiting a site that currently uses
server-only-authenticated TLS would send a nonce client certificate but
not bundle anything else?  What would be the benefit of doing that?

-- 
Matt