Re: [saag] Last Call: <draft-dukhovni-opportunistic-security-01.txt> (Opportunistic Security: some protection most of the time) to Informational RFC

[Stephen Kent <[e-mail]>]

Stephen,

Viktor did provide me woth a copy of -03, and solicited comments.

I am sorry to say that almost none of my comments seem to have been 
incorporated
into the text, expect splitting the reference section as required by RFC 
conventions.

I repeat my comments below. I have not bothered to remove ones that may 
have
been addressed, since Viktor didn't even bother to reply to me to discuss
the comments.

I also note something I didn't mention in my review. The Terminology section
redefines "authenticated encryption" and defines "unauthenticated 
encryption" so that
the terms means what Viktor wants. This introduces needless conflict 
with a widely accepted
term (the former). If Viktor used the phrases "authenticated, encrypted 
communication" and
"unauthenticated, encrypted communication" there would be no need for 
this contradictory
terminology.

Steve
-------

I like the new subtitle ☺.

Someone told me that there was a suggestion to use the phrase 
“opportunistic crypto-security” instead of “opportunistic security”. I 
think that would be a good change, as it more precisely defines what 
we’re trying to accomplish, and it avoids acronym collision with the 
more traditional use of OS.

Abstract

I’m not fond of the phrase “protocol design pattern”. I don’t recall 
ever hearing that phrase before. If you substituted “guidelines” or 
“principle” for pattern that would be more in keeping with existing 
terminology.

“OS protocols tailor the minimum acceptable channel security to the 
capabilities of the peer systems.” I don’t see the word “acceptable” as 
appropriate here. “Achievable” makes sense, but what is or is not 
acceptable seems to be a different matter.

“As a result, at least some cryptographic protection is provided most of 
the time.” We hope this will be true, but it’s not at all certain, so 
this statement is not supportable.

Introduction


Overall comment: the introduction seems rambling. It does not progress 
in a simple, clear fashion to make the argument you want. I’d re-write 
it as follows:

- motivate the development of the OS/OC guidelines by citing RFC 7258.
- note that there are many IETF standards for security, but they do not 
appear to be as widely used as we would like, as observed in 7258.
- say that we believe the reason that these protocols are not so widely 
used is because they usually require that at least one-way, if not 
two-way authentication (provide a forward reference to definitions in 
the terminology section), and that authentication is based on key 
maagement.
- Note that the mechanisms we have developed for authenticated key 
management (Web PKI, TOFU, etc.) all have some limitations, and these 
limitations prevent them from being used ubiquitously. The most recently 
developed mechanisms for authenticated key management are immature (cite 
DANE). While we wait for mechanisms such as DANE to become widely 
available, we want to encourage wider use of encryption for 
confidentiality.
- This observation suggests that if we want to remove barriers to 
widespread use of encryption, we need to make it easy to provide 
confidentiality (via encryption) w/o authentication. Note that while 
some IETF protocols offer this capability (e.g., TLS and BTNS) it is not 
commonly employed.
- Now, provide a concise definition of OS (or OC). Say, for example: 
“OS/OC is a set of protocol design guidelines that encourage widespread 
use of encryption. OS/OC is not a protocol. Protocols that comply with 
OS/OC guidelines may offer additional crypto-security services, e.g., 
integrity and authentication, if these services are supported by both 
(all) parties to a communication.”
- Note that the primary focus is OS/OC is countering passive 
wiretapping, as that is the primary concern cited in 7258. Nonetheless, 
active attacks are of concern as well, and thus OS/OC guidelines 
encourage use of mechanisms that counter such attacks. Nonetheless, a 
fundamental precept of OS/OC is that encryption should be enabled even 
if (crypto-based) authentication is not possible. Also note that OS/OC 
guidelines require that a failure to encrypt not prevent communication. 
This is necessary so as to allow for incremental deployment in a 
backward compatible fashion and encourage use of OS/OC. Thus plaintext 
communication is an acceptable fallback when peers are not able to 
encrypt, e.g., because not both (all) are employing OS/OC protocols.
- A protocol that adheres to OS/OC guidelines may be used in conjunction 
with a local security policy. That policy may override the default OS 
communication criteria. Specifically, local policy may require 
communication to be authenticated, in some or all cases. Such local 
policy is not viewed as contradictory to OS guuidelines.
- Finally, observe that OS/OC protocols are not viewed as a substitute 
for existing security protocols, that typically offer authentication as 
well as confidentiality. When such protocols can be employed, they are 
preferred to OS/OC protocols.
- Provide a overview of the rest of the document, noting that Section 3 
describes the OS/OC design guidelines.

Comments on section 1 text details:

I think the first sentence is still a poor start. When NIST began the 
crypto module evaluation program they discovered that almost all of the 
algorithm implementations submitted for review had security flaws. So, 
encryption is not so easy, although I agree that (authenticated) key 
management is harder.

The phrase “fully trusted” is vague.

“Web PKI public CAs are not always sufficient to authenticate the peer 
system.” What does this mean?

“And with so many certification authorities the communicating parties 
don't always agree on a mutually trusted CA.” I don’t think this is a 
common problem, because the major browsers seem to have adopted most of 
the same set of trust anchors.

“Historically, Internet security protocols have prioritized 
comprehensive cryptographic protection against both passive and active 
attacks over enabling systems with varied security requirements to 
communicate with each other.” This sentence is too long and complex.

“…while communications traffic is sometimes strongly protected, …”

“The fact that most traffic is unencrypted …” -> “The fact that most 
traffic is not encrypted …”

“Using the opportunistic security design makes passive attacks more 
difficult for all these actors.” -> “Using opportunistic security design 
principles makes passive attacks more difficult for all these actors.”

“In order to make encryption more ubiquitous, …” -> “In order to make 
encryption ubiquitous, …” BTW, 7258 intentionally avoids using the term 
ubiquitous; do you really want to use it here?

“… authentication should not be required where it cannot be expected.” 
What does this mean?

The penultimate paragraph in the introduction is redundant and wordy. 
Here is how I would write it:

If peers support a protocol designed to meet the OS guidelines, they 
will establish encrypted communication when authenticated communication 
cannot be achieved. Nonetheless, peers are encouraged to establish 
authenticated, encrypted communication when possible. If one peer is 
OS-enabled, and the other is not, then communication will be in cleartext.

“The opportunistic security design pattern features a range of 
cryptographic protection levels, …“ As others have noted, this wording 
suggests an ordering of the protection afforded by OS. There seems to be 
agreement that, given the range of security service options, there is 
only a partial ordering.

“Even with opportunistic security, protection against active attacks is 
still employed where unconditionally required by local policy or else 
determined to be applicable with a given peer.” I assume that what you 
are trying to say in the first two-thirds of his sentence is that local 
policy may require additional security services, and those trump the 
interoperability goal of OS. That’s an important notion, one that needs 
to be stated more clearly. The last phrase (underlined above) is 
mysterious. What are you trying to communicate there? Are you trying to 
distinguish between a local policy that requires all communication to be 
authenticated vs. only select peers? The text is not at all clear on 
this. Referring to active attacks, vs. requiring authentication, only 
makes the sentences here less clear.

Section 2.

Add definitions (or citations) for one-way and two-way authentication.

The definition of unauthenticated encryption refers to “key agreement” 
but that is unduly restrictive, i.e., key management mechanisms other 
than key agreement can deliver keys that are not bound to a “reference 
identity.”


Section 3

As I noted above, “pattern” is an odd term. I suggest “guidelines” or 
“principles” or “philosophy” instead. This section needs to have a clear 
distinction between what appears in it vs. in Section 4. Right now that 
distinction is not at all clear.

The phrase “advertised capabilities” seems appropriate for data that 
might be acquired out-of-band, e.g., via the DNS. When the capabilities 
are discovered via in-band communication, the term “negotiation” seems 
more appropriate.

“This includes the specific mechanisms, whether to require their use, 
how to handle errors and what to do when mechanisms are disabled.” I’d 
say “specific security mechanisms” here. Also, is it really common to 
communicate how to handle errors via the mechanisms to which you refer? 
What are examples? I’m not aware of such a capability in TLS or IPsec, 
for example.


“When the advertised capabilities of peers match reality, an 
opportunistic security design avoids causing communications issues that 
would otherwise prevent the deployment of protocol security.” What does 
the phrase “match reality” mean here? The underlined phrase in the 
sentence above is very confusing. Try to simply it.

“The determination of which security mechanisms to use can vary from 
case to case when the OS design pattern is used with different 
protocols. The protection provided by the OS pattern will depend on the 
protocol making use of the pattern. In many cases, OS will result in 
negotiating channels with one of the following security properties:” 
There are so many qualifiers in these sentences that it makes it appear 
that the “OS pattern” is indefinable. I don’t think you need to be so 
vague.

“Opportunistic security does not start with an overly optimistic view of 
peer capabilities only to be "disappointed" and settle for less when the 
peer fails to live up to expectations. Rather, the opportunistic 
security design pattern starts with a pessimistic view of the baseline 
capabilities of all peers, and is "pleasantly surprised" to learn that 
some peers can be expected to do more. Opportunistic security aims to do 
better than might be expected, rather than worse than might be hoped.” 
This text is needlessly anthropomorphic for a section that purports to 
be explaining a “pattern.”

“Enforcement of authentication in an opportunistic protocol is not a 
contradiction. …”

I suggest replacing the paragraph with:

“A peer that requires authentication may be compatible with the OS 
design guidelines. For example, authentication may be required by local 
policy. 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.

“Unless preempted by local or other policy, an opportunistic security 
protocol first determines the capabilities of a peer.” The escape clause 
at the beginning, especially the “other policy” phrase, makes this 
statement almost useless.

“This might include whether that peer supports authenticated encryption, 
unauthenticated encryption or perhaps only cleartext.” You’ve been 
advised that this the underlined phrase is not one you should be using. 
How about: “Typical peer capabilities are support for authenticated, 
encrypted communication, encryption w/o authentication, or only 
cleartext communication.”

“The appropriate communications security policy is then employed for 
each peer.” -> “After each peer has determined the capabilities of the 
other, a compatible set of security services can be employed.”

“An OS protocol may apply more stringent security settings with the 
underlying cryptographic mechanisms when authenticated encryption is 
required than when only unauthenticated encryption is employed.” What 
does “more stringent security setting” mean? dTthere is no total order 
for security capabilities, and the phrase “security settings” has not 
been defined.

“Authentication failure can be a reason to abort a connection to a peer 
that is expected to be authenticated. However, such a failure must not 
then lead to communication in cleartext when encryption is an option.” 
This guidance is confusing. Does it mean that when peer A determines 
that peer B is capable of authentication (e.g., via DANE), but 
authentication fails, that peer A MUST/SHOULD attempt encrypted 
communication, rather that rejecting communication? This is one of 
several possible interpretations of the two sentences above. You need to 
re-word the sentences to provide clear guidance here.

“Cleartext support is for backwards compatibility with already deployed 
systems. Cleartext transmission should be avoided in new OS protocol 
designs.” The first sentence is clear. The second sentence is vague, 
since, for backward compatibility, cleartext fallback is required. The 
third sentence provides clarification, making the second sentence 
redundant. Re-word.


Section 4

As noted in my comment at the beginig of Section 3, there is no clear 
distinction between the design “pattern” and design “principles,” other 
than formatting.

“Coexist with explicit policy” This principle is generally well stated, 
but one comment is confusing: “… opportunistic security might be enabled 
only for specified peers, …” If one does not authenticate a peer, how 
does one know that the peer is one for which OS is to be used? I would 
expect that a security policy would identify peers for which 
authentication is required, and if a peer is not authenticated, then OS 
might apply.

“Prioritize enabling communication” The description of this principle 
says “If a non-negligible number of potential peers are only capable of 
cleartext, then it is acceptable to fall back to cleartext when 
encryption is not possible.” This is still wrong. If ANY potential peer 
is capable of only cleartext, then it is acceptable to fall back to 
cleartext when communicating with that peer!

“Maximize security peer by peer” This principle overlaps with the first 
one. I presume that the phrase “… may, when applicable, refuse to 
communicate with peers for which higher security is expected …” is just 
an example of a local security policy mandating more than OS. If this is 
correct, this principle adds nothing, if this is not correct, you need 
to do a better job of explaining what is intended here.

“Encrypt by default” This principle begins by saying “An opportunistic 
security protocol at least encrypts communications.” The second sentence 
then recants this statement, noting the need to fallback to cleartext 
for backwards compatibility, and to accommodate “local policy.” Don’t 
make a string statement, and then have to qualify it this way. I suggest 
removing the first two sentences and making this principle all about PFS.

“No misrepresentation of security” is an interesting, new principle. 
Unfortunately, the phrase “communication over a secure channel” has not 
been defined, so the intent is unclear. Presumably you are alluding to 
communication over an authenticated, encrypted channel, but maybe an 
authenticated, cleartext channel would qualify. There is also an 
ambiguity about to whom/what the misrepresentation is directed. Is this 
a UI issue, an API issue, or what?


Section 5

“Thus opportunistic TLS based on STARTTLS support …” Is there an RFC 
that characterizes this behavior as “opportunistic TLS?” if not, then it 
seems inappropriate to apply this term to an existing mechanism.

“Self-signed certificates are common on receiving MTAs, …” Do some MTAs 
only receive messages, and not send them? Or do you mean that it is 
common for an MTA that is the target of a message transfer to offer a 
self-signed certificate when STARTTLS is employed?

“Therefore, MTAs that implement opportunistic TLS …” Again, it appears 
that you are applying the term “opportunistic TLS” when there is no 
precedent for doing so, i.e., no RFC that characterizes this behavior in 
this fashion.

“Not only is the STARTTLS advertisement is vulnerable to active attacks, 
…” -> “Not only is the STARTTLS advertisement vulnerable to active 
attacks, …”


Section 6

“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 always increased and never reduced.” This sentence 
is way too long, and it again seems to imply a total ordering on 
security service offerings.

“ … when maximal security is not applicable.” The phrase “maximal 
security” is not appropriate.

“Opportunistic security does not require reducing security policy to the 
lowest common denominator.” I disagree. OS is precisely an LCD 
mechanism, when considered on a pairwise peer basis. What I think you 
intend to say is that OS is not the LCD of all possible communicating 
peers.

“a-priori” -> “a priori” Additionally, the term “a priori” is not used 
anywhere else in this document, so why use it now? Do you mean “local 
security policy?” Security policies tend to be “a priori” i.e., they 
exist before an event that requires their application, so his term seems 
silly here.

“However, such a-priori policy can be counter-productive when it expects 
more than most peers can in fact deliver.” The IETF is not in a position 
to make this value judgment, e.g., for an enterprise. Also, I suspect 
you really mean that it’s a bad idea to mandate authenticated encrypted 
communication, or cleartext. Even that is not an obvious mistake; an 
enterprise might decide that it prefers cleartext traffic that it can 
inspect with a firewall and an IDS over encrypted communication that is 
unauthenticated and not subject to inspection.