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. We might have to separate a "marketing name" of the overall concept from a set of technical definitions we can refer to when explaining this in RFCs. For me, I can happily accept using OE as the unclear marketing bullshit term for a set of solutions that set up an encrypted communication channel - regardless of URI or configuration, without any indication to the user in the phone UI or browser UI - no locks! I can understand that this may be hard to accept in a technical community, but we have a huge educational effort ahead of us in order to get this done. The general concept has to be easy to explain. In summary, I propose that we keep OE as the overall term and define a set of more precise terminology to explain what goes on in the background. As Victor pointed out, there may be different solutions in different protocols. 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. Cheers /O _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
