authentication without https (was Re: https at ietf.org)

[Dave Crocker <[e-mail]>]

On 11/6/2013 6:09 AM, Ted Lemon wrote:
> I assume that what we want is a mechanism for authenticating the
> content; in this case there is no need to encrypt the content.   We
> are just talking about HTTPS because no mechanism exists to do the
> one without the other.   So the problem you are talking about, which
> I agree is real, is simply evidence of a missing feature; maybe that
> is where this debate ought to go.


G'day.

I'm glad this discussion has distinguished between wanting content 
authentication vs. content confidentiality.  While some uses of https 
can do both, it's good to note that a) it can't do only authentication, 
and b) requiring https prohibits many current, legitimate scenarios.

I take this state of affairs -- combining the goal of authentication 
with a desire to preserve an extensive operational base -- as meaning 
that we need to create something to solve the problem.  This would, of 
course, mean that participants in the new mechanism do need to adopt new 
software, but it also would mean that non-adopters do not -- and won't 
be bothered by the presence of the signature, if it's packaging is 
designed properly.

There happens to be a solution lurking close by, just the other side of 
this door...  The door is marked "transparent authentication of content".

The base technology is DKIM:

      http:dkim.org

which affixes a signature using a special header-field to email.  The 
signature is transparent to any engine that doesn't recognize it, 
including human readers who are typically being shown a common subset of 
the full email header.

(DKIM semantics do not match the authentication goal here.  It uses 
authentication technology, but it uses it only to authenticate an 
identifier it affixes to the message; the presence of that identifier 
means that its owner of the identifier is taking 'some' responsibility 
for the message, not that the owner is certifying the content or 
claiming ownership of the content. So my suggestion is about underlying 
DKIM technology, not DKIM itself.)

The mechanisms of DKIM could be rather easily adapted to provide content 
authentication semantics, with the signature carried in a header field. 
  It would therefore provide authentication for any web client that 
upgraded and would be transparent to others.

There's been an effort to define a flexible version of this underlying 
mechanism, for just this sort of adaptation.  It's called DOSETA:

      http://www.trusteddomain.org/doseta.html

This leaves some real engineering work to be done, but provides a very 
high point of departure for solving the problem of content 
authentication that does not bother the legacy installed base.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net