Re: [saag] SHA-1 to SHA-n transition

[Nicolas Williams <[e-mail]>]

On Thu, Feb 26, 2009 at 07:58:37AM -0800, Bill Sommerfeld wrote:
> IMHO we need a transition plan which allows websites to deploy with
> sha-n certs in parallel to sha-1 certs from day 1 (and, if I dare
> mention it, we need to find some way to do this without making them pay
> a bunch of nuisance fees to CA operators).

Indeed.  And not having to pay "nuisance fees to CA operators" falls out
of not having a real PKI -- no real PKI, no real CAs to pay.

What we need is something like DIGEST-MD5, but tied into browser apps in
a different way than DIGEST-MD5 is today (more on this below).  Given
this we can forego PKI -- just do channel binding to TLS (with or
without server certs, whether CA-issued or self-signed).

My proposal:

1) Add JavaScript interfaces to deal with DIGEST-MD5, successors,
   GSS-API, ...

   These could be simple XmlHttpRequest object extensions, where
   DIGEST-MD5 can already be used, and where HTTP/Nego and successors
   could be used too.

2) Tie the above interfaces to the browser UI.

   Mark pages/windows/tabs with colors/text/sound/whatever appropriate
   markers as:

    - plain (nothing is authenticated)
    - weak server authentication (what we do today with HTTPS)
    - mutually authenticated (DIGEST-MD5/something else was used through
      the above mentioned interfaces, with credentials furnished through
      the trusted path)

   Add markers for degree of security based on crypto algs used.

   Make it simple for users to see the authenticated identities.

   We'll also need a new flavor of cookies.  We have "secure" and "not
   secure" cookies now; we'll need "issued in mutually authenticated
   context" -- call them "authenticated cookies."

   Prompting for DIGEST-MD5/whatever credentials needs to be done
   securely.

   As with all UI design matters, it's important to find a way to
   prevent attackers from emulating the UI with enough fidelity.  (E.g.,
   don't allow full-screen apps.)

3) Teach users to look for the new markers.  *This* is the hard part.
   Education will always be the hard part.

   (Not that UI design isn't hard -- it is, and it is a requirement to
   get the UI right if we're to educate users successfully.)

4) Federation/whatever fits into (2).  We already have lots of
   federation choices.  The propblem is how federation fits in
   generally.

Given (1), (2) and (3) the transition to SHA-n looks a lot simpler: it's
completely piecemeal, there's no CAs to shame into getting SHA-n support
because PKI gets cut out of the picture (even if server certs are still
used, they no longer matter for security).  TLS would still be used, so
getting TLS implementations updated to 1.2 so that SHA-n would be a
requirement.  As would be a successor to DIGEST-MD5.

We'd also be solving some of the other web security problems with this
approach.

Nico
--