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

[Eric Rescorla <[e-mail]>]

At Thu, 26 Feb 2009 10:54:48 -0600,
Nicolas Williams wrote:
> 
> 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.)


I don't want to get into an extensive argument about this on SAAG,
but I don't think this direction is particularly promising, for
reasons I've indicated before: namely that you're handwaving
the difficult part of the problem, UI, which we have no real 
idea how to solve. Sure, if we solved that, there are any
number of things we could do, but absent that, the other things
are fairly useless.


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

I think you're rather overselling here: this only works well for
account-based systems. There are plenty of cases where I need to
connect to someone where I only know their name but I don't yet have
an account (e.g., https://www.amazon.com). The mechanism that you
provide doesn't work at all in this case. Rather, you need some
third-party verifiable mechanism. I suppose one could argue that certs
aren't a good such mechanism, but they're the one that TLS supports
and I suspect any replacement would smell a lot like certs.

-Ekr