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.