On Fri, Aug 15, 2014 at 08:54:18AM -0700, Dave Crocker wrote:
Designing and deploying a key management for the whole Internet is
for now an unsolved problem.
Oops the word "system" got lost after "key management"... Will
have to add that back when I next get a chance.
The opportunistic security design pattern involves stepping up from a
baseline security policy compatible with all relevant peers to the
most secure policy compatible with the capabilities of a given peer.
Actually, it involves stepping /down/.
The draft is providing a *definition*. Definitions should be taken
at face value. This is not an empirical statement whose truth one
can debate, it is a definition.
A related goal is broader adoption of protection against active
attacks, by enabling incremental deployment of authenticated
encryption.
Although this sounds entirely reasonable, there is no explanation
provided to make it credible. (n fact it is not at all clear to me that
is /us/ credible...) How will use of an opportunistic pattern lea to
broader adoption?
By enabling deployment that is incremental and yet on by default.
With "all or nothing" security there is no way to allow the network
effect to help reach near-universal adoption.
Both opportunistically
employed encryption and opportunistically employed authentication
need to avoid deployment roadblocks and need to be designed with care
to "just work".
I have no idea what the last sentence means.
It means mechanisms that consistently work out of the box, no need
to tune explicitly for each peer or prompt the user when they
predictably fail a significant fraction of the time.
Opportunistic security does not start with an over-estimate of peer
capabilities only to settle for lesser protection when a peer fails
to deliver. Rather, opportunistic security sets a minimum protection
level expected of all peers, which is raised for peers that are
capable of more.
This paragraph is not very helpful. The issue here has nothing to do
with estimation. (Can a design pattern make an estimation?)
An estimate is what one has, when one has not ye performed the
measurement. Perhaps a better word could be crafted here, suggestions?
I still think the original text is sufficient.
The first sentence is what you're consistently not taking at face
value, the point needs to be made.
If authentication is required, we have classic authenticated encryption,
not opportunistic <foo>.
Again no, you're still reading what you would have said, rather
than what the draft actually says. The draft actually defines a
way to do "opportunistically employ" authentication. And this is
important, and is the main point of departure from Steve Kent's
earlier draft.
"Required of all peers" is not opportunistic. Required when advertised
By a given peer
The 'opportunistic' construct is all about permitting lesser protection.
If it isn't permitted, we are not in an opportunistic scenario.
Again, that's not the *definition* in this draft. You might have
defined it that way, but this draft does not.
The term needs to be quite disciplined about what is excluded and what
is included. As soon as the term is too broad, it is meaningless.
No, not meanigless, just not the meaning some would have come up with.
Enforcement of authentication is not incompatible with opportunistic
security. If an OS-enabled peer (A) makes available authenticated
key material, e.g., via DANE, to peer (B), then B should make use of
this material to authenticate A, if B is OS-enabled and supports
DANE.
This is worded a bit differently than in the preview draft I saw, but I
still have no idea what that sentence means. The language that follows
is about preference, not enforcement.
Ultimately I can't tell what the motivation for this sentence is.
You're still not reading the definitions as stated.
If authentication is only possible for some peers, then it is
acceptable to authenticate only those peers and not the rest.
It is only sometimes acceptable. It is essential that the text here
highlight that such a fallback needs to be the result of careful
analysis and choice and not a casual default.
There is no fallback from a suitably advertised capability to be
authenticated (e.g. via DANE). Similarly the TACK draft is a type
of opportunistically enabled authentication that is more of the
TOFU style.
Employ PFS: Opportunistic Security should employ Perfect Forward
Secrecy (PFS) to protect previously recorded encrypted
communication from decryption even after a compromise of long-term
keys.
I'm told that PFS isn't really possible for asyncrhonous, object-based
encryption, such as for email.
PFS works for hop-by-hop SMTP, but yes, not likely for end-to-end
S/MIME or PGP. This could be qualified with "when possible" or
some such.
No misrepresentation of security:
Unauthenticated encrypted communication must not be misrepresented as
communication over a secure channel.
Oh boy. That sentence is far too compact and not obviouly correct. In
fact it is arguably wrong.
That's the -02 draft text you're responding to.
In summary, the opportunistic security design pattern encompasses
protocol designs that remove barriers to the widespread use of
encryption on the Internet. The actual protection provided by
opportunistic security depends on the advertised capabilities of the
communicating peers. Opportunistic security aims to encrypt all
network traffic, while allowing fallback to cleartext with peers that
do not appear to be encryption capable.
Ran out of time. Haven't reviewed the remainder...
So is this.
5. Example: Opportunistic TLS in SMTP
Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS
([RFC3207]) ESMTP extension. MTAs acting as SMTP clients are
generally willing to send email without TLS (and therefore without
Software does not have a 'will'. I think what is meant here is 'able'.
Except that we're describing tolerated lower-bounds, not abilities.
Therefore, MTAs that implement opportunistic TLS either employ
unauthenticated encryption or deliver over a cleartext channel.
deliver -> transmit
Sure.
Recent reports from a number of large providers suggest that the
majority of SMTP email transmission on the Internet is now encrypted,
and the trend is toward increasing adoption.
This anecdotal comment isn't needed, isn't substantiated, and is going
to be distracting when this document is read 20 years from now. I
suggest removing it.
The example is an anectote, a protocol case-study if you like, not
a specification. It is I think useful to highlight a success of
OS in this space.
Not only is the STARTTLS advertisement vulnerable to active attacks,
but also at present some MTAs that advertise STARTTLS exhibit various
interoperability problems in their implementations. As a result, it
Again, the ephemeral frame of refernce won't be helpful.
So:
but also an MTA that advertises STARTTLS can produce various
interoperability problems in its implementation. As a result, it might
choose to fall back to cleartext...
Except that the wisdom of the cleartext retry is rooted in the
operational status-quo. When the interoperability issues with
clunky old MTAs fade away, the engineering trade-off will be
different.
6. Security Considerations
Though opportunistic security potentially supports transmission in
cleartext, unauthenticated encryption, or other cryptographic
protection levels short of the strongest potentially applicable, the
effective security for peers is not reduced. If a cryptographic
capability is neither required by policy nor supported by the peer,
nothing is lost by going without. Opportunistic security is strictly
stronger than the alternative of providing no security services when
maximal security is not applicable.
I'll repeat that counting "cleartext" as part of an opportunistic
pattern is a strategic error. In simple terms, it is saying that no
security is part of security.
Yes, in order to make security usable, we tolerate no security as
a baseline where required.
The issue is not that cleartext is bad or that permitting it might not
be ok. It's that it needs to be outside of the scope of an
opportunistic pattern.
Disagree. Otherwise we get into "fallback" and all that, but OS
is about attempting to get more than minimum (possibly none)
security. Not about settling for less. As defined! Not empirical
fact to debate. You could argue for a different definition, but
it should be clear that you'd prefer a different formulation, not
that the current one is "wrong".
Opportunistic security coexists with and is preempted by any
applicable non-opportunistic security policy. However, such non-
This first sentence makes no real sense to me or worse is confusing. It
does not "coexist". If it is preempted, it is at best subordinated.
Well, coexists and is subordinate to. But that is clearly evident from
the text...
--
Viktor.