Re: [lamps] Draft LAMPS Recharter

[Phillip Hallam-Baker <[e-mail]>]

On Thu, May 3, 2018 at 9:25 AM, Ryan Sleevi <[e-mail]> wrote:

>
> On Thu, May 3, 2018 at 7:47 AM Phillip Hallam-Baker <[e-mail]>
> wrote:
>
>>
>> ​The reason to move to short term certs is simple and has nothing to do
>> with insufficiency: It is simply more efficient.
>>
>> Once you automate the process of certificate management, the move to
>> short lived certs is inevitable and obvious because then the server only
>> needs to cope with a single data object rather than two equivalent data
>> objects.
>>
>> With a long lived cert plus OCSP:
>>
>> * The server has to update its cert every X days and update its OCSP
>> token, a different code path, every day.
>> * The client has to process the cert and then process the OCSP token,
>> each of which has a separate trust path.
>>
>
> To make sure I understand this claim: Is the view that adding yet another
> method, which is not as expressive and with a host of trade offs, will
> somehow payoff at some point in the future in which clients and servers no
> longer have to implement or care about revocation data?
>

Short lived certs are exactly as expressive as long term plus OCSP with
pre-generated validity tokens.

While the intent of the original OCSP proposal (which I wrote the draft for
and can thus speak with authority) was to enable insurance of individual
transactions, I am not aware of any use of OCSP for that purpose. Nor do I
expect any such use to arrive in the future as we subsequently developed
the TAXI (Trust Assertion XML Infrastructure) for that purpose which is now
known as SAML.

I would rather like to think “the spec is prettier if we do it this way” is
> a poor justification for taking on work, so I was hoping a bit more
> substance to a reply.
>

​Simpler is better. ​

Changing practice in the browser world is certainly possible but has a long
payback time as it takes quite a while for browsers to update.

Instituting best practice for Web Services is a totally different matter as
there are new services being deployed every day and those that exist are
often kept up to date very aggressively.


> With a short lived cert:
>>
>> * The server has to update its cert every days.
>> * The client has to process the cert.
>>
>> I do not understand where client certificates come into the argument.
>> Obviously, the same approach may be applied to client certs but why would
>> anyone bother when the browser UI for client auth is so utterly useless?
>>
>
> It’s unclear: you read the draft and are disagreeing with it, or did you
> read me reply and weren’t aware I was referencing the draft? The mention of
> browsers leads me to believe the latter, because the message I was replying
> to identified this work was not for the Web PKI, but if the former, I’m
> hoping to bring a bit more clarity to the position.
>

​At this point in time, PKIX has established itself as a mechanism ​for
supporting server authentication. PKIX has not established itself as a
mechanism for user authentication. SAML has been vastly more successful in
that role. And I do not see that changing.

TLS Client auth is not very useful as a means of authenticating users in a
Web browser but it is very widely used as a means of authenticating
Services to other Services.

The distinction between 'client' and 'server' is not very useful here
because all a 'client' is, is the party that initiates a transaction. PKIX
is for authenticating services whether to users or to other services and
regardless of whether it is the initiator or responder in a transaction.

Of course we need to move to short lived certs for services because in the
modern deployment, a service typically lives on a particular host for a
matter of a few days or even hours. Generating keys valid for up to 2 years
and then churning them round a data center simply means that every machine
in that data center is a potential point of compromise.

An obvious control to help mitigate this problem is to limit cert validity
to the length of time we expect the service to remain on a particular
machine and to generate new keying material every time the service moves to
a new host.