ietf
[Top] [All Lists]

Re: Target audience? (was Re: [saag] Last Call: <draft-dukhovni-opportunistic-security-01.txt> (Opportunistic Security: some protection most of the time) to Informational RFC)

2014-08-04 12:53:17
On Mon, Aug 04, 2014 at 10:08:36AM -0700, Dave Crocker wrote:

Looks to me like they are listed as key management methods.

Well, Wikipedia is not necessarily authoritative here.  We do have
the term "key agreement" available, and it should be noted that in
many cases (including many cases with TOFU) even when long term
keys are not necessarily strongly authenticated in addition to the
long-term (managed) keys, there are typically also per-session
ephemeral keys obtained via a suitable key agreement scheme.

We can spend a lot of time fine-tuning subtleties of wording that
only a few select initiates of the arts will appreciate.  It is
reasonably clear from the context of the draft that key management
is about authentication keys, most commonly in the form of PKIX
X.509 certificates.

More generally, for this draft, I would expect the term 'key management'
to have extremely broad and inclusive meaning, only barely qualifying as
a technical definition, simply because I thought this document was
intended for broad use.

While the drafts intended audience is broad, the meaning of the
term key management is to be understood in context as the primary
barrier to universal adoption of authenticated active-attack
resistant protocols.  Thus the intended meaning is not so broad as
to include cases that are barriers to said adoption.

It is hard to imagine an audience of non-specialists finding this
an issue to quibble over.  It is rather secondary.

All of which leads to the basic question of who this draft is for?  I
thought it was for broad-based use among technicians, technical managers
and others, including folk who are not security experts and folk who
might not even be networking or computer experts.

Yes, and therefore, subtle nuance, and overly precise definitions are
a distraction from the main thrust of the document:

    * Encrypt whenever possible, even when authentication is not an option.
    * Do consider designs where authentication is employed when possible,
      on a peer-by-peer basis.

It really would help to gain some rough consensus about the target
audience for this document, so that that population can be referenced
when attempting to evaluate choices, rather than having anyone attempt
to rely on their personal preferences, here on the IETF.

The document is a new security manifesto for the Internet at large.

I personally welcome all clarifications of the core message.  I'd
prefer to not get stuck in the weeds.  If I am there already, please
help me out, if some weeds are required for a balanced diet by IETF
consensus, I'll add them in.

-- 
        Viktor.

<Prev in Thread] Current Thread [Next in Thread>