On Wed, Aug 06, 2014 at 01:36:00PM -0400, Paul Wouters wrote:
> >12. Saying that an OS-capable peer may demand more than unauthenticated encryption does
> >conflict with the stated goal of not requiring coordination (between administrators).
I am not aware of any evidence for this conflict, and have implemented
and deployed a protocol in which the conflict is absent, by constrast
with the non-opportunistic Web PKI TLS (applied to SMTP) where
coordination between administrators was required and made deployment
taxing and limited.
> >I think is an example of trying to make the term OS all encompassing.
Not, "all encompassing", rather not artificially constrained to
needlessly weak mechanisms.
> Well, the term "opportunistic security" surely feels more encompassing
> compared to "opportunistic encryption". If we are only talking about
> encryption, don't call it security.
Most of us are not talking about just (unathenticated) encryption.
However, the draft is about communications (or channel) security,
not security generally. So, if we're really in the mood for making
the term more "precise", we could say "opportunistic channel-security"
or "opportunistic communications-security", but I don't think this
is helpful.
To the question of whether "best effort key management" or similar
is better, my main objection is that this composes poorly with
actualy protocols that employ the design principles:
- "Opportunistic DANE TLS" works
- "Best effort DANE TLS" does not.
The point being that "DANE TLS" is applied when possible, not to
some unspecified extent.
--
Viktor.