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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]