Viktor sent me a preview copy of the latest draft.
I see he made some adjustments, to text I had comments on. (Thanks!)
Below are the comments I provided him that were not responded to or
resolved in the version he just released. And a few comments on new text...
I'll repeat my point about the problems with saying 'security' rather
than 'encryption'. This draft is now clearly and solely about
encryption. And that is exactly the right focus for the draft.
In this draft, authentication is only in the service of better
encryption. And no security mechanisms other than encryption (and
authentication) are discussed. Nor should they be.
When a term is intended as the primary reference to a topic, the term
needs to be clearly about that topic, and not something more general.
For this draft, the topic is flexible encryption frameworks, and nothing
else. The term that is used needs to be clear about that.
"Opportunistic security" is a very, very long way from such clarity.
So I'll repeat my suggestion: Either use "opportunistic encryption" and
expand upon the existing definition, to increase it's scope. Or
choose a term like "Best Effort Encryption", which is entirely
intuitive, clear and accurate.
Review:
> Abstract
...
> established practice of employing cryptographic protection against
> both passive and active attacks, or no protection at all. As a
"Employing" misses the point. The sentence needs to be clearer that the
protected is required, or else there is not protection:
established practice of requiring cryptographic protection against
both passive and active attacks, or no protection at all.
> Opportunistic Security: Some Protection Most of the Time
"More" is a promise of success that you and we can't make.
A little restraint in the language will help. In the same style of
catchy phrasing, but with a reduced tone of hype, I suggest:
Some Protection More of the Time
> 1. Introduction
> Historically, Internet security protocols have emphasized
> comprehensive "all or nothing" cryptographic protection against both
> passive and active attacks. With each peer, such a protocol achieves
> either full protection or else total failure to communicate (hard
This is new text. It's much better than it's predecessor. A small,
word-smithing quibble, worth pursuing because it relates to a core issue:
"Emphasized" is not really correct. It implies preference, but with
flexibility.
The mechanisms have imposed, demanded, only permitted, or the like.
They have typically not had a hierarchy of choice with a 'preference'
for stronger protection. That is, after all, the point of innovation
with opportunistic approaches. So, replace emphasized with a word
making clear that all-or-nothing has been binary.
> Designing and deploying a key management for the whole Internet is
> for now an unsolved problem. For example, the Public Key
> Infrastructure (PKI) used by the web (often called the "Web PKI") is
> based on broadly trusted public certification authorities (CAs). The
I believe it is not "for" the web. To my knowledge, there is nothing in
it that is specific to the web.
It is "used by" the web, but I believe it is also used by other services.
Also, in spite of there being an existing working group that does use
the term "Web PKI", I suggest removing references to the term. The
important point being made -- that there are too many trust authorities
-- is generic. It really is an essential concern and it doesn't matter
whether it is for the web or email or whois or...
> The
> Web PKI has too many trusted authorities and imposes burdens that not
> all peers are willing to bear.
To my knowledge, it is only used to validate the server, never ( or at
least, almost never) the client. This is one of the continuing points
of misunderstanding due to casual use of language, like 'security', that
is overly broad.
> Web PKI authentication is vulnerable
> to MiTM attacks when the peer reference identifier ([RFC6125]) is
> obtained indirectly over an insecure channel, perhaps via an MX or
> SRV lookup.
Huh? That needs a citation, to explain and 'prove' it more carefully.
> However, at this time, DNSSEC is not sufficiently widely
> adopted to allow DANE to play the role of an Internet-wide any-to-any
> authentication system.
RFCs typically should not make temporal references. RFCs often have
utility for decades and the conditions at the moment of writing are no
longer relevant.
This requires a bit of word-play, to make the important point, but
without reference to possibly transient issues.
Perhaps:
For some scenarios DNSSec and DANE cannot be, or are not, used to
permit authenticated encryption.
> Opportunistic security protocols on the other hand, can begin to use
> DANE immediately, without waiting for universal adoption.
The term OS has not yet been defined.
Probably the better choice is to eliminate the sentence. It seeks to
sell the solution, but this section of text is really only giving
substance to the problem statement. Save the solution discussion for later.
> 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.
> promotes stepping up from cleartext, not down from authenticated
> encryption.
Actually, it involves stepping /down/. In addition, the sentence is a
bit challenging to read.
Perhaps:
An opportunistic design pattern involves using the strongest level
of protection that is compatible among participating peers. Rather than
devolving to no session or no protection, it permits use of less
stringent protection, when that is all that can be supported amongst the
peers.
> The risk of active attacks should also not be ignored. The
> opportunistic security design pattern features a range of
> cryptographic protection levels, with encrypted transmission
Add a sentence to provide a better bridge to the conclusion that is
being promoted:
...not be ignored. Hence there is benefit in always seeking the
strongest cryptographic protection possible, while allowing a range of
lesser levels of protection. The opportunistic...
> 3. The Opportunistic Security Design Pattern
>
> Opportunistic Security is a protocol design pattern that aims to
> remove barriers to the widespread use of encryption on the Internet.
Note that that is a 'purpose' statement, and not a technical definition.
And, again, it is about 'encryption' specifically and not 'security' in
general.
> 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?
> We will use the phrase "opportunistically employed" to mean that the
> use of a type of protection or a security mechanism was tailored to
> the advertised capabilities of the peer. 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.
> 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?)
The pattern is about capabilities.
I suggest simply dropping the first sentence and the "Rather". The
second sentence is reasonable on its own.
> Opportunistic security protocols should provide a means to enforce
> authentication for those peers for which authentication can be
> expected to succeed based on information advertised by the peer via
> DANE, TOFU or other means. With DANE, the advertisement that a peer
> supports authentication is downgrade-resistant. What is
> "opportunistic" here is the selective use of authentication for
> certain peers; much in the same way as unauthenticated encryption may
> be used "opportunistically" with peers capable of more than
> cleartext.
The first sentence is cumbersome, at best. I'm not sure I understand all
of it. But worse, the beginning of it is probably wrong!
If authentication is required, we have classic authenticated encryption,
not opportunistic <foo>.
The 'opportunistic' construct is all about permitting lesser protection.
If it isn't permitted, we are not in an opportunistic scenario.
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.
On reflection, I think that the point intended by this paragraph is
along the lines of:
Opportunistic patterns require using the strongest protection that
is possible amongst peers. In particular, authenticated encryption is
to be used whenever possible, rather than unauthenticated encryption.
For example with DANE, the advertisement...
> 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.
> 4. Opportunistic Security Design Principles
> Emphasize enabling communication: The primary goal of opportunistic
> security is to enable secure communication and maximize
> deployment.
I think that counts as two goals.
> 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.
> 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.
> 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.
Encryption without authentication is still a useful degree of
'security'. (Actually this point again highlights why using the word
"security" or "secure" is actively unhelpful.)
I assume that the point here is about misleading folk into thinking they
have a degree of protection that they don't really have. However I
believe there is no widely-used terminology that communicates that.
"secure channel" is most certainly NOT a a widely-used term that
communicates that.
However the bullet point /is/ important.
So perhaps:
Unauthenticated encrypted communication must not be misrepresented as
providing more protection than it does. In particular, its use need to
carry the explicit warning that it is vulnerable to MITM attacks.
> 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...
> 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'.
> encryption), but will employ TLS (and therefore encryption) when the
> SMTP server announces STARTTLS support. Since the initial ESMTP
> negotiation is not cryptographically protected, the STARTTLS
> advertisement is vulnerable to MiTM downgrade attacks. Further, MTAs
> do not generally require peer authentication. Thus opportunistic TLS
> for SMTP only protects against passive attacks.
>
> Therefore, MTAs that implement opportunistic TLS either employ
> unauthenticated encryption or deliver over a cleartext channel.
deliver -> transmit
("deliver" is a term of art in email and for the current discussion,
MTAs don't do it.)
> 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.
> 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...
> is common practice to fall back to cleartext transmission not only
> when STARTTLS is not offered, but also when the TLS handshake fails,
> or even when TLS fails during message transmission. This is a
> reasonable trade-off, since STARTTLS protects only against passive
> attacks, and absent an active attack TLS failures are simply
> interoperability problems.
> 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.
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.
>
> 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.
> opportunistic policy can be counter-productive when it demands more
> than many peers can in fact deliver. Non-opportunistic policy should
> be used with care, lest users find it too restrictive and act to
> disable security entirely.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net