On 3/13/2014 12:59 AM, Olle E. Johansson wrote:
On 12 Mar 2014, at 21:02, Derek Atkins <[email protected]> wrote:
Joe Touch <[email protected]> writes:
Why not just use the term "unauthenticated encryption", when that's
exactly what's happening?
Well, it's not necessarily what's happening. The data itself might
still have "integrity protection" (which is a form of authentication.
You're just not authenticating the endpoint, which means you could be
subject to a MitM attack. Alternate terms could be "Unauthenticated
Keying" or "Unauthenticated Key Exchange" which are closer (IMHO) to
what's going on.
To get any movement in this area among developers and sysadmins,
we need a language that any sysadmin or developer understands.
I believe we can easily get them to understand "Opportunistic encryption"
but if we go into explaining "keying" or "key exchange" they will be lost in
the OpenSSL documentation maze again.
The problem is that OE isn't what's going on when you simply choose not
to authenticate keys. Yes, it's a simple term, but it's also an
incorrect one.
I appreciate the desire to find a cute marketing term, which is why I
offered "zero-ID" - which is more accurate and easier to explain to
developers and sysadmins (what do you *do* to make OE? it's easy to make
zero-ID - you stop using IDs).
I'm not wed to that term, but market-speak is your metric, OE fails on
multiple counts.
As a side note:
https://tools.ietf.org/html/rfc5630
Use the term "best-effort TLS" to describe that a SIP ua is perfectly
allowed to set up a TLS session based on policy regardless if there
is a "sips:" URI. I don't know where that terminalogy came from. It's
always used with quotation marks in the RFC. This "best-effort TLS"
still requires verification of the certificate though.
That's similar reasoning as to why I don't like OE.
Joe
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane