[Cryptography] SSL Certificates are expiring...

[Phillip Hallam-Baker]

On Fri, Feb 14, 2020 at 4:43 PM Bill Frantz <frantz at pwpconsult.com> wrote:

> On 2/13/20 at 6:40 PM, phill at hallambaker.com (Phillip
> Hallam-Baker) wrote:
>
> >On Tue, Feb 11, 2020 at 7:43 PM Bill Frantz <frantz at pwpconsult.com>
> wrote:
> >
> >>...
> >>
> >>When you make good money selling certificates, you love the
> >>hammer you have.
> >>
> >
> >I think this is an unhelpful way to think.
>
> Phillip and I will perhaps have to agree to disagree. I have
> always objected to having to rely on a "Trusted Third Party"
> (TTP) to validate any web connection. When I deal with
> individuals and businesses outside of the computer
> communications world, I use the model of recognition, not
> attestation. I may buy something inexpensive to start developing
> trust in my counter-party. I'll use the physical location or
> face as an anchor for that developing trust, not a TTP.
>

People have been complaining about my work for decades. The WebPKI met its
design brief and it was deployed at global scale. The same cannot be said
of any other alternative that was proposed.

The WebPKI design brief was very narrow, I know this because I wrote it
together with Michael Baum, Warwick Ford. The objective was to make
shopping online as safe for the customer as shopping in a store. That is
all. Confidentiality was not a primary concern, that was a secondary
concern necessitated by the fact that credit card numbers are bearer tokens.

The WebPKI was designed as an accountability infrastructure. The goal being
to ensure that if a merchant did not deliver, there would be consequences.
The objective was never to prevent the possibility of merchant fraud, it
was to limit the rate to an unprofitable level.


And the system worked so well fir the first decade, a lot of arrogant sods
decided they knew better and could start hacking parts out arbitrarily.
Like the revocation infrastructure. And then folk decided that it was an
all purpose confidentiality infrastructure because that is the only type of
security they can understand.

People can ignore me if they like, but blowing off the anti-Trust concerns
that drove Microsoft's contribution to the WebPKI is going to look like a
terrible idea pretty soon. 'Big Tech' is becoming a slogan and not just on
the far left, the GOP is actually rather more concerned. Facebook took
their party away from them and gave it to Putin/Trump. The whip of choice
will be anti-Trust and WebPKI will be just one of its tails.



> For the web, I would like to have my trust anchor for a site be
> through a key it controls, not a CA. When I go to a site using a
> CA as a trust anchor, I will keep my financial and secret data
> exposure low until I have some transaction experience. I want to
> know I'm talking to the same site I was talking to when I
> developed the trust I have, not a intruder site attested to by
> an untrustworthy TTP. (Do browsers still have over 80 trust anchors?)
>

The flaw in the WebPKI is that the design brief really calls for an
introduction scheme and TLS is configured as a transaction authentication
scheme. That is in part a consequence of not having the tools at the time
to make an introduction scheme portable across browsers and hosts. It is
also a consequence of the fact that a merchant does not necessarily defect
immediately and it takes time for defection to be observed. Oh and the fact
that many Web sites are incapable of managing PKI with the fidelity
required for pinning trust anchors.



> I think we have the current system because that was the only
> system people could build a business model around, and that the
> need to support that business model was reflected in
> contributions to the standards bodies.
>

The RSA and DH patents expired in the 90s, there was plenty of opportunity
to propose something different.

The problem is path dependence, not some conspiracy. We could have adapted
TLS for IoT devices really easily, just make use of self signed certs
painless. I suggested that on a half dozen occasions and it never happened.


>IoT needs a PKI. But PKIX has a bunch of assumptions built in that are
> >unhelpful (to say the least). Sure, we need something a bit different but
> >who is going to design and deploy that infrastructure?
>
> Phillip may have meant the following, but here's my take for clarity.
>
> It seems to me that an IoT device doesn't need a traditional
> PKI. It needs to validate the devices it talks to -- the light
> switch and the bulbs need to validate each other, which is
> better done through direct introduction. The phone app which
> allows remote control should be verifying the device using the
> public key pair built into it.
>
> When the IoT device talks to the mother ship to upload your
> behavior profile, it would be better to include the necessary
> public keys in the device when it is purchased.
>

You can't trust manufacturer inserted device keys and they turn out to be a
liability for the manufacturer - just ask Huawei.

The approach I am proposing in the Mesh is to use threshold key generation
so that manufacturer installed keys are only ever used during onboarding.
The administrator issues a seed from which a second keypair is generated
deterministically and the sum of the two private keys is used for the
private key of the device within a particular Mesh.

So if the built in device key is {d.B, d} where B is the base point and the
administrator device provisions {a.B, a}, the composite key pair is
{d.B+a.B, (d+a) mod Q} where Q is the order of the subgroup.

The really nice thing about this approach is that we don't (usually) need
to worry about proof of possession. The admin device can calculate the
public key of the device in the user's Mesh without knowing d. And that is
what they credential. So the device can't actually make use of the
composite private key unless they know d.

[Yes, there are some pitfalls to watch out for, this approach means that as
far as external parties are concerned, the private key is at lest as strong
as the stronger of the two key contributions. Unfortunately, the public key
turns out to be as trustworthy as the least trustworthy of the
contributions. Which leads to rogue key attacks...]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20200216/9fed741f/attachment.htm>