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

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 3 Aug 2014 15:13:43 +0000

On Wed, Jul 30, 2014 at 05:31:14PM +0000, Viktor Dukhovni wrote:

> > "OS strives to greatly broaden the use of encryption in IETF protocols,
> > to combat PM. To facilitate incremental deployment, OS operates in
> > a fashion that may result in a plaintext connection/session."
> 
> This is I think addressed by the "Encrypt by default" principle,
> but perhaps the below change helps to get the point across:
> 
> [...]

That change and a few more are in the -02 version:

    A new version has been submitted for draft-dukhovni-opportunistic-security:

    http://www.ietf.org/internet-drafts/draft-dukhovni-opportunistic-security-02.txt

    Diff from previous version:

    http://www.ietf.org/rfcdiff?url2=draft-dukhovni-opportunistic-security-02

Summary of changes:

    - Replaced undefined "strong protection" with "protection
      against both passive and active attacks".

    - Moved Terminology section up between the Introduction and the Design
      Principles (body) section.

    - More references.

    - Split some run-on sentences.

If anyone feels strongly that some of the original text was better,
please speak up...

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 Aug 2014 18:14:19 +0000

On Tue, Aug 05, 2014 at 11:43:02AM -0400, Stephen Kent wrote:

> The abstract uses the phrase "the established approach" to refer to
> employing protection against passive and active attacks, or no protection at
> all. Since opportunistic security (OS) is a term being defined for use in
> IETF standards, a reader might interpret the phase in quotes as referring to
> our standards, vs. deployment. While it is true that our security standards
> generally try to address both active and passive attacks, offering no
> protection at all is not a goal of these standards. The author should
> rephrase the text to clarify whether he is discussing standards or
> deployment.

In the abstract, I think it is not essential to distinguish between
goals and consequences.  The abstract is not blaming anyone, and we
do not need to apportion blame.  One way or another, at present, the
situation is as described.  I am discussing the present state of the
Internet, which results from a combination of standards and deployment,
and it is not clear why additional precision is required here.

> *Section 1*
> 
> Despite the fact that the abstract says the memo defines OS, the intro does
> not do so. A number of others have made this comment, both during the SAAG
> discussion of the document and during IETF last call, but the author has
> repeatedly ignored these comments. I suggest a definition of OS should
> appear within this section.

Since the document's goal is to define opportunistic security,
rather than use such a definition to do something else, I felt it
appropriate to offer motivating material in the Introduction, and
the definition in the body of the draft.  There seemed to be
significant feedback supporting the document as-is.

> The text says:
> 
> Since protection against active attacks relies on authentication, which at
> Internet scale is not universally available, while communications traffic
> was sometimes strongly protected, more typically it was not protected at
> all.
> 
> This statement is in the past tense, but the situation described is present
> tense. The use of the past tense here may confuse readers, causing them to
> believe that the problem described is in the past.

The tense mismatch should probably be fixed at the next opportunity to
revise the document, thanks.

> More importantly, the
> phrase "at Internet scale" is not defined anywhere in the document, yet it
> is a recurring theme in the document.

I don't think anyone is likely to be confused about what "Internet-scale"
means.  Nor is it essential that their interpretation of the phrase
match mine.

> The text later says:
> 
> ... with encrypted transmission accessible to most if not all peers, and
> protection against active attacks still available where required by policy
> or opportunistically negotiated.
> 
> Our current security protocols offer protection against active attacks
> "where required by policy" (e.g., IPsec) so this text is misleading, again.

The above quote leaves out essential context:

   Indiscriminate collection of communications traffic would be
   substantially less attractive if security protocols were designed
   to operate at a range of protection levels; with encrypted
   transmission accessible to most if not all peers, and protection
   against active attacks still available where required by policy
   or opportunistically negotiated.

In this context, the discussion of designs that operate at a *range* of
protection levels, with encryption ubiquitous and stronger protection
used where appropriate, thus a *range* of protection levels.

> And the term "opportunistically negotiated" is not defined, so it's use here
> adds to the confusion.

When protection against active attacks is not unconditional policy,
a party that strives to maximize security might "discover" (say
via presence of DANE TLSA RRs) that its peers can in fact be
authenticated, and thus employ the appropriate measures to thwart
active attacks.  This is an instance of opportunistic security that
goes beyond unauthenticated encryption.  Likely the below would
be an improvement:

   Indiscriminate collection of communications traffic would be
   substantially less attractive if security protocols were designed
   to operate at a range of protection levels; with encrypted
   transmission accessible to most if not all peers, and protection
   against active attacks still employed where unconditionally required
   by policy or else discovered to be possible with a given peer.

> The next paragraph refers to key management, again at "Internet scale"
> without definition or explanation. I'm pretty sure the author intends to
> refer to "authenticated" key management, at a specific (but unstated)
> granularity of authentication.

The ambiguity of "Key Management" has already been discussed
separately.  I think the text is sufficient as-is.  Overly precise
definitions require more ink on side-issues which distract from the
main goal of the document.

> The bottom line is that a primary
> motivation for OS is a desire to remove barriers to the use of encryption,

More strongly:

    * Yes at least encrypt when possible, but more generally,
    * Avoid needlessly weak options, and finally,
    * Strive for stronger security than just unauthenticated encryption,
      with any peer for which this is possible.

Do no forget that during the saag discussion that preceded this
draft, this was one of the main differences between our views, and
that I do not subscribe to the view that opportunistic security is
a narrow response to PM or that it should be limited to promoting
just unauthenticated encryption.

> and removing the need for authentication based on certificates is a good way
> to do this.

Not "removing", rather "not requiring".  We lower the floor,
but not the ceiling of the range of acceptable protections.

> But, this simple statement appears nowhere in this document.
> (DANE is cited later in this paragraph, but is dismissed because DNSSEC is
> not yet widely deployed. This is an accurate statement, but the say it is
> presented fails to convey the fundamental issues at play here.)

That's because the simple statement in question over-emphasizes lowering
the floor, and leaves the treatment of the ceiling unaddressed.   Instead
the draft's design principles are:

    * Interoperate to maximize deployment.
    * Maximize security peer by peer.
    * Encrypt by default.
    * No misrepresentation of security.

The second and third of these both explain that unauthenticated
encryption may well be the best available, and should be employed
when that is the case.

> The second paragraph in this section says:
> 
> The PKIX ([RFC5280]) key management model, which is based on broadly trusted
> public certification authorities (CAs), introduces costs that not all peers
> are willing to bear.
> 
> This is another example of inaccurate terminology that engenders confusion.
> I believe the author meant to refer to the Web PKI CA model (currently being
> documented in the WPKOPS WG), not to RFC 5280. Subsequent references to PKIX
> should be removed whenever they are not specifically tied to PKIX RFCs.

I am not alone in conflating the PKIX standards with their deployed
infrastructure.  Here again higher precision is I think not essential,
however we can avoid the problem cheaply enough:

   Encryption is easy, but key management is difficult.  Key
   management at Internet scale remains an incompletely solved
   problem.  The Web PKI key management model, which is based on
   broadly trusted public certification authorities (CAs), introduces
   costs that not all peers are willing to bear.  Web PKI public
   CAs are not sufficient to secure communications when the peer
   reference identity ([RFC6125]) is obtained indirectly over an
   insecure channel or communicating parties don't agree on a
   mutually trusted CA.

by replacing PKIX with "Web PKI" if that is better.

> The second paragraph of this section is trying to explain why extant means
> of key management systems (that are used in the Internet today), do not meet
> the author's goal of Internet scale key management. This is an example of
> the author avoiding the task of creating a definition, and instead relying
> on a set of examples to convey meaning. This is a bad strategy for an RFC.

The RFC is informational (even aspirational), and the introductory
text is informal motivating background.  Simplicity and accessibility
are prioritized over precision where precision imposes a cost on
the complexity of the document.  Perhaps the trade-off is not quite
right in some places, I welcome further feedback on that point.

> When authenticated communication is not possible, unauthenticated encryption
> is still substantially stronger than cleartext.
> 
> This would be better stated as:
> 
> When authenticated communication is not possible, unauthenticated encryption
> is preferable to cleartext transmission, relative to the concerns identified
> in [RFC7258].

This is fine by me.  Anyone else care to comment?

> The section ends with another observation about OS, without defining it:
> 
> In particular, opportunistic security encourages
> unauthenticated encryption when authentication is not an option.
> 
> This is a fine statement, that would be appropriate if only a definition of
> OS had preceded it.

The definition is in the body of the document, not the Introduction.

> *Section 3*
> 
> This section describes the author's design philosophy for OS, which would be
> appropriate IF OS had already need defined!

Ditto.

> The first goal says:
> 
> The primary goal of designs that feature opportunistic security is to be
> able to communicate with any reasonably configured peer.
> 
> I'm pretty sure that, given the vagueness of the phrase "reasonably
> configured peer:" that this is a goal of ALL IETF protocol standards.
> Perhaps the author meat to say that the goal is to maximize the ability of
> communicating peers to encrypt their traffic.

No, the point here is that opportunistic security is first and
foremost not a barrier to communicating.  Security takes a back
seat to moving the bits, provided none of the peers are misconfigured.

I can replace the word "reasonably" with "correctly" if that is less
confusing.  This is reiterated in the final sentence:

      Opportunistic security must not get in the way of the peers
      communicating if neither end is misconfigured.

What is different here from extant security protocols is the relative
priority of security and interoperability.  With OS interoperability
is generally prioritized over security, when all peers are properly
configured (possibly to offer only weak or no security services).

However, when peers are advertising (say via DANE) particular
security services, then OS is expected to demand that the peer
delivers on its promise (peers that promise, but don't deliver
are misconfigured).

> The text then says:
> 
> If many peers are only capable of cleartext, then it is acceptable to fall
> back to cleartext when encryption is not possible.
> 
> The term "many" here is misleading, unless this is referring primarily to
> some multicast scenario. Perhaps the author meant to say:

Many as in a non-negligible fraction of potential peers as with legacy
applications or infrastructure.  Not "many" as in multicast.

I'll change the text to:

    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.

if there are no objections to that.

> If a peer is not OS-capable, then an attempt to initiate unauthenticated,
> encryption communication may fail. In that case, plaintext communication is
> an acceptable outcome.

No, "OS-capable" is not a synonym for "Encryption-capable".  The
two are quite distinct.

> The text then says:
> 
> Interoperability must be possible without a need for the administrators of
> communicating systems to coordinate security settings.

This is borne of a decade of experience with exactly such bilateral
administrator interactions when setting up Web PKI secure channels
for SMTP.  The parties need to agree on which CAs to employ and
what names to validate at the peer domain's MX hosts.

> This is an important principle but the phrase "security settings" is a bit
> vague.

Does this really need elaboration?  The real point is that OS can
be deployed organically with any prior bilateral coordination
between the communicating parties.  Perhaps I should add the word
"prior":

    Interoperability must be possible without a prior need for the
    administrators of communicating systems to coordinate security
    settings.

> But, for TLS, is configuration of a mutually
> acceptable set of cryptographic algorithms a problem?

Yes, though not algorithms, rather trusted CAs and in the case of SMTP also
reference identities, since MX indirection makes the natural reference
identities insecure.

> I think this statement
> implies a mandatory to implement set of cryptographic algorithms that will
> be part of OS standards (else coordination will be needed to ensure
> overlap).

Yes, security protocol designs (OS or otherwise) need to interoperate
by default, but in the case of OS, the need to not get in the way of
communication is even more important, because security is secondary.

> Also, because this statement appears after the comment on
> authentication as a part of OS (if possible) it opens up the question of
> whether the security settings refer just to encryption or also to
> authentication. The text needs to be clearer on this.

Both, but most of the historical friction is with authentication.

> Applications employing opportunistic security need to be deployable at
> Internet scale, with each peer independently configured to meet its own
> security needs (within the practical bounds of the application protocol).
> 
> This wording suggests that use of OS is tied to an application. The TCPINC WG
> is working on what they view as an OS-motivated change to TCP that would not
> change the TCP API. An application would not be aware of encryption provided
> at that layer. Does the author intend to rule out a TCP-based OS approach?
> If not, the this text needs to be fixed, and the fix may not be easy.

I can drop the word "application" if that is an improvement.  There
is no intention to specify the protocol layer in question to be an
"application" protocol.

> The description of the first goal ends with this statement:
> 
> Opportunistic security must not get in the way of the peers communicating if
> neither end is misconfigured.
> 
> Surely we can state this intent more clearly, especially since what
> constitutes "misconfiguration" of a peer is not described anywhere in this
> document.

Misconfiguration here means promising (publishing or negotiating)
security services that are not available or don't work correctly.
How about:

    Opportunistic security must not get in the way of the peers
    communicating if neither end is misconfigured (i.e., neither
    publishes or negotiates security services that are not available
    or don't function correctly).

> The next goal states:
> 
> Subject to the above Internet-scale interoperability goal, opportunistic
> security strives to maximize security based on the capabilities of the peer
> (or peers).
> 
> The last three words are confusing. If we assume that communication involves
> at least two parties, then the capability of the peers trying to engage in
> communication is what matters.
> 
> Change "peer (or peers)" to "peers".

OK.

> The text then says:
> 
> For others, protection against active MiTM attacks may be an option.
> 
> An MiTM attack is ALWAYS active, so the wording here is redundant, and thus
> potentially confusing.

I thought it was reasonable emphasis, but I can drop MiTM here if preferred.

> The text then says:
> 
> Opportunistic security protocols may at times refuse to operate with peers
> for which higher security is expected, but for some reason not achieved.
> 
> There is a subtle issue at play here. It suggests that a protocol that is
> deemed an example of OS might require security services beyond
> confidentiality, e.g., authentication.

Yes, absolutely.  This is one of the main reasons why I wrote an
alternative draft.  Not only might this happen, I am recommending
that OS designs support authentication when possible (peer by peer).

> This seems to contradict the notion
> that an OS protocol require no coordination between administrators to enable
> communication, as stated in the first goal.

No contradiction at all.  Administrator Bob publishes DANE TLSA
RRs.  Administrator Alice independently (before or after Bob's
action) enables DANE TLSA support.  When both are done Alice's
traffic to Bob is authenticated and encrypted.

> Also, the phrase "at times" is
> misleading, unless it is intended to suggest that inconsistent behavior
> between the same set of peers, perhaps based on time of day, is OK.

At times, depends on the peers, and their published capabilities
at the times in question, not just the time of day.  However, it
may be better to say "in some cases".

> The description of this goal ends with the following text:
> 
> The conditions under which connections fail should generally be limited to
> operational errors at one or the other peer or an active attack, so that
> well-maintained systems rarely encounter problems in normal use of
> opportunistic security.
> 
> This sentence immediately follows the discussion of refusing to communicate
> when peers have differing requirements for security services. It is
> confusing, as it appears to ignore the scenario described in that sentence.

The two sentences go together.   Though active attack protection may block
communication, this should only happen when under attack, or when someone
botches their configuration.

> The next goal, encryption by default, begins with a strong statement, that
> is muddled by the choice of words:
> 
> An opportunistic security protocol MUST interoperably achieve at least
> unauthenticated encryption between peer systems that don't explicitly
> disable this capability.
> 
> Perhaps the author meant to say:
> 
> If two peer systems make use of the same OS protocol, they MUST, at a
> minimum, establish unauthenticated, encrypted communication when they
> connect, unless either has explicitly disabled this capability.

How is this different or better?

> Still, this simpler statement would conflict with the prior goal of allowing
> a system to reject unauthenticated communication with a peer, e.g., because
> it require use of additional security services. This needs to be reconciled
> with prior goals.

No conflict.  This discusses the floor case of *at least*
unauthenticated encryption.  The other text is about the
ceiling case of authenticated encryption when possible.

> The text then says:
> 
> Over time, as peer software is updated to support opportunistic security,
> only legacy systems or a minority of systems where encryption is disabled
> should be communicating in cleartext.
> 
> This seems to ignore the possibility that an active attack might prevent
> peers from enabling OS, even though they are both capable.

The word "should" allows for some exceptions, such as an occasional
active attack.

> The description of this goal ends with a mention of PFS. This is out of
> place in this definition. It should appear elsewhere.

Why is it wrong to encourage the encrypt by default goal to use
PFS? Your own draft made PFS a central goal of OS.  Must this be
a separate design principle?  Why?

> The next goal starts by using the undefined phrase "strong security".
> Several others have suggested that this phrase be removed from the I-D, and
> I concur. If the author wants to use the phrase, it must be defined in
> section 2.

It is largely gone, now in just two places, otherwise mostly replaced by
"protection against both passive and active attacks" or similar language.

Now in this paragraph we're talking about *representation* to users,
and here I see few better alternatives.  On UI issues "strategic
ambiguity" that gets the point across is important.

> The penultimate paragraph in this section finally offers a definition for
> OS. This needs to be moved near the beginning of this document.

I still prefer to defer the definition until after the Introductory
material that motivates its and the design principles that it summarizes
and which are a core part of the definition.

> The word
> "actual" should be elided from the second sentence of the definition. The
> definition ends with:

Given unequal security policy floors and security policy ceilings, actual
protection may differ from minimum required or maximum available.

> ... while allowing fallback to cleartext with peers that do not appear to be
> encryption capable.
> 
> Change "encryption capable" to OS-capable or "OS-enabled".

The peer may not be OS-capable, but may still support encryption.
The cleartext fallback is for lack of encryption support.

> The final paragraph in this section says:
> 
> When possible, opportunistic security SHOULD provide stronger security on a
> peer-by-peer basis.
> 
> This is an obvious attempt to make the definition of OS be very broad,

Not "obvious attempt", but rather clear and multiply stated goal of the
draft.  And as mentioned earlier a clear point of difference during the
saag discussion, and the key reason this draft exists.

> well beyond the primary goal cited earlier.

No, exactly as intended and stated.

> It also conflicts with the goal of
> not requiring coordinated security configuration between peers, another goal
> cited earlier.

No conflict.  See DANE Alice/Bob example above.

> The last sentence in the section appears
> to be the authors per peeve, and probably does not belong in this document.

It clearly illustrates much of what is wrong with the status quo
and how OS can make things better.  The blunder in question is
rather common, and even if the draft achieves nothing beyond
discouraging such blunders, that would progress.

> The use of "MUST" here is also questionable, as it is stated w/o explicit
> context. (The author did not say, for example, that this behavior in an
> OS-capable MTA violates the criteria established for OS.)

This blunder MUST be avoided in any MTA, OS or otherwise, but an
appreciation for the fact that the MTA in question is in fact
engaging in OS (by falling back from authenticated transmission),
and making a botch of it (by falling back to cleartext instead
of continuing the encrypted session) is helpful.

> *Section 4*
> 
> Again there is use of the phrase "strong security" which is problematic for
> the reasons cited above.

I think by this point it is understood what this means given all
the earlier text.  If necessary, it can be made more verbose as
in most of the other cases.

> *Section 6*
> 
> The references are not described as informative vs. normative.

The draft is informational, so I thought this was not essential.
If the separation is none-the-less important, that's an easy fix.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Aug 2014 16:04:35 -0500

>       with any peer for which this is possible.

Yes.

To be more specific OS must not preclude things like DANE that can be
opportunistic and provide strong authentication.

It's worth mentioning DNSSEC/DANE because a lot of concerns I've seen
stated about OS (indeed, that I myself have stated) go away when one
considers the use of DNSSEC for learning how to authenticate a service.

(Or, perhaps, such concerns get transmutated into concerns about the
lack of compromised/adversarial parent zone MITM detection in DNSSEC.)

> just unauthenticated encryption.

More than that: why should OS stop there?

> but not the ceiling of the range of acceptable protections.

More +1.

And, really, +1 to the rest of Viktor's response.

Nico
--

---

From: Henry B Hotz <[email-masked]>
Date: Tue, 5 Aug 2014 16:41:27 -0700

+1

Can we do clearer text with this as a starting point?

On Jul 28, 2014, at 3:04 PM, ianG <[email-masked]> wrote:

> Instead we want to change the paradigm.  We want to lift the bar to the
> height that the jumper can leap, not filter the jumper by the height of
> the bar, set arbitrarily high.

Conceptually, we may be doing nothing more than pre-empting the existing/default mechanism selection order for a protocol.

Personal email.  [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 00:17:38 +0000

> Can we do clearer text with this as a starting point?

The draft already says this with different words, and (to stretch
the analogy) with additional emphasis that the bar should be set
higher when the jumper assures everyone he can clear that height.

> > the bar, set arbitrarily high.

We are prioritizing success over absolute security, but trying to
get as much security as possible while leaving room for non-trivial
minimum standards where appropriate (local policy or securely
published peer capabilities, ...).

So I do not disagree with the substance of above alternative
language, but don't see a need for a restart to say the same thing.

> Conceptually, we may be doing nothing more than pre-empting the
> existing/default mechanism selection order for a protocol.

There's likely to be a lot more going on than that.  New DNSSEC
lookups, outcome dependent initial policy selection, then further
adaptation based on direct communication with the peer, ...

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 05 Aug 2014 18:04:52 -0700

> opportunistic and provide strong authentication.

A reference like that has been made several times, and I don't
understand it.

DANE provides authenticated keys.   Given the reliance on DNSSec, the
authentication is substantial.

So while use of DANE has some interesting differences from using a
classic CA-based key, using it as a basis for encryption ought to
qualify as fairly straightforward authenticated encryption.

That doesn't seem at all 'opportunistic' to me.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 01:27:07 +0000

> That doesn't seem at all 'opportunistic' to me.

It is when authentication is then used *only* with peers that
publish TLSA RRs and not with peers that don't.  You get opportunistic
authentication, which is employed when possible (or at least promised
by the peer system's DNS administrator) and not otherwise.

See:

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-11

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 05 Aug 2014 19:26:10 -0700

On 8/5/2014 6:27 PM, Viktor Dukhovni wrote:
> publish TLSA RRs and not with peers that don't. 

My point was/is that reliance on DNSSec means that there is an
INDEPENDENT authentication hierarchy.

Taking a look at the entire 'system' that DANE is part of, the
authentication is NOT only between peers.

Use DANE without DNSSec, and calling it opportunistic probably makes
sense.  Using it with DNSSec and it doesn't.

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 02:55:36 +0000

> sense.  Using it with DNSSec and it doesn't.

We'll have to disagree on this.  From the perspective of an MTA
delivering mail to all possible domains, its security policy is
opportunistic, doing the best it can with each destination.  When
DANE support is enabled, it becomes possible to authenticate some
peers, this is still opportunistic security, with the bar set to
the right level for each peer, and mail delivery in cleartext should
a previously DANE-enabled domain withdraw its TLSA RRs, ...

If opportunistic security is mutually exclusive with protection
against active attacks, it is a step sideways not forward.  I am
proposing to make encryption more ubiquitous *without* lowering
the achievable security.  I believe I have strong support for this
in this forum (both saag and ietf general).

For SMTP, the resulting protocol is "opportunistic DANE TLS", which
is an example of an "opportunistic security" design.

You're bringing baggage to this discussion in the form of assumptions
about what opportunistic security means.  The draft proposes a more
ambitious definition.

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 05 Aug 2014 19:58:51 -0700

> a previously DANE-enabled domain withdraw its TLSA RRs, ...

I've read the above several times but do not really understand what it
means.

Also the issue is not whether we agree  but what the technical details
are that qualify this as "opportunistic" rather than authenticated
encryption that happens to use DNSSec as a form of CA.

For a term to be useful, there must be a clear and consistent way of
applying it.

The exchange we are having right now makes the meaning -- and therefore
utility -- of opportunisitc (foo) -- questionable.  It is simply not
useful to have such a basic assessment reduce to "we'll have to disagree"...

d/

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 03:16:22 +0000

> I've read the above several times but do not really understand what it

DANE with authentication can be either opportunistic (enabled via
discovery on a peer by peer basis) or mandatory (required by local
policy, URI scheme, ...).  Postfix for example supports both
opportunistic and mandatory DANE TLS:

    http://www.postfix.org/TLS_README.html#client_tls_dane

> encryption that happens to use DNSSec as a form of CA.

The term "opportunistic security" is new, and can be defined, within
reason, as we see fit.  The proposed definition includes authentication
that is based on published peer capabilities (discovered authentication
support) under the umbrella term of opportunistic security, and rightly so.

> For a term to be useful, there must be a clear and consistent way of

Opportunistic peers are willing to set the bar at various levels
depending on peer capabilities.  They don't operate at a single
fixed (all or nothing) security policy.  Publication of TLSA RRs
(for example) is one way of signalling a higher bar for a particular
peer, STARTTLS is another (though not as high, and not immune to
active attack).

> utility -- of opportunistic (foo) -- questionable.  It is simply not

Perhaps I said that wrong, I did not mean to shut down the
conversation, however, I am more than willing to clarify my stance
on a definition that ranges from cleartext to authenticated encrypted
comms that resist both passive and active attacks.  I think we are
well past the point where I need to consider substantively narrower
definitions.  We can certainly debate the clarity and wording of
the text.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 03:22:34 +0000

On Tue, Aug 05, 2014 at 11:14:27PM -0400, Scott Kitterman wrote:

> It seems to me that all it means is that the MTA is taking the opportunity
> to make the most secure connection it can on a peer basis.  Sometimes that's
> going to be a full DANE negotiated session protected by DNSSEC.  Other
> times it's not.  I think the major point of opportunistic isn't how good
> the resulting security is, but the idea of taking advantage of the best
> option available on a per peer basis rather than treating it as all or
> nothing.

Exactly.

Opportunistic security operates at a variable protection level,
not fixed by a-priori policy.  Rather, it is tuned to the apparent
capabilities of the peer.  Some appearances are not downgrade
resistant (enabling active downgrade attacks), and some don't
reflect reality (breaking interoperability when the peer promises
more than it can deliver).

-- 	
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 04:28:43 +0000

Proposed wording updates to address some of Steve Kent's comments
(plus one or two minor other fixes).  Note, this is not a major
rewrite or restructuring.  Just nit fixes.

diff --git a/draft-dukhovni-opportunistic-security b/draft-dukhovni-opportunistic-security
index ff29c55..c3ff1a3 100644
--- a/draft-dukhovni-opportunistic-security
+++ b/draft-dukhovni-opportunistic-security
@@ -55,7 +55,7 @@
      comprehensive protection against both passive and active attacks
-     for peers capable and motivated to absorb the associated costs.
+     for peers able and motivated to absorb the associated costs.
      Since protection against active attacks relies on authentication,
      which at Internet scale is not universally available, while
-     communications traffic was sometimes strongly protected, more
-     typically it was not protected at all.  The fact that most
+     communications traffic is sometimes strongly protected, more
+     typically it is not protected at all.  The fact that most
      traffic is unprotected facilitates nation-state pervasive
@@ -67,4 +67,4 @@
      accessible to most if not all peers, and protection against
-     active attacks still available where required by policy or
-     opportunistically negotiated.
+     active attacks still employed where unconditionally required
+     by policy or else discovered to be possible with a given peer.
    </t>
@@ -74,10 +74,10 @@
      management at Internet scale remains an incompletely solved
-     problem.  The PKIX (<xref target="RFC5280"/>) key management
+     problem.  The Web PKI key management
      model, which is based on broadly trusted public certification
      authorities (CAs), introduces costs that not all peers are
-     willing to bear.  PKIX is not sufficient to secure communications
+     willing to bear.  Web PKI public CAs are not sufficient to secure communications
      when the peer reference identity (<xref target="RFC6125"/>)
      is obtained indirectly over an insecure channel or communicating
-     parties don't agree on a mutually trusted CA.  DNSSEC (<xref
-     target="RFC4033"/>) is not at this time sufficiently widely
+     parties don't agree on a mutually trusted CA.  At this time,
+     DNSSEC (<xref target="RFC4033"/>) is not sufficiently widely
      adopted to make DANE (<xref target="RFC6698"/>) a viable
@@ -93,3 +93,3 @@
      When protocols only offer the options of authenticated secure
-     channels or else cleartext, most traffic is sent in the clear.
+     channels or cleartext, most traffic is sent in the clear.
      Therefore, in order to make encryption more ubiquitous,
@@ -97,5 +97,6 @@
      communication is not possible, unauthenticated encryption is
-     still substantially stronger than cleartext.  Opportunistic
+     preferable to cleartext transmission, in that it addresses
+     pervasive monitoring <xref target="RFC7258">.  Opportunistic
      security encourages peers to employ as much security as possible,
-     without falling back to unnecessarily weak options.  In
+     without falling back on unnecessarily weak options.  In
      particular, opportunistic security encourages unauthenticated
@@ -159,4 +160,5 @@
      goal of designs that feature opportunistic security is to be
-     able to communicate with any reasonably configured peer.  If
-     many peers are only capable of cleartext, then it is acceptable
+     able to communicate with any correctly configured peer.  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.  If
@@ -164,10 +166,12 @@
      acceptable to authenticate only those peers and not the rest.
-     Interoperability must be possible without a need for the
+     Interoperability must be possible without a prior need for the
      administrators of communicating systems to coordinate security
-     settings.  Applications employing opportunistic security need
+     policy.  Applications employing opportunistic security need
      to be deployable at Internet scale, with each peer independently
      configured to meet its own security needs (within the practical
-     bounds of the application protocol).  Opportunistic security
+     bounds of the employed protocol).  Opportunistic security
      must not get in the way of the peers communicating if neither
-     end is misconfigured.  </t>
+     end is misconfigured (i.e., neither publishes or negotiates
+     security services that are not available or don't function
+     correctly).  </t>
 
@@ -176,7 +180,7 @@
      security strives to maximize security based on the capabilities
-     of the peer (or peers).  For some opportunistic security
+     of the peers.  For some opportunistic security
      protocols the maximal protection possible may be just
      unauthenticated encryption to address passive monitoring.  For
-     others, protection against active MiTM attacks may be an option.
-     Opportunistic security protocols may at times refuse to operate
+     others, protection against active attacks may be an option.
+     Opportunistic security protocols may, when applicable, refuse to communicate
      with peers for which higher security is expected, but for some
@@ -192,3 +196,3 @@
      this capability.  To facilitate incremental deployment,
-     opportuistic security protocols may tolerate cleartext connections
+     opportunistic security protocols may tolerate cleartext connections
      or sessions with peers that don't support encryption.  Over
@@ -213,6 +217,6 @@
      encompasses protocol designs that remove barriers to the
-     widespread use of encryption in the Internet.  The actual
+     widespread use of encryption on the Internet.  The actual
      protection provided by opportunistic security depends on the
-     capabilities of the communicating peers; opportunistic security
-     MUST attempt to at least encrypt network traffic, while allowing
+     capabilities of the communicating peers.  Opportunistic security
+     MUST at least aim to encrypt network traffic, while allowing
      fallback to cleartext with peers that do not appear to be
@@ -228,3 +232,3 @@
      MAY be a reason to abort a connection to a peer that is expected
-     to be authenticated, it MUST NOT instead lead to communication
+     to be authenticated, it MUST NOT then lead to communication
      in cleartext when encryption is an option.  Some Message

-- 
	Viktor.

---

From: ianG <[email-masked]>
Date: Wed, 06 Aug 2014 11:08:22 +0100

> That doesn't seem at all 'opportunistic' to me.

Opportunistic refers to the choice made by the protocol on the day, not
the strength of the outcome.

iang

---

From: ianG <[email-masked]>
Date: Wed, 06 Aug 2014 11:20:09 +0100

s/reasonably/correctly/good.

The causality of "many peers" I don't understand.  I would have thought
it should say

        If a peer is only capable of cleartext, then it is acceptable
        to fall back to cleartext when encryption is not possible.  If

Why are we making the fallback conditional on multiple peers?

iang

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 13:41:50 +0000

> Why are we making the fallback conditional on multiple peers?

We are not.  Rather the idea was that as deployed systems that
speak a legacy protocol migrate from just cleartext to OS, once
only a negligibl minority support only cleartext, the bar could be
raised to "at least encrypt" leaving the negligible minority in the
dust.  In such situations it will still be possible to apply local
policy overrides to communicate with the laggards, but otherwise,
everyone will refuse to fail to encrypt.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 14:30:20 +0000

On Wed, Aug 06, 2014 at 06:43:56AM -0700, Dave Crocker wrote:

> All of the above means that this term is for use only by security
> experts, since it makes the term unwieldy for use by anyone else.

The draft's core audience is designers of security protocols, and
implementors of protocol toolkits.  They'll make the technology
available to users, but users also need a vocabulary to understand
what they are getting.

Postfix has had support for "opportunistic TLS" since at leeast
2006.  There has been little user confusion.  In January 2014 we
added "opportunistic DANE TLS", and still no user confusion.

Perhaps users will understand the concept more easily in the context
of their particular application and its documentation.

> I'll also note that the draft says nothing like the above.  That should
> bother you, and everyone else.

More accurately, the draft leaves some things unsaid, that can only
be made concrete in a particular protocol that makes the appropriate
choices.

For example, there is a common myth that in client-server protocols
authentication of the server by the client and authentication of
the client by the server have essentially similar semantics.  This
misconception is especially common with regard to TLS, where I've
observed that many users believe that if authentication of the server
by client can protect against active attacks, then surely so must
authentication of the client by the server even absent the client
authenticating the server.  This is false.  Sloppy reasoning about
the security properties of protocols leads to nonsense.

So I focused on what could be said about opportunistic security,
and left out what could not be said.  Perhaps some disclaimers
belong in the text.  Perhaps the text can be made clearer, I wonder
what it is specifically that makes the text clear to Scott K., but
fails to get the idea across to you.  If you could highlight where
I've lost you, perhaps the text can be improved.

> Worse, the different responses from folks who have been active in the
> discussion and who try to explain the term show different
> understandings/meanings.  Still.  After all this time and discussion.

Different words, same tune.

> The only "end-to-end" protection function that has been seriously
> discussed is confidentiality through encryption.  All other protections
> really have no concrete basis in practice or even in discussion focus,
> within the context of this 'opportunistic' framework.

This is clearly not the case.  Multiple people have expressed some
concern that even the draft's definition of OS makes it too easy
to weasel out, implement only opportunistic unauthenticated encryption
and stop there, ignoring active attacks entirely.  They and I want
more than that, and in fact we have a soon to be published and
already deployed (small number of early adopters so far, gated by
currently low deployment of DNSSEC) protocol "SMTP opportunistic
DANE TLS", that does more.

> Of the various terms that were originally suggested, the one that has
> the simplext, clearest and most useful meaning is "best effort".
> Opportunistic is clearly a much sexier word, but the continuing lack of
> coherent community understanding of its meaning makes it problematic. At
> the least, it means that it will not be particularly intuitive for the
> rest of the world.

Perhaps you're projecting your own surprise at the meaning of the
term onto the community at large.  Yes, I would like the draft to
be accessible to all, and we may yet need to revise it to be more
clear, but I don't think there's a broad failure by the community
to understand the term.  It seems that most people are able to
express the same ideas in their words and still end-up saying the
same thing.  Ideally, we can increase the size of that purported
"majority".

> In contrast, best effort is a commonly used term and it means exactly
> what is at issue here, as the common thread to everyone's attempted
> explanations.
> 
> To the extent that folks really can't abide having the term be focused
> specifically  on encryption, then focus on the functional component that
> is also common to everyone's explanations:  key management.  How the key
> is administered is the essence of what the current topic is focused on.
> 
>    Best Effort Key Management

If "best effort" is the right prefix, it is still "best effort
security", not "key management".  But "best effort" misses the
point, and we've already chosen a term by rough consensus, and any
problems with the draft are with its wording, not the term chosen
to be defined.

If we keep revisiting every decision, we'll never be done.  I would
like to suggest strongly that we let "OS" stand, and focus on the
clarity of the definition instead.

-- 
	Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 06 Aug 2014 07:49:13 -0700

On 8/6/2014 7:30 AM, Viktor Dukhovni wrote:
> implementors of protocol toolkits. 

In terms of legitimate need for a term and likely use of it, I suggest
that it is seriously misguided to believe that this term will be used
only by that extremely restricted community.

 They'll make the technology

Exactly.

Your earlier recitation of TLS as an example of why saying 'security' is
ok is indicative of the problem here.  The severely limited real-world
uses of TLS is widely misunderstood amongst users.  They hear the word
security and believe all sorts of protections are in force that rarely
-- or never -- are.  Even in IETF discussions, the fact that client
authentication is essentially never done is an example of the problems
caused by sloppy, vague terminology.

> be made concrete in a particular protocol that makes the appropriate

Viktor,

Stephen was providing a broad-based and conceptual description of the
term that covers a wide variety of uses.  The only place that's going to
happen is in this definition.

What will happen in specifications for particular protocols will be
about particular protocols.  They will not -- and must not --  be making
broad statements of the sort that Stephen made.

> Different words, same tune.

An unfortunate effect of small-group dynamics is that it's members can
develop a shared sense of things that is widely at variance with what th
rest of the world will see and understand.  The challenge, then, is to
treat publishable statements with skepticism and put effort into
considering how they will be seen by those not already familiar with the
language.

So I do understand that your view is what some of you have convinced
yourselves of.  However it is not what I'm seeing in the different
statements.

> and stop there, ignoring active attacks entirely. 

Forgive me but this response seems a non-sequitor to me.  I do not
understand how it is relevant to the concerns I've raised or suggestions
I've made.

> term onto the community at large.  

It's always self-comforting to choose an ad hominem counter-argument.
Please try to refrain from repeating that indulgence.

> Yes, I would like the draft to
> to understand the term. 

I do acknowledge that you are not seeing the problem I am asserting.

> problems with the draft are with its wording, not the term chosen

We have?  What consensus process was that?

This is an individual submission.  The repeated citation of previous
discussions in saag, as if they resolved issues, is a basic and serious
error in IETF process.

> If we keep revisiting every decision, we'll never be done. 

Casual dismissal of basic concerns might produce output, but it will be
problematic output.

d/

---

From: Stephen Kent <[email-masked]>
Date: Wed, 06 Aug 2014 11:42:17 -0400

Viktor,

Rather than deal with each of your responses to my comments individually,
I'll just provide some overall responses.

1. My comments on the abstract are not about blame, but about clarity in
writing. It is important to distinguish between standards and what is 
deployed,
especially because we can control only the former.

2. I have seen considerable feedback from various sources, including the 
GEN-ART
review, that does not suggest that the doc is fine "as-is."

3. I've rarely seen someone suggest that being more precise in terminology
is a bad thing. I think we owe it to readers of RFCs to be a clear as 
possible.
Clarity in writing, and concision, yield good docs. You seem to believe that
making a doc more precise makes it verbose. That is not a necessary outcome.

4. The term "collection" is generally defined as passive wiretapping, so 
encryption
suffices, irrespective of using other security services.

5. Yes, you are not alone in making an erroneous statement that conflates
PKIX standards and the Web PKI. However, that does not justify perpetuating
such errors in an RFC.

6. The definition of OS appears at the end of Section 3, after all of 
the background.
My comments argued that it appear sooner, which is not the same as 
saying that it needs
appear in the Intro, contrary to your complaints.

7. I called into question the phrase "reasonably configured peer." Your 
reply was
wordy and missed the point of my criticism.

8. You seem to have misunderstood why I found the term "many" to be 
confusing; changing it
to "non-negligible number" misses the point. The point is that the text 
is clearer is one
discusses a pair of peers trying to communicate. Also, I note that 
another person cited the
same problem; it's not just me!

9. The phrase "security settings" is vague, since it means different 
things in
different security protocol contexts. You later seem to acknowledge this 
when you observe
that TLS and SMTP security settings are different. Saying that OS can be 
deployed "organically"
suggests spreading around a lot of manure :-).

10. yes, do drop the term "application" when there is no intent to 
restrict solutions to
be app-specific.

11. Your effort to clarify what you mean by "misconfigured" was a 
revelation to me.
I did not get any sense of that meaning from the text.

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 think
this is an example of trying to make the term OS all encompassing.

13. Your attempts to reconcile what you refer to as "no ceiling" for OS 
and the
simple notion of unauthenticated encryption between OS-capable peers 
yields text
that is confusing, borderline contradictory. I noted several examples. 
Your replies
either insist there is no problem (and that the meaning is clear) or 
offer additional
text that is marginally better.

14. I said that the suggestion to use PFS was out of place in the goal 
where it
appeared. Your reply missed the point entirely.

15. I observed that the closing MTA example is inappropriate in a doc of 
this sort.
I should also have noted that the use of MUST here makes no sense in an 
informational
RFC defining terminology. Your reply suggests that you again missed the 
point.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 15:44:30 +0000

On Wed, Aug 06, 2014 at 07:49:13AM -0700, Dave Crocker wrote:

> >> the simplest, clearest and most useful meaning is "best effort".

Apologies, no ad-hominem attack intended.  I am trying to say that
it seems that the problems with the text are far from universal, but
if it fails to reach some people, perhaps we can do better, without
losing yet a different group of people...

Is the problem at all partly the possibility that you're bringing
a prior conception of what "opportunistic security" might mean to
the table?  Or is it that I am simply failing to explain the term?

Either way, now that you've seen various formulations of the idea
of a range of security levels, dynamically tailored to the purported
capabilities of the peer, what would you like the draft to do
differently?  Would all become light if I in fact added something
like this at the beginning of the introduction:

    Opportunistic security: A security protocol in which the ability
    to communicate is prioritized over absolute security.  This is
    achieved by replacing a fixed all or nothing security level
    expected of all peers with a range of security levels, such
    that the minimum acceptable level is tailored to the purported
    capabilities of the particular peer system.  Provided the
    communicating peers are not misconfigured to promise greater
    capabilities than they can correctly deliver, security does
    not get in the way of the ability to communicate.

    While, in order to address Pervasive Monitoring (PM [RFC7258]),
    opportunistic security aims to always achieve at least
    unauthenticated encryption, with legacy protocols or infrastructure
    it may be acceptable to fall back to cleartext with peers that
    are not encryption capable.

    Opportunistic security protocol designs are strongly encouraged
    to strive for more than just unauthenticated encryption.
    Designs should, if possible, enable peers to advertise (in a
    downgrade-resistant manner) support for authenticated communication
    to thwart active attacks.  When peers advertise such capabilities,
    it is expected that opportunistic security protocols will
    require greater security with those peers, and will refuse to
    communicate when the expected security level is not achieved.

-- 
	Viktor.

---

From: Rene Struik <[email-masked]>
Date: Wed, 06 Aug 2014 11:55:53 -0400

Dear colleagues:

I had another look at the (now updated) draft: 
draft-dukhovni-opportunistic-security-02.

Some more comments:

(a) The term "perfect forward secrecy" (Section 2) is not defined 
properly. Suggested changes: (i) change "that are derived" towards "that 
were previously derived"; (ii) remove "or distributed using". This also 
In fact, it may be best to just use the terminology definition of RFC 
4949 (For a key agreement protocol, the property that compromises 
long-term keying material does not compromise session keys that were 
previously derived from the long-term material.)

(b) The verbiage in the draft should make it more clear that 
opportunistic encryption will not jeopardize those entities that wish to 
only set-up secure and authentic channels, by policy. Essentially, there 
are three channel categories: (i) unsecured channel; (ii) channel 
providing confidentiality only; (iii) channel providing confidentiality 
and authenticity. While opportunistic security aims to enable a shift 
from (i) to (ii), it may also cause a shift from (iii) to (ii) -- see 
also the concerns I expressed July 11, 2014, 10:08am EDT [copied at end 
of this email].
-- There should be language in draft 02 that expresses this concern 
(which would be a security loss), e.g., with the security consideration 
section.
-- The current language re "design for interoperability" leaves 
ambiguity as to whether one cares about channels where one would like to 
enforce, by security policy, channel category (iii). Unless I understand 
this sentence wrong, the phrase "if authentication is only possible for 
some peers, then it is acceptable to authenticate only those peers and 
not the rest" seems to suggest lowest-common denominator security 
policies (opening the door to downgrade attacks, denial of service 
attacks, etc.). Currently, the phrase "interoperability must be possible 
without a need for the administrators of communicating systems to 
coordinate security settings" suggests that a system where one 
authenticates entities via certificate verification of a CA root key 
acceptable to the receiving end of a communicated cert would be taboo 
(thereby, killing off a specific way of realizing (iii) using certs); 
similarly, this seems to preclude communication settings where either 
end may have a white list of raw public keys. A much more useful 
approach seems to be to curtail user/device privileges depending on 
whether one ends up with channel category (i), (ii), or (iii), where 
policies may explicitly include blocking communications if channel 
category (iii) is not achieved, but may also allow specific message 
types to pass through if one only has an unsecured channel (category 
(i)) at hand.
-- What about the following change at end of the section on 
"interoperability" (first para of Section 3): replace by "Opportunistic 
security must not get in the way of the peers communicating if neither 
end is misconfigured and neither end precludes communicating with the 
other end by virtue of its own security policy". Note: Right now, the 
term "misconfigured" is not really defined, but the suggestion from the 
entire draft is that one should allow channel type (ii), no matter what. 
This requires a finer line: ultimately, security policies should 
determine this. From that point of view, the email response below is 
somewhat scary:

    [excerpt of email Viktor Dukhovni, Wed Aug 6, 2014, 9:41am EDT]
    Why are we making the fallback conditional on multiple peers?

    We are not.  Rather the idea was that as deployed systems that speak a legacy protocol migrate from just cleartext to OS, once only a negligibl minority support only cleartext, the bar could be raised to "at least encrypt" leaving the negligible minority in the dust.  In such situations it will still be possible to apply local policy overrides to communicate with the laggards, but otherwise, everyone will refuse to fail to encrypt.

(c) With the "maximize security peer by peer" para (Section 3), the 
phrase "opportunistic security may at times refuse to operate with peers 
for which higher security is expected, but for some reason not achieved" 
is somewhat cryptic. If the intention is to capture that ultimately it 
is up to each peer to enforce its own security policy as to channel 
category (i), (ii),or (iii), {which I do hope} this could be made more 
clear. Right now, this para has highly ambiguous language such as "the 
conditions under which connections fail should generally be limited to 
operational error t one or the other peer or an active attack, so that 
well-maintained systems rarely encounter problems in normal use of 
opportunistic security", which - to me - spells trouble since suggesting 
sloppy security policy enforcement (or, does operational error include a 
security policy mismatch?).

(d) It may be good to articulate that, e.g., a security handshake that 
by itself only provides for channel type (ii) may provide some 
additional information to another process that allows elevating this to 
channel type (iii). An example hereof would be TLS with server 
authentication, where one does not really verify the cert as part of 
TLS, but simply sets up an anonymous channel (e.g., using ephemeral 
Diffie-Hellman) as part of TLS, and has another process, e.g., at the 
higher layer, verifying authenticity info (e.g., by verifying the 
certificate chain). This seems to be in line of what some people (e.g., 
Nico Willems) have suggested re including some language re interface 
aspects (DANE, etc.).

Best regards, Rene

On 7/11/2014 10:08 AM, Rene Struik wrote:
> Dear colleagues:
>
> One of my concerns with Optimistic Encryption is that it may have as 
> side effect that it may be tempting for implementers to move from 
> secure and authentic channel set-up to just encrypted (but 
> unauthenticated) channels, since it - how convenient - removes the 
> need for any admin... I can already see arguments about why one should 
> spend money on authentication support if the attack window is so 
> small, etc., akin to discussions I have seen rampant in industrial 
> control settings, where some people have argued that communicating 
> symmetric keys wirelessly over the air for bootstrapping is okay, 
> "since nobody would listen in anyway". I think this is a major risk.
>
> If this "substitution risk" would materialize, we might actually lower 
> the bar  and set back the clock nearly 40 years, since realizing 
> encrypted, unauthenticated  channels already proposed in the 1976 
> paper on "New Directions in Cryptography".
>
> Shouldn't one at least add some more extensive verbiage about security 
> policy enforcement? After all, reason to do authentication would be to 
> have some evidence on the party one is communicating with and can then 
> arrive at more fine-grained conclusions as to authorization and scope 
> hereof, based on that evidence.
>
> The the day-to-day risk for security architectures may be increase of 
> admin cost if there would ever be a lifecycle event after initial 
> provisioning and where lack of authentication may really hurt.
>
> Rene
>
> On 7/8/2014 11:34 AM, Stephen Farrell wrote:
>> IETF LC started as promised.
>>
>> Cheers,
>> S.
>>
>>
>> -------- Original Message --------
>> Subject: Last Call: <draft-dukhovni-opportunistic-security-01.txt>
>> (Opportunistic Security: some protection most of the time) to
>> Informational RFC
>> Date: Tue, 08 Jul 2014 08:09:40 -0700
>> From: The IESG <[email-masked]>
>> Reply-To: [email-masked]
>> To: IETF-Announce <[email-masked]>
>>
>>
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>> - 'Opportunistic Security: some protection most of the time'
>>    <draft-dukhovni-opportunistic-security-01.txt> as Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2014-08-05. Exceptionally, comments 
>> may be
>> sent to [email-masked] instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>
>>     This memo defines the term "opportunistic security".  In contrast to
>>     the established approach of delivering strong protection some of the
>>     time, opportunistic security strives to deliver at least some
>>     protection most of the time.  The primary goal is therefore broad
>>     interoperability, with security policy tailored to the capabilities
>>     of peer systems.
>>
>>
>>
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/
>>
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/ballot/ 
>>
>>
>>
>> No IPR declarations have been submitted directly on this I-D.
>>
>> This document and a predecessor have been the subject of discussion
>> on the saag mailing list. [1]
>>
>>      [1] 
>> https://www.ietf.org/mail-archive/web/saag/current/maillist.html
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> saag mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/saag
>
>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 16:36:47 +0000

On Wed, Aug 06, 2014 at 11:55:53AM -0400, Rene Struik wrote:

> (b) The verbiage in the draft should make it more clear that opportunistic
> encryption will not jeopardize those entities that wish to only set-up
> secure and authentic channels, by policy.

Where local or other policy (e.g. semantics of HTTPS URIs) requires
both active and passive protection, opportunistic security is not
in scope.

However, it is worth quoting from the draft that the effect of the
high bar set by current designs is that most traffic is not protected
at all.  Opportunistic security aims to provide some (in fact as
much as possible) security (be it just channel protection) to the
huddled masses.  Ideally, often essentially as strong as the
statically defined comprehensive protections in extant protocols,
but now on a peer by peer basis, enabling "incremental adoption".
[ Steve Kent: that's what I meant to say by "organic", sorry about the
inadvertent associations with manure, the word "organic" does not
appear in the draft, only in my email comments, the right word is
"incremental". ]

> Essentially, there are three
> channel categories: (i) unsecured channel; (ii) channel providing
> confidentiality only; (iii) channel providing confidentiality and
> authenticity.

Yes, ignoring some sub-categories, essentially three possible
*outcomes*.  However, there are also multiple possible prior
policies that lead to one of the afore-mentioned outcomes:

    * Channel security off
    * Channel security fixed to only encrypt
    * Channel security fixed to encrypt and authenticate
    * Channel security adaptive to peer capabilities finding the *maximum*
      possible with a given peer.

The last of these is essentially opportunistic security.  In real
applications, the prior policy might also be peer-dependent.  So
that for example one might default to OS for a generic peer, but
set a high bar for some peers statically (potentially requiring
some bilateral policy coordination with administrators of the peer
system).

> While opportunistic security aims to enable a shift from (i)
> to (ii),

or for some combinations of peers (i) to (iii).

> it may also cause a shift from (iii) to (ii)

OS does not trump local or protocol requirements.  It aims to secure
to the extent possible, the under-served population left out in the
cold by a binary choice between (i) and (iii).

If OS adoption leads to users abandoning protocols or configurations
that require (iii) in favour of more adaptive approaches, then
perhaps users did not want (iii) as much as security engineers and
protocol designers thought they did.

> -- There should be language in draft 02 that expresses this concern (which
> would be a security loss), e.g., with the security consideration section.

OS itself does not degrade security.  That would only happen if users choose
to disable prior policies that require active protection and replace these
with OS.  OS does not aim for users to do that, but if they do, it is not
clear that OS is doing the user a disservice.

> -- The current language re "design for interoperability" leaves ambiguity as
> to whether one cares about channels where one would like to enforce, by
> security policy, channel category (iii).

The SMTP opportunistic DANE TLS draft mentions coexistence of that
protocol along-side existing channel security policies.  We can
add some language that makes it clear that OS is not intended to
displace cases where security assurance is required, rather it is
intended to serve the under-served.

> Currently, the phrase
> "interoperability must be possible without a need for the administrators of
> communicating systems to coordinate security settings" suggests that a
> system where one authenticates entities via certificate verification of a CA
> root key acceptable to the receiving end of a communicated cert would be
> taboo

Opportunistic security needs to allow "incremental" adoption,
without O(N^2) manual coordination effort.  For use-cases where
use of public CAs requires no manual coordination, OS can use public
CAs.  In any case, OS does not exclude the use of non-OS policies
where applicable.

Just because something is not OS, does not mean that it is forbidden.
It is simply not OS.

> security must not get in the way of the peers communicating if neither end
> is misconfigured and neither end precludes communicating with the other end
> by virtue of its own security policy".

On the substance, sure, but if we're going to have to explain this,
I'd like to do it elsewhere, by stating that OS does not trump
local or other policy that requires greater channel security for
some or all peers.  Such policy is not OS, but OS can coexist along-side
other (traditional or new mechanisms or policies).

> Note: Right now, the term
> "misconfigured" is not really defined, but the suggestion from the entire
> draft is that one should allow channel type (ii), no matter what.

For peers only capable of (ii), when some OS protocol is the selected security
mechanism.  I wanted to define OS.  It seems I am being asked to also define
how it interacts/coexists with other designs.

> 
> (c) With the "maximize security peer by peer" para (Section 3), the phrase
> "opportunistic security may at times refuse to operate with peers for which
> higher security is expected, but for some reason not achieved" is somewhat
> cryptic. If the intention is to capture that ultimately it is up to each
> peer to enforce its own security policy as to channel category (i), (ii),or
> (iii),

No, this is mostly about the purported capabilities of the peer,
not (static) prior policy.  We can handle static policy separately
if that's required.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Aug 2014 13:36:00 -0400 (EDT)

On Wed, 6 Aug 2014, Stephen Kent wrote:

> 4. The term "collection" is generally defined as passive wiretapping, so encryption

I think that the term or usage of the term will need to be updated in that
case since we have been made aware of the efforts of massively storing
encrypted traffic for later decryption (note the leaks regarding pptp
and weak IKE PSK's in particular)

Encryption is not "sufficient" to protect against "collection". It only
raises the costs for the collector to decrypt it.  Pervasive monitors
in fact, _especially_ collect encrypted communications for later processing.

> 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 think

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.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 6 Aug 2014 17:55:49 +0000

On Wed, Aug 06, 2014 at 01:36:00PM -0400, Paul Wouters wrote:

> >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.

> 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.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Aug 2014 20:37:56 +0100

Hi Rene,

Just two things on this bit...

> also the concerns I expressed July 11, 2014, 10:08am EDT [copied at end

First, your (iii) is not a single thing, we very often see server-auth
only for https for example, which is quite different to mutually
authenticated channels, which themselves may be e.g. TLS mutual auth or
some form of TLS server-auth+channel-binding+user-password. Also SSH's
leap-of-faith/TOFU model doesn't match any your categories well I would
assert. So, we're just not on safe ground in making any inferences
about possible "shifts" from (iii) to (ii).

That said, I do get the concern so if there's text that could/should
be added saying that changing from an existing working endpoint
authenticated channel setup to an OS setup could be a disimprovement,
that could be reasonable as a security consideration.

Cheers,
S.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 6 Aug 2014 21:23:02 -0400 (EDT)

> More than that: why should OS stop there?

Aren't these two comments of contradicting? First you say authenticated
encryption is not opportunistic security,  then you say that OS should
be more then just unauthenticated encryption and should not stop there?

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 Aug 2014 01:33:53 +0000

> be more then just unauthenticated encryption and should not stop there?

No contradiction.  Neither Nico, nor the draft state the authenticated
encryption is mutually exclusive with opportunistic security.  Both
in fact say the opposite.  However, an indiscriminate static policy
that applies a fixed authenticated security policy to all peers
regardless of capabilities (and fails when the peer does not measure
up, even though there no reason to expect that the peer could be
authenticated, other than said static policy) is not opportunistic.

    * Fixed high bar:

	not opportunistic security

    * Variable bar, set high for peers that securely publish requisite capabilities,
      and lower for peers that don't, possibly even allowing cleartext, or at least
      unauthenticated encryption:

	opportunistic security.

The two approaches can coexist, when an organization has high value
business relationships with select peers, and wants guaranteed
protection for traffic with them, but to promote as secure as
possible communication with the rest of the planet, is more liberal
(opportunistic) in its default communications policy.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Aug 2014 20:49:07 -0500

> be more then just unauthenticated encryption and should not stop there?

Are we reading the same quotes?  I don't understand your response.

Where did I say that "authenticated encryption is not opportunistic
security"?  Remember, I was really responding to Stephen K., not Viktor.

As for the second quote, I meant that OS shouldn't mean only
"unauthenticated security", which with DANE in context makes sense:

 - if you can securely discover that a service can do strong
   authentication, do _that_

   (Securely discover: there's a DNSSEC path from . to the service's
    RRSets' names, AND there are TLSA-like RRSets for it that bootstrap
    authentication from DNSSEC.  Remember: DNSSEC provices secure
    NXDOMAIN results.)

 - otherwise attempt unauthenticated encryption

   (The service had no TLSA-like RRSets or one of the zones from .
    to it doesn't support DNSSEC.)

The ability to securely bootstrap authentication via DNSSEC is
"opportunistic": we do it when it (DNSSEC, TLSA RRs) is there, we don't
when it isn't.  Teh key here is that DNSSEC allows us to securely detect
that this path isn't available.

The ability to use unauthenticated encryption when we would otherwise do
cleartext is also "opportunistic": we do it if we can negotiate it.

Nico
--

---

From: ianG <[email-masked]>
Date: Thu, 07 Aug 2014 12:30:57 +0100

> everyone will refuse to fail to encrypt.

OK, got it, that becomes clearer reading the full context, 'design
philosophy'.

iang

---

From: Stephen Kent <[email-masked]>
Date: Thu, 07 Aug 2014 10:43:14 -0400

Paul,

> in fact, _especially_ collect encrypted communications for later 
Sorry if my comment was too terse. Acquiring traffic for later 
cryptanalysis is
consistent with the notion of "collection" as passive wiretapping. We 
seem to agree that
having to decrypt traffic raises the cost for the wiretapper. RFC 7258 
argues that
widespread use of encryption is a good countermeasure for PM. So, yes, 
collection of
traffic is not prevent by encryption of payloads, but encryption of 
payloads is perceived
as a meaningful, significant countermeasure.
> encryption, don't call it security.
Not everyone is in agreement about the scope of OS, as these continuing 
discussions
illustrate :-).

Steve

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 Aug 2014 15:03:26 +0000

On Thu, Aug 07, 2014 at 10:43:14AM -0400, Stephen Kent wrote:

> discussions illustrate :-).

Indeed:

  - Rene Struik is concerned that opportunistic security might
    lead to a reduction in protection against active attacks,

  - You seem to want to ensure that opportunistic security should
    avoid defending against active attacks,

  - And I am suggesting adaptive behaviour that protects against
    active attacks when the peer is known to support authentication
    (via whichever key management technique from DANE, TOFU, ... is
    applicable to the situation at hand).

I can address Rene's concern, by adding some text to explain that
OS coexists with existing mandatory security policies, and is
intended to handle the cases in which mandatory policy does not
apply.  Protocol designs should however be aware that trying to
apply mandatory policy too broadly can have negative consequences,
and that OS may well be a better fit in many situations.

As for a desire to cap the definition of OS at unauthenticated
encryption, I'm afraid I've seen no compelling rationale for that.
It runs counter to Rene's concerns, and counter to the opportunistic
use of DANE authentication in Postfix, and would fail to encourage
other designers of adaptive protocols to consider authenticated
modes of operation.

Note, the draft DOES NOT require that OS protocols be able to
support authentication, it encourages protocol designers to consider
the option.  It is even likely that OS designs for near-term wide
deployment will not be able to offer authentication, since DANE is
not yet ready for prime-time (DNSSEC adoption barrier).  And yet
I see no reason to artificially cap the ceiling or preclude the use
of DANE for opportunistic authentication before we even get the 
chance to try it.

-- 
	Viktor.

---

From: ianG <[email-masked]>
Date: Thu, 07 Aug 2014 16:08:32 +0100

On 6/08/2014 16:42 pm, Stephen Kent wrote:

> Clarity in writing, and concision, yield good docs. ...

Normally, this would be true.  Precision in terminology would be a good
thing.

Unfortunately, we are not in the normal circumstance.  We're in the
byzantine environment where agencies expend significant resources to
push the net in particular directions.  These directions can be obvious,
direct, or also subtle and confusing.

In particular, the agencies know that it is rather easy to push a
committee into a self-defeating cycle of perfection.  This is not a
matter of speculation, it's standard time-tested practice [0].

It requires a certain degree of balance to oppose "more precision in
terminology" when it is universally a good thing, as "the perfect is the
enemy of the good."

I'm not saying that we are at that point, but instead, I'm seeking to
cast light on why people here might be aggressively pushing forward an
imperfect text.  Pushing against equally aggressive wordsmiths.

It's simply that a lot of us feel that for a couple of decades, the
committee-perfection thing preferred in IETF has been used against us.
To bad results.  Enough is enough.

It takes some deft handling to find the balance, the compromise.

iang

[0] http://svn.cacert.org/CAcert/CAcert_Inc/Board/oss/oss_sabotage.html

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Aug 2014 11:07:34 -0500

>     avoid defending against active attacks,

[Here "you" == Stephen K.]

That's my take on Stephen's position.  IIRC it derived from wanting no
UI impact from OS.  But DANE lets you securely discover that you can
authenticate a service, authenticate it, and success/failure *is* the
*only* UI needed in that case -- a UI that already exists.

I.e., OS w/ DANE has no UI impact, and you can't fallback on
unauthenticated encryption when the service can be authenticated.  OS w/
DANE has no downgrade attacks.

The only ways to make OS w/ DANE fail are: compromise a DNS registrar in
the chain, compromise the service, compromise the crypto, or DoS.

Heck, OS w/ TOFU/pinning has similar properties once the peer's keys are
learned/pinned (and with all the security considerations of
TOFU/pinning).  DANE isn't the only option, but DNSSEC's secure NXDOMAIN
functionality makes DANE >> TOFU/pinning.

Therefore OS can provide more than unauthenticated encryption in some
cases.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Aug 2014 11:14:14 -0500

>     lead to a reduction in protection against active attacks,

I too had this concern.  For me the key is that looking forward to a
DANE-like world we get secure discovery of services' ability to
authenticate.  By "secure discovery" I mean: no downgrade attacks.

Rene's concern however is partly about people getting a false sense of
security and not bothering with anything else once they have
unauthenticated encryption everywhere.  However, I think DANE is much
more likely to gain momentum than people are to think they have security
against active attacks without it.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 Aug 2014 16:21:03 +0000

On Thu, Aug 07, 2014 at 11:07:34AM -0500, Nico Williams wrote:

> IIRC it derived from wanting no UI impact from OS.

I've seen no compelling rationale for that either.

The less said about the UI the better, we aren't experts even about
the UI's of specific applications, let alone about the UIs of a
family of protocols sharing some common security features.  The
draft's "no misrepresentation" language is about as far as one
might reasonably venture in that direction.

For example, in Postfix logs (closes thing in an MTA's to a UI),
DANE authenticated delivery is logged as authenticated delivery,
in much the same manner as authetnicated delivery via a trust chain
from a public CA, or a statically configured public key fingerprint.

Representing opportunistically DANE authenticated transactions as
secure may be the right choice for an MTA, but need not be the
right choice for a web browser.  The draft should I think be
silent on UI issues.

Therefore, I think a UI argument against admitting authenticated
modes of operation in the umbrella term is not appropriate.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Aug 2014 11:25:26 -0500

+1

---

From: Christian Huitema <[email-masked]>
Date: Thu, 7 Aug 2014 17:29:44 +0000

> Heck, OS w/ TOFU/pinning has similar properties once the peer's keys are learned/pinned 
> (and with all the security considerations of TOFU/pinning).  DANE isn't the only option, but 
> DNSSEC's secure NXDOMAIN functionality makes DANE >> TOFU/pinning.
>
> Therefore OS can provide more than unauthenticated encryption in some cases.

Agreed. I like Viktor's description of a continuum, from basic OS to maximal security.

For example, I can see a baseline of "zero knowledge" encryption, using some kind of DH exchange where each party contributes half a key. This is obviously vulnerable to MITM. We can progress from there with optional authentication using channel binding, which would detect the MITM. If one party knows a public key for the other party, they can use that key to encrypt their "half key" during the DH exchange, effectively making MITM much harder. These are just sketches, but they show that is very easy to conceive OS protocols that offer gradual improvements in the level security.

-- Christian Huitema

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Aug 2014 11:04:09 -0700

> Agreed. I like Viktor's description of a continuum, from basic OS to maximal security.

I agree it's useful to describe it as a range, but it isn't as clearly a 
continuum or even a total order of discrete values.

Different types of security may not be directly comparable in terms of 
strength and protection, e.g., what's "stronger":

	- small keys and authentication

	- large keys and encryption without authentication

Joe

---

From: "Black, David" <[email-masked]>
Date: Thu, 7 Aug 2014 14:30:28 -0400

> 	- large keys and encryption without authentication

I agree that scope of security functionality (e.g., authentication
presence/absence) should be orthogonal to strength of functional
components (e.g., encryption key sizes).  I thought this draft
primarily concerned scope of functionality, as "opportunistic" is a
characterization of (potential) absence of functionality (e.g.,
authentication, again).

A functional continuum or range seems like a fine concept, where
"maximal" refers to breadth of functionality, and not the relative
strengths of individual functional elements.

Thanks,
--David

> -----Original Message-----
> From: saag [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Thursday, August 07, 2014 2:04 PM
> To: Christian Huitema; Nico Williams; [email-masked]
> Subject: Re: [saag] Last Call: <draft-dukhovni-opportunistic-security-01.txt>
> (Opportunistic Security: some protection most of the time) to Informational
> RFC
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Aug 2014 11:38:03 -0700

> strengths of individual functional elements.

Sure, but there are multiple dimensions:

	- integrity protection
	- encryption
	- authentication

Is OS just about the single dimension of authentication? If so, it seems 
like there are very few points in the continuum:

	1. no knowledge
	2. no validation, but known persistent within a session
		e.g., unsigned DH
	3. no validation, but known persistent across multiple sessions
		e.g., TOFU
	4. validated (and presumably persistent as well)
		e.g., PKI or preshared secret

Joe

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Aug 2014 13:57:09 -0500

On Thu, Aug 07, 2014 at 11:04:09AM -0700, Joe Touch wrote:
> I agree it's useful to describe it as a range, but it isn't as
> clearly a continuum or even a total order of discrete values.
> 
> Different types of security may not be directly comparable in terms
> of strength and protection, e.g., what's "stronger":
> 

If you're proposing that we have some security ranking, I think that way
lies quagmire, or it should be left to a future document.  We need to
make progress.  Viktor's I-D is a great start.  Let's get started.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Aug 2014 14:03:06 -0500

On Thu, Aug 07, 2014 at 11:38:03AM -0700, Joe Touch wrote:
> Is OS just about the single dimension of authentication? If so, it

No.  Read the draft and the list archives.  OS is about doing anything
we can do that is better than sending plaintext.  I.e., assume at least
unauthenticated key exchange + authenticated encryption (in the AEAD
sense), and do not preclude authentication; if you can securely detect
the ability to authenticate, then do not fallback to unauthenticated key
exchange nor cleartext.

That's it.

> seems like there are very few points in the continuum:
> 
> 	1. no knowledge

Also: DANE.  That's special because you can securely find out that you
can do it, with no downgrade attack.  That consideration is critical to
understanding potential future evolution for application protocols.

Pre-shared/configured keying is the only other scheme that has this
property, and it doesn't scale.

Nico
--

---

From: Joe Touch <[email-masked]>
Date: Thu, 07 Aug 2014 13:08:54 -0700

On 8/7/2014 11:57 AM, Nico Williams wrote:
> lies quagmire, or it should be left to a future document.

Actually I'm just warning that there is no such thing, IMO.

 > We need to

No disagreement; the point was to mark this as a rathole to avoid it.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Aug 2014 16:20:45 -0400 (EDT)

On Thu, 7 Aug 2014, Nico Williams wrote:

> unauthenticated encryption everywhere.

That is why FreeS/WAN did not do anonymous IPsec back in 1997. Boy I
wish we had come to a different conclusions at the time. Today, it's
only become more obvious that we need to do this, and yes not bother
the user with a GUI if it is unauthenticated.

Paul

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Aug 2014 15:22:52 -0500

> Actually I'm just warning that there is no such thing, IMO.

Indeed, a standard, global ranking of apples to oranges (which rot at
different rates too boot) is not feasible.  We shouldn't even try.

(Local rankings are called "configuraiton".  That's OK of course.)

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Aug 2014 15:26:13 -0500

> the user with a GUI if it is unauthenticated.

If the app/user would fallback to cleartext, then yes.

(I also wish that Dan McDonald's IP_SEC_OPT socket option from back in
1996-ish -which much later inspired RFC5660- had gotten momentum then
too.  We wouldn't have to have TCP-layer crypto protocols now.)

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 07 Aug 2014 21:40:14 +0100

In some offlist mail I described OS as a useful protocol
design pattern.

The receiver of that mail thought that might be useful.
Other opinions on that welcome.

S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 Aug 2014 21:39:27 +0000

> Other opinions on that welcome.

I may borrow the term "protocol design pattern" for the next revision
of the draft, if you don't mind.

There are a few layers of granularity at which one can consider
the range of security levels that OS can achieve.  At the coarsest
level, we have a reasonable ranking:

   1. cleartext, which is weaker than:

   2. passive attack protection via unauthenticated encryption, which is
      weaker than:

   3. passive and active attack protection via authenticated encryption

Then we can peek beneath the covers and look at the details of the
security protocols used in 2 or 3 to find that an objective total
ordering of these is difficult to impossible.

This said, there is some merit to the view the at the level of
opportunistic behaviour, which is mostly about mechanism selection
(encrypt or not, authenticate or not), we are just talking about
the 123 choice above, and not so much about the details of which
cipher-suites are negotiated in 2, or whether authentication is
mutual in 3, ...

Finding a sensible cipher-suite is largely outside the scope of
opportunistic behaviour, it is just mechanism-specific baggage.

Now mutual authentication in TLS where the server optionally requests
client certificates can be opportunistic, based on the presence of
published TLSA RRs for the client's purported identity.  This is
even an item for consideration on the DANE WG's updated charter.

However, this does not change the picture much, because basically
the opportunistic behaviour in that case is by the accepting peer,
and for the initiating peer the coarse levels are still 1, 2, 3.

So the draft could, in principle describe the more detailed coarse
view above as the context in which the OS design patter plays out.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 7 Aug 2014 18:59:15 -0400 (EDT)

> discussions illustrate :-).

Agreed. But the point I was trying to convey is that the continued
discussion in itself is a sign that the term (and thus the final outcome
of this discussion/draft) will not be very useful. It will at best have
the same ambiguities as OE outside the IETF space.

I think we are still confused about whether we are defining a term for
protocol engineers or for consumers. I don't think OS is useful as a
term for protocol engineers, especially because the only part of
"security" we seem to be talking about is encryption and authentication.

Security isn't opportunistic, security should be mandatory. Encryption
or authentication can be opportunistic.

Paul

---

From: Nico Williams <[email-masked]>
Date: Thu, 7 Aug 2014 18:27:48 -0500

On Thu, Aug 07, 2014 at 06:59:15PM -0400, Paul Wouters wrote:
> >Not everyone is in agreement about the scope of OS, as these
> >continuing discussions illustrate :-).
> 
> discussion in itself is a sign that the term (and thus the final
> outcome of this discussion/draft) will not be very useful. It will at
> best have the same ambiguities as OE outside the IETF space.

We may just have to see.

I think there's a much better chance for OS than there was for OE for
the following reasons:

 - The Time is Right; timing is everything.

 - OE was IPsec-specific; OS has general applicability.

 - OS was a term we spent a *lot* of time settling on; some of us (at
   least myself) asked non-initiates for feedback on a large variety of
   alternatives, and OS seemed to work best.

 - We're actually working _right now_ (i.e., in this LC and related
   threads) on establishing widespread consciousness of the term OS
   within the IETF community.  Combined with the general applicability
   of OS this means the term should have a much better chance of
   widespread adoption than OE.

We'll have to socialize the term outside the IETF when we're done with
this draft, of course.

In any case, we can't fail to try just because we had trouble getting OE
adopted.

> protocol engineers or for consumers. I don't think OS is useful as a

"Yes."

We're defining it for protocol engineers (that's the audience for RFCs),
but we've picked the term "OS" so that it denotes roughly the right
thing to users as well.

First, no other adjective in the English language is as appropriate a
descriptor as "opportunistic" is.  We spent a fair bit of time on this
on saag.

Second, "security" is clearly easier for users to understand than
"encryption" and many other terms.

Third, because the design pattern is right (right? I think we've clearly
got consensus on that by now) we're not pulling a fast one on users.  We
can expect influential social media and news media writers to pick up on
this eventually, particularly as more application protocols adopt OS and
then products ship.

Remember, the time is right; if not now, probably never.

Finally, for something of such broad applicability we could argue about
linguistics forever and not reach consensus.  Fortunately we're only
after rough consensus, which I believe we have.

> "security" we seem to be talking about is encryption and

On the contrary, it's a great term: the pattern it refers to is
relatively simple and it addresses a highly visible subset of problems
in the security space, on top of which its applicability is broad.  OS
has a great chance of becoming a well-known short-hand for exactly what
we're after.

> or authentication can be opportunistic.

I've two different answers to this:

 - With DNSSEC/DANE in mind:

   Sure, because the end state is that all services will use DANE or
   alike.  But if you insist on never having less than "full" security,
   then see my second answer below.

 - Absolutely NOT, because we've tried insisting on security all the
   time and failed time and again, and we know that given the choice of
   "things I care about don't work" or "things don't work securely",
   users (and vendors) reliably choose the latter.  OS is about getting
   us on an upgrade path to security being on all the time (see first
   answer).

   You yourself wrote earlier today that you wished IPsec had done this
   in 1997.  So what's the problem?  Why the self-contradiction? :)
   
   I suspect you're reacting not to the protocol design pattern but to
   the name.  Perhaps like Rene, you're afraid that OS will cause users
   to accept less than what they should expect.  This is a risk, but
   again, with DANE in mind, I think it will be a non-problem: because
   DNSSEC allows us to securely discover that we can authenticate,
   leaving the choice, really, to the services we use (and so to how
   much they value reputation).

   In any case, since we won't get to the end state in one day, we need
   a deployment strategy and a catchy term.  I believe there's no better
   alternative to "OS", or that we won't find a better alternative
   without spending so much time and effort on that search that we'll
   miss our window of opportunity.

Nico
--

---

From: ianG <[email-masked]>
Date: Fri, 08 Aug 2014 10:59:48 +0100

> "security" we seem to be talking about is encryption and authentication.

I can't recall when we first started talking about SSH as being
"opportunistic" as against the "model/standards" approach of PKI.  I
think it's at least a decade.

> Security isn't opportunistic, security should be mandatory.

Developers from the "model" or "standards" security school thought so,
but people in the emerging "risk" school think not.

In the risk [0] approach, everything is optional, and every tool is a
mitigation.  Everyone makes choices, and everyone should make different
choices.  Every choice has its pluses and minuses.

Where "mandatory" makes its mark is if one legal party is supplying to
another legal party, and there is a claim made;  if the claim turns out
to be false, and the second party is damaged, there is a legal liability.

In order to mitigate (!) the risk of legal liability, a product is sold
with some standard attacked, that says "X is mandatory".  As long the
product meets the standard's mandatory marks, the liability is limited.
 (Or so the legal theory goes.)

If you didn't have the liability or commercial arrangement such an
approach might not be needed.

iang

[0] another term might be risk security, but I suspect that boat has
departed.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 08 Aug 2014 09:28:11 -0400

Ian,

> direct, or also subtle and confusing.
I have seen no evidence that any of the work on various forms of 
opportunistic
security for a variety of protocols in the IETF has been delayed by the
deliberations about this doc. Thus I believe there is no reason to rush 
ahead
with text that could be more precise, clearer, etc.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 08 Aug 2014 09:33:37 -0400

Paul,

> ...
That's a new statement in this context. And, given the variety of
security services we may be able to provide, I don't know how to interpret
the statement.
> Encryption
I think you mean that the use of these services, between peers, may be 
invoked
opportunistically?

Steve

---

From: ianG <[email-masked]>
Date: Sat, 09 Aug 2014 09:18:50 +0100

...
> ordering of these is difficult to impossible.

Right.  Maybe that is the point to make?

> the 123 choice above,

The current state of the art would suggest that ordering 123, yes.  But
our knowledge and our facilities advance over time.

> and not so much about the details of which

Well, no.  Correct my understanding, but as I understand it:  [TCPInc]
will not change its charter with MUST-include-algorithm-agility until
they receive specific advice from drafts such as this OS one or the
stalled one on algorithm agility.

As of the moment, [TCPinc] are in the unfortunate position of having to
explain to their users that they might or might not be passively secured
with confidentiality, but if they are, they can be assured that they are
using one of several 'sensible' cipher-suites, and if they aren't, it
might be because 'sensible' searches for suites failed to agree.

> even an item for consideration on the DANE WG's updated charter.

Engaging in mutual authentication is something where our knowledge and
capabilities might indeed advance, once OS is accepted as a good design
philosophy.  It has often been suggested that the password mess can be
mitigated by (eg) use of client certs.  Yet, the only way this notion
will advance is opportunistically;  the standards/model approach fails
to deploy client certs in sufficient numbers and therefore rules them
outside the security model, optional-not-opportunistic, 2nd class citizen.

(The trick here might be to leave 'purported identity' outside the
discussion.)

> and for the initiating peer the coarse levels are still 1, 2, 3.

I don't think we know that.  If hypothetically in TLS there was always a
possibility for the client to deliver a cert, without being asked, then
we might get 3 and 2 in parallel.

> view above as the context in which the OS design patter plays out.

I agree that the 1,2,3 description above is helpful as long as it is
indicative of current understanding, and is not suggested as advice or
best practice.  Or, e.g., as you point above, the 1,2,3 is a stylistic
high level view, but likely in the event, a designer will find that the
objective total ordering fails.

On the question of advice on algorithm agility or mutual agility, maybe
they should be debated for their importance, but that doesn't mean the
OS draft should include them.

iang

---

From: John C Klensin <[email-masked]>
Date: Wed, 06 Aug 2014 18:39:37 -0400

--On Wednesday, August 06, 2014 07:15 +0200 Patrik Fältström
<[email-masked]> wrote:

> 
> On 6 aug 2014, at 04:26, Dave Crocker <[email-masked]> wrote:
> 
>> Use DANE without DNSSec, and calling it opportunistic
>> probably makes sense.  Using it with DNSSec and it doesn't.
> 
> The devil is in the details. I think we disagree on the
> meaning of the word "opportunistic", and the evaluation of
> whether you are lucky enough.
> 
> Personally, I think that as fragile the current CA system is,
> I think DANE without DNSSEC is more stable and better than the
> current CA system. And better than self-signed-certs that one
> "just accept" (which happens quite a lot).

Conversely (and without agreeing or disagreeing with either of
you), the discussion suggests noting, again, the very limited
nature of what DNSSEC actually protects.  It is ultimately an
integrity test within the DNS hierarchy.  If the resolver
associated with the user's application is not DNSSEC-validating
and within that user's trust boundary, then relying on DNSSEC
for protection is only as good as the intermediate trust
situation, e.g., whether the client user trusts the testing and
validity assertions of her ISPs forwarding DNS system.   There
is reason to not do that.  First, it may have changed but at
least up to some years ago, those ISP "DNS servers" were much
more often compromised than, e.g., authoritative servers for
root or TLD domains.  Second, some ISPs have discovered that
that they have economic or political incentives to alter DNS
queries or responses.  Enough have done so under various
circumstances to discourage uncritical trust.

The other end is equally bad.  DNSSEC protects the integrity of
data already stored in the DNS.  But, if the proverbial Bad Guy
can compromise a domain name registrar and register a name that
is misleading or otherwise problematic, certificates tied to
that name may not be very useful, especially as assertions of
good and upright behavior associated with, e.g., mail traffic.
Whether DANE-type certificates that depend on DNSSEC and
registrar integrity are more of less trustworthy than PKI-type
certificates that depend on certificate chains,
low-assertion-quality certificates, and CA integrity is an
interesting question... but one that might easily be resolved by
a race to the bottom.

   john

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 6 Aug 2014 07:15:50 +0200

> sense.  Using it with DNSSec and it doesn't.

The devil is in the details. I think we disagree on the meaning of the word "opportunistic", and the evaluation of whether you are lucky enough.

Personally, I think that as fragile the current CA system is, I think DANE without DNSSEC is more stable and better than the current CA system. And better than self-signed-certs that one "just accept" (which happens quite a lot).

   Patrik

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Aug 2014 11:03:39 +1000

In message <[email-masked]>, John C Klensin writes
:
> nature of what DNSSEC actually protects.

DNSSEC is designed to protect the data from when it is entered to
when it is retrieved by the application.  It is the applications
fault if it is not validating answers it receives.

DNSSEC works with stub resolvers.  The application just has to
request the DNSSEC records be returned.  There are a number of
validating stub resolver libraries.  Libdns has been able to perform
in this role for 15 years now.  named calls libdns to do its
validation.

Validating in the recursive server is a *necessary* step in getting
a working DNSSEC path to the application but it was *never* intended
to be the last place that validation was performed.  It provides
protection against attacks on the traffic between the recursive
server and the authoratative server.  It doesn't protect between
the recursive server and the application.

If, and only if, you have a trusted path between the recursive
resolver and the stub resolver, and you know the validation policy
of the resolver and agree with it can you trust the AD bit.  Unless
you are running a validating recursive server on the same machine
as the application you will most probably not meet the required
level to trust AD.  If you use a ISP's nameserver you should not
trust AD. 

I believe but have not verified that most DANE implementations
actually validate answers in the application.  This is where we
expected the ultimate validation to be done when we started developing
DNSSEC.  In application includes within a library the application
calls.

> It is ultimately an

While there is a threat with registries and registrars I believe
you are overstating the threat.  Being able to register a new name
is NOT a threat.  What is a threat is compromising registrant and
registrar accounts, unauthorised transfers, a registry publishing
unauthorised delegetion data, and the private keys of the registry
being leaked / used in unintended ways.  Note apart from private
keys these are threats that registries and registrars have to deal
with in plain DNS and should already be taking steps to address.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Sat, 09 Aug 2014 09:25:10 -0700

On 8/6/2014 3:39 PM, John C Klensin wrote:
> the discussion suggests noting, again, the very limited
> integrity test within the DNS hierarchy. 

This is such a fundamental point and of such broad community relevance,
it's important we have clarity about it.

     I have always understood DNSSec to provide /authentication
     for DNS data/, specifically that the data were put there
     are under the authority of the domain name owner.

The signing hierarchy (up to the root, when full DNSSec signing is used)
certifies the authenticity of the domain owner's signature.

Data integrity is an important side-effect of crypto signing
methodology.  However I'm not used to seeing it classed as the primary
purpose of DNSSec, with no mention of authentication.

It would be helpful for DNSSec experts to provide clear, simple,
definitive statements on this.

d/

---

From: Paul Wouters <[email-masked]>
Date: Sat, 9 Aug 2014 13:03:46 -0400 (EDT)

> purpose of DNSSec, with no mention of authentication.

In the mid ninetees when dnssec was worked on, there were two camps. The
DNS people who wanted to only secure DNS and explicitely did NOT
want the DNS to become a PKI. And those that mainly wanted secure
DNS to make a new PKI (eg Gilmore and the FreeS/WAN people). This
fight continued throughout, and is the reason KEY/SIG/NXT changed to
DNSKEY/RRSIG/NSEC. The change dictated those records were for DNS only
and not for use by applications as PKI.

So the PKI people had to silently go along with the DNS people to
write and deploy DNSSEC, so that they could add their RRTYPE's for a
PKI later even if the DNS people hated the idea. That is why you don't
see it listed anywhere in any document as a purpose of DNSSEC.

Paul

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 9 Aug 2014 17:34:10 -0400

Just to point out that DNSSEC authenticates data even in the case of
null data; that is, it provide authenticated denial of the existence
of data.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 9 Aug 2014 17:43:14 -0400 (EDT)

> we might get 3 and 2 in parallel.

It seems that mutual-authentication everywhere, particularly if clients
(sometimes) speak first, might make it eaiser to track the connections of
a particular user.  Leaving "purported identity" outside the discussion
may leave room for a client to present a unique/throwaway identity when it
does not care about being associated with some existing database of
identities.

-Ben

---

From: John C Klensin <[email-masked]>
Date: Sun, 10 Aug 2014 10:36:29 -0400

--On Saturday, August 09, 2014 12:31 -0400 Steve Crocker
<[email-masked]> wrote:

> The authenticity and integrity go hand in hand.  The party
> looking up a domain name wants to know if the answer is
> correct.  "Correct" in this context means that it was
> provided by the party that is authorized to provide it, i.e.
> the domain owner, and that the information hasn't been
> modified along the path to the user.  That's integrity and
> authenticity combined.

Steve, while I clearly agree with the above, I was trying to get
at the point that there are other elements that people might
reasonably consider part of authenticity.  One is whether the
apparent domain is what it appears to be.  Another is whether
the apparent domain owner is who it appears or claims to be.
That, in turn, is closely connected to the question of whether
there is enough information available to even determine what
ownership assertion is being made, i.e., whether the
user-accessible part of the registry database contains
information about the domain owner or merely some proxy or
"hidden registration" information that points to an entity that
conceals identities for hundreds or thousands of such domains.

>From those perspectives, a registrar or registry who might
collude with a criminal registrant to create deliberately
deceptive names and associated registration data (or whose
procedures allow similar results without explicit collusion) is
fully as much part of the threat model as a CA that issues
certificates without any attempt to verify the identity of the
entity being certified or who colludes in deliberately hiding or
distorting the information.  

Now "we" all know that has nothing to do with DNSSEC.  It
provides assurance that what is in an authoritative zone and
what reaches the systems closest to the user that actually
validates the signatures and records are the same.  But I'm
concerned that it gets oversold to the point that users and
others in the name-using environment hear what we say about "DNS
Security" as "if DNSSEC validates the record, then one has
assurances of the accuracy and integrity of the registrant and
registrant- DNS entry relationship" with "accuracy" and
"integrity" used in their street sense, not the much more narrow
and technical DNS and DNSSEC ones.

Where that loops back to things like DANE is that DANE, at least
apparently, is making assertions about the identity of an
individual or other entity, not [merely] about validation of the
relationship of DNS records as installed/created in comparison
to those received.  As with DNSSEC itself, that isn't a problem
if DANE is used carefully and with an understanding of what
assertions are being made and can be trusted.   It could be a
significant problem if people over-promise (or over-believe) and
the use of DANE for critical functions becomes widespread enough
to become a tempting target for attacks of technical and/or
social or economic character (just as we have seen on CAs).

There is one sense in which trust models based on DNSSEC that
seem to imply certification of non-DNS entities (like
registrants) are more dangerous than ones based on CA chains.
In the latter case, there are good, and obvious, analogies to
many people's everyday experience.  If one finds someone who
claims to be a notary but who operates out of the back of a
taxicab, exhibits no credentials or authorization, who is
willing to certify a document with no more identification of the
signer than the ability to pay a few dollars in cash,  and
trusts him to certify signatures on an important document, it is
pretty generally understood what that certification is worth.
We aren't quite there with CAs, but most people are able to at
least understand applicability of the analogy.  On the other
hand, when we build a system on top of the DNS and DNSSEC,
relying on elaborate rituals like the signing of the root and
layers of processes that are, for the typical user of the
Internet, indistinguishable from magic, and fail to be clear
that, e.g., no actual certification of registrant identity or
integrity is involved, people may trust the magic rather than
trusting DNSSEC as it is.  

That, in turn, could lead to some really nasty surprises --and
loss of confidence in us and the institutions we ask people to
trust-- when the bad effects of that misunderstanding manifest
themselves in a damaging and public attack.

best,
    john

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 10 Aug 2014 15:00:06 +0000

> and technical DNS and DNSSEC ones.

No certification authority assures a user of the business ethics
of a company.  A CA may in some cases refuse to issue certificates
that are misleading with respect to a company's identity, but they
make no assurance that the user will not be defrauded.

I, personally, find all attempts to conflate *identity* certificates
with *trustworthiness* to be irresponsible hype.  Neither DANE or
public CAs have any business selling "trustworthiness".  If users
want that, then they'll need to vote with their dollars for tools
that (somehow, statistically at best) provide information about
the trustworthiness of a particular domain.  This is a separate
problem from identifying that domain.

The trustworthiness tools can ONLY succeed if there is no financial
relationship between the rated domain and the rating "agency".
The users would have to collectively pay the rating agency tax.
Otherwise, the system is a sham.  Both DANE (through the registrant
to registrar relationship) and public CAs are paid for the domain
owner, and thus trustworthiness cannot be asserted by either.

-- 
	Viktor.

---

From: Henry B Hotz <[email-masked]>
Date: Sun, 10 Aug 2014 13:24:07 -0700

> trusting DNSSEC as it is.  

There is one sense in which trust models based on DNSSEC are less dangerous than CA chains. The keys are issued by the same people who are responsible for directing traffic (via DNS) to a named entity, not by some other people at a different business in another country. My favorite example of this is the US Federal Bridge CA, which is not on the standard browser trust lists. At the same time a number of hostile (to the US) foreign governments *are* on those lists.

Where I think we agree is that having simple, clear, and accurate descriptions of what a technology does is critical so no one gets a really nasty surprise.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 10 Aug 2014 20:30:10 +0000

On Mon, Aug 11, 2014 at 07:36:09AM +1200, Brian E Carpenter wrote:

> What people are pointing out is that this is no better, and no worse,
> than the seal on a snake oil bottle proving that the snake oil
> has not been tampered with since it left the factory.
> 
> Unfortunately, the average user can easily confuse that with an
> assurance that the snake oil will cure your illness. There isn't
> much we can do to change that.

Sure we can, we can stop promoting marketing hype.

An honest statement I am happy to stand by is:

    DNSSEC and DANE help ensure that your connection to the scumbag
    you connected to who's trying to cheat you out of your money
    is not tampered with by another scumbag trying to cheat you out
    of your money.

DKIM and DMARC do not prevent 419 scams and phishing.  Certification
authorities don't stop fraudulent business practices, ...  Promising
them any of those things is the problem.  Failing to deliver what
ought not have been promised is not the problem.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 11 Aug 2014 12:59:06 +1000

In message <[email-masked]>, John C Klensin writes
> conceals identities for hundreds or thousands of such domains.

DANE isn't trying to be more than "DV".  DNSSEC doesn't try to do
more than "the answer matches what was entered in the zone for both
positive and negative result".  Both of those are actually very
powerful.

They don't however protect against someone registering
microsoft.example.com and publishing a CERT for that name.

For SMTP DV and assurance that the MX records or lack there of are
not tamperered with is exactly what you want.  You really don't
care who the hoster is, just that you are talking to the authorised
hoster.

A similar thing for SUBMISSION.  You really don't care about who
is hosting the server for a domain as long as you can securely go
from the domain to the submission server.

For email you can get that user@domain sent the message.  You don't
get the linkage that "This Person" sent the message.

Now for HTTP there are times when you care about whether a EV
certificate is presented or not.  At other times you only care that
it matches the domain you are connecting to or not.

> social or economic character (just as we have seen on CAs).

DANE is only promising "DV" level certs.  It can however disprove
a invalid "EV" cert.  If a "EV" cert is referenced in a TLSA record
the difference between DV and EV comes from the CA not DNSSEC.

> trusting DNSSEC as it is.  

DNSSEC and DANE certify that the domain name holder added the linkage
from the domain -> cert.  CA's try to go from the CERT -> domain
but they are not part of the delegation process for domains so one
can never be sure.  Basically CERT's have been oversold for decades.

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Aug 2014 01:16:26 -0500

DNSSEC is most decidedly a PKI, with roughly the same security and
naming semantics as PKIX, differing only in the details.

DNSSEC is also decidedly superior to the Web PKI, mainly because DNSSEC
has strong naming constraints, while the Web PKI has none to speak of,
and because DNSSEC truly has a single root (for now) and is truly
hierarchical, while the neither is true of the Web PKI.

As far as naming goes, both PKI and DNSSEC have equivalent semantics for
what PKIX calls dNSName.  There are names that PKIX supports or could
that DNSSEC can't easily, but that's of little interest here.

DNSSEC has nothing like CPS, but CPS is a fiction, and if it weren't it
could easily be added to DNSSEC anyways.

DNSSEC does have problems:

 - The same "CAs can MITM" problem as PKIX.  DNSSEC is much better than
   the Web PKI for this because there's many fewer CAs (registrars) that
   can MITM any given domain in DNSSEC than in the Web PKI.

 - DNSSEC does not provide confidentiality of protection for lookups and
   answers (while PKIX has no real directory service to speak of).

 - DNSSEC currently uses relatively small RSA keys, and large keys make
   for amplification attack problems.  This can be fixed by sprinkling
   some DJB crypto technology, namely EdDSA.

By all means talk about the above problems if you like, but don't spread
FUD about DNSSEC.  DNSSEC is absolutely not worse than the Web PKI
(unless you think the small RSA keys are a bigger problem than all the
problems the Web PKI has, and if you do, I've a bridge to sell you).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Aug 2014 01:20:33 -0500

>    answers (while PKIX has no real directory service to speak of).

Arg, protection of confidentiality.

DNSSEC does provide integrity proection.  Which is to say:
authentication of data and its origin (assuming honest and secure
registrars, just like one has to assume honest and secure CAs in the
PKIX model).

Nico
--

---

From: Randy Bush <[email-masked]>
Date: Mon, 11 Aug 2014 14:56:13 +0800

[ most cc:s removed ]

> registrars, just like one has to assume honest and secure CAs in the

dnssec does not provide authentication of origin and does not need to do
so.  it provides object authentication irrespective of who threw the
object at you.  there could be 42 monkeys in the middle and it will make
no difference as you can verify that they threw authentic bananas.

randy

---

From: Steve Crocker <[email-masked]>
Date: Sat, 9 Aug 2014 12:31:09 -0400

The authenticity and integrity go hand in hand.  The party looking up a domain name wants to know if the answer is correct.  “Correct” in this context means that it was provided by the party that is authorized to provide it, i.e. the domain owner, and that the information hasn’t been modified along the path to the user.  That’s integrity and authenticity combined.

Steve

---

From: manning <[email-masked]>
Date: Sat, 9 Aug 2014 15:20:50 -0700

all  of this is true… ONLY to the extent that you have, in your possession and properly configured (AT YOUR OWN NODE)
a verified Trust Anchor - AND if the chain of custody terminates at one of the Trust Anchors you have configured.

Almost the same model as the CA keys stored in your browser…  

A presumptive is that folks will care for and actively manage their Trust Anchors.   Just like folks care for and actively
manage their Browser Certificates.

As usual, YMMV and your vendor may or may not agree with your trust profile or allow you to set it.

/bill

---

From: ianG <[email-masked]>
Date: Mon, 11 Aug 2014 12:38:01 +0100

> themselves in a damaging and public attack.

The only way people figure out the limits of a new technology is by
nasty surprises.

We've had our nasty surprises with the CA industry -- it's basically
worthless for any user's needs to place trust in it -- and the sooner we
get on with discovering how surprising or otherwise DANE et al is the
better for all concerned.

iang

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Aug 2014 14:09:07 -0500

> no difference as you can verify that they threw authentic bananas.

Did you think I meant "server" by "origin"?  IMO my text was clear that
I meant "registrar" (or: the entity signing the RRSet anyways).

At any rate, all we need is to authenticate the "bananas" as you put it.
I.e., DNSSEC is good enough for the purposes of things like DANE.

And DANE is good enough for a lot of application protocols.

As for other (actual) objections, if it truly mattered we'd add
something like CPS to DNSSEC.

Nico
--

---

From: ianG <[email-masked]>
Date: Tue, 12 Aug 2014 13:10:22 +0100

> The authenticity and integrity go hand in hand.  The party looking up a domain name wants to know if the answer is correct.  “Correct” in this context means that it was provided by the party that i…

Yes, we want it all, "correct".  But the problem with each of these
concepts is that they are uncertain at their core.  E.g., "authorised to
provide it" is based on a human process that can be tricked.
"information hasn't been modified on path" is likewise something that is
easy to fiddle at the endpoints.

The better way to treat this is to couple a reasonable approach to
authenticity with a reasonable approach to integrity, where the
"reasonable" level in each is balanced to the weaknesses of the other.

No point in coupling a supertanker anchor chain to a bikelock...

Now, the problem in the large is that we don't know really how to build

>> definitive statements on this.

Opportunistic Security recognises that the balance can be hard;  it says
don't couple them rigidly, do the best you can independently, and let's
see what works.

iang

---

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Aug 2014 17:36:02 -0400

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.

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 Aug 2014 07:17:30 +0900

> A presumptive is that folks will care for and actively manage their
> Trust Anchors.  Just like folks care for and actively manage their
> Browser Certificates.

a bit easier to curate one TA than 300+

randy

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 Aug 2014 22:18:06 +0000

On Fri, Aug 15, 2014 at 05:36:02PM -0400, Stephen Kent wrote:

> incorporated into the text, expect splitting the reference section
> as required by RFC conventions.

I must say I at least tried:

    commit 07e1bd3bd599266b07a162ae56b2e36fa3d4eead
    Author: Viktor Dukhovni <[email-masked]>
    Date:   Wed Aug 13 21:44:35 2014 -0400

	Steve Kent feedback.

     draft-dukhovni-opportunistic-security |  398 ++++++++++++++++++---------------
     1 file changed, 216 insertions(+), 182 deletions(-)

sorry if it is not what you had hoped, a lot more of the comments
were  addressed than might appear at first glance.  Not necessarily
by adopting the suggested changes as-is, but the comments were
useful, were taken seriously, and not simply ignored.

> have been addressed, since Viktor didn't even bother to reply to me to
> discuss the comments.

I've been integrating comments from multiple people burning the
candle at both ends for a whole week.  Cycles for individual
back/forth correspondence were not available.

My response was -03.  If you're just resending the comments for
stale versions of the work in progress, I can't really make use of
those I'm afraid.  They've already been processed and taken seriously.

> 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.

This is a reasonable new suggestion, I'll see whether this introduces
any problems in the context in which these are used.  It may well
reduce the need for the "this is not AEAD" diclaimers.

-- 
	Viktor.

---

From: manning <[email-masked]>
Date: Fri, 15 Aug 2014 15:51:48 -0700

> a bit easier to curate one TA than 300+

Indeed.   and a single point of failure is harder to miss, esp when it fails.

of course as long as most of the Internet links stay up/aren’t redirected,  nearly 
everyone should be able to walk the validation chain back to the TA.   
And we all know how robust the Internet is…  esp. these days.

/bill

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 Aug 2014 10:04:50 +0900

> Indeed.   and a single point of failure is harder to miss, esp when it

fallacious logic.  in any case, you have a cert to chase to a single
TA.  the point is the likelihood of good curation of one TA vs 300+.
can you say diginotar?

randy

---

From: manning <[email-masked]>
Date: Sat, 16 Aug 2014 01:15:58 -0700

> TA.  the point is the likelihood of good curation of one TA vs 300+.

Randy,
	I am agreeing with you.   A single TA is easier to curate.   And if all you have is a single TA,
it is much easier to notice when it breaks.   Simple,easy…   However we can continue to argue about
being agreeable...

/bill

---

From: Dave Crocker <[email-masked]>
Date: Fri, 15 Aug 2014 17:23:11 -0700

> “principle” for pattern that would be more in keeping with existing

I was surprised by the term, but mostly felt it was at least trying to
move discussion in a useful direction, compared with earlier claims,
such as that it was a 'protocol'.

However a quick search on the term produced some troubling existing
usages that conflict with the usage in the draft:

   http://en.wikipedia.org/wiki/Canonical_protocol_pattern

   "...a design pattern, applied within the service-orientation design
paradigm, which attempts to make services, within a service
inventory,[1] interoperable with each other by standardizing the
communication protocols used by the services. This eliminates the need
for bridging communication protocols when services use different
communication protocols.["

and:

http://www.eventhelix.com/realtimemantra/patterncatalog/protocol_layer.htm

    "Provide a common framework for implementing different layers of a
protocol stack."

d/

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Aug 2014 16:03:42 -0400 (EDT)

> communication protocols.["

I only see this results for google(protocol design pattern), not
google("protocol design pattern") (with quotes).

>     "Provide a common framework for implementing different layers of a

I do get several results from this site from google("protocol design
pattern"), but apparently not this particular one (which is in particular
a "protocol *layer* design pattern", which seems quite different.

The links on that site that I did follow seem to be about having a
software framework that facilitates implementations of protocols that
share common design features.  As we would like the draft under discussion
to inspire future protocol designs to share some common design features
(regarding choosing to use encryption and/or other security features), I
do not think that the usage is incompatible with our proposal.

I think that your observations may just be a failure of the search engine,
which is not reflected in the current use among computer science
professionals.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Sat, 16 Aug 2014 15:07:08 -0500

> usages that conflict with the usage in the draft:

Bikeshedding is what this is.

I'm under no illusions as to having a single dictionary of terminology
in such a large group.  In fact, I've no patience for these games; I
recall vividly Stephen Kent trying to school me as to the meaning of
"network authentication", whereupon I had to point him to the very TITLE
of RFC1510 (fun times).

It's true that terminology matters, don't get me wrong, but you're
demanding a level of conflict-free terminology that is infeasible, while
at the same time failing to convince anyone that there's a problem here.
Really, "protocol design pattern" is problematic?!

The question is not "can you find some past usage of this or that term
that you can use to nitpick?".  The question is: is the I-D clear?

IMO: the I-D is quite clear.  Serious arguments otherwise would be nice;
text nice still.

Another question, even more important, is whether OS (the proposed
protocol design pattern, not the term) is on the right path or whether
it is dangerous, or how to improve it.  I've yet to see anargument that
Viktor's OS proposal is weak tea, dangerous, or could be improved, only
lots and lots of verbiage about verbiage.

Nico
--

---

From: Paul Wouters <[email-masked]>
Date: Sun, 17 Aug 2014 10:58:48 -0400 (EDT)

> Bikeshedding is what this is.

Except in this day, the bikeshed needn't have a name. Our products are
RFC numbers. As I said before, why define a term that we can't agree on?

Just call this document something like "Defending against pervasive
monitors". Get rid of "OS" and "opportunistic security" and "design
patterns". That's the actual bikeshed paint we don't need.

> lots and lots of verbiage about verbiage.

I've actually contributed quite some text for clarifications (see git
history) and I know others have too, despite the paint discussion).
I've also suggested this document brings in mroe technical content helping
protocol designs but to some that seemed out of scope and a matter for
another document. To me, once you remove the sillyness of the terminology,
this document is precisely about giving protocol engineers generic help.

Things I came up with that I think belong in this document

- encrypt as much as possibly as soon as possible. eg no SNI style leaks
- Mandate PFS/session keys protection (Viktor included that in -03)
- Don't ask more identifying data then you need for protocol functioning
   (generic privacy/anonimity practises)
- Follow RFCs as strict as possible to defeat fingerprinting attacks
- If a connection is one-sided authenticated (eg like TLS) ensure your
   protocol is okay with a role-reversal (eg if it needs to authenticate
   the end that was anonymous)
- Ensure crypto agility doesn't come at the cost of more RTTs when the
   world moves to something stronger (eg the IKE modp problem)

Paul

---

From: Nico Williams <[email-masked]>
Date: Sun, 17 Aug 2014 12:29:45 -0500

> RFC numbers. As I said before, why define a term that we can't agree on?

Jonh Doe: this is a new utility shed design, it's highly portable and
variably sized.

Jane Doe: but the examples are kinda focused on bikes, and anyways, that's
what it's clearly designed around, so just call it a bikeshed.

John: but you could store lawnmowers, shovels, ..

Jane: your use of the term general utility is not really common place and
no one well understand it.

John: you're just bikeshedding!

Jane: see?  it's a bikeshed, and anyways, i don't care what color you paint
it, this is about the name of the thing.

:)

IMO it's bikeshedding the name.  We could be minting new words and it
wouldn't be a problem: because by giving them this meaning we'd overcome
the objection that until now they were meaningless.y

I assume there are no objections to the substance now.  Publish it!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 18 Aug 2014 10:35:36 -0500

> this document is precisely about giving protocol engineers generic help.

The silliness or not of the terminology is bikeshedding about terminology.

> - encrypt as much as possibly as soon as possible. eg no SNI style leaks

I agree, though this seems rather generic, not so specific to OS.

> - Mandate PFS/session keys protection (Viktor included that in -03)

Hmmm.  I agree that when opportunistically engaging in unauthenticated
encryption key agreement should be used, and public keys should be
fresh enough that PFS results.  I think that's pretty obvious.

But I don't think we should mandate PFS for all OS cases.  Again, this
seems like a generic recommendation/requirement, not specific to OS.

>   (generic privacy/anonimity practises)

Agreed.

> - Follow RFCs as strict as possible to defeat fingerprinting attacks

Agreed, but again: too generic.

Ditto.

Ditto.

I don't think this I-D should become a dumping ground of good security
protocol design patterns.  It's just one pattern.

Nico
--

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Aug 2014 17:17:57 -0400

Viktor,

> those I'm afraid.  They've already been processed and taken seriously.
You ignored/rejected detailed suggestions that would, IMHO, significantly
improve the text. Thus most of my comments are still applicable.

I'll go through the exercise of reviewing the posted -03 version, and 
providing feedback,
again, late this week.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Aug 2014 17:18:02 -0400

Nico,

> "network authentication", whereupon I had to point him to the very TITLE
I recall spending a lot of effort trying to transform your BTNS text into
something useful. I'm generally pleased with the results (vs. what I
started with) in terms of the text. I'm sorry to see that the effort was
not so successful wrt engendering good writing habits.

> Really, "protocol design pattern" is problematic?!
yes, it is. it's yet another example where Viktor has chosen to
needlessly create a new term, which engenders confusion.

When trying to convey new concepts to an audience it's a good idea to use
existing terminology whenever possible. This doc is a poster boy for failing
in that regard.
> that you can use to nitpick?".  The question is: is the I-D clear?
That's an easy question to answer: NO, it is not clear.
> IMO: the I-D is quite clear.  Serious arguments otherwise would be nice;
Read my comments to Viktor. They provide specific suggestions on how to
change the text. The problems are so widespread, and Vicktor has been so
unwilling to make changes, that, short of re-writing it for him, I don't
see how to fix this mess.
> lots and lots of verbiage about verbiage.
In fact, Viktor's prose is needlessly verbose in many places. I provided
some examples of how to simplify it. This doc can be much better, and
not longer, if it were rewritten to be clear.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Aug 2014 22:30:13 +0100

Steve,

On 18/08/14 22:18, Stephen Kent wrote:
> short of re-writing it for him, I don't

I think that's going too far and is disrespectful
to Viktor and to those others who have expressed
support for the document. That's especially egregious
given that you haven't even bothered to compare
-03 to the earlier on-list discussion.

Please provide a detailed description of how -03
does or does not map to the earlier mailing list
discussion.

S.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 18 Aug 2014 14:36:56 -0700

On 8/18/2014 2:30 PM, Stephen Farrell wrote:
> support for the document. 

Really, Stephen,

Please stop finding ways to discount comments from those of us with
serious criticisms of the draft.

That's especially egregious
> -03 to the earlier on-list discussion.

This is a prime example of the problem in your perspective.

An author should provide detailed responses, to detailed comments.

In the current case, the author has repeatedly failed to do that.
Instead, we are faced with the rest of us having to guess what changes
might pertain to our comments.

The kind of "check the latest draft" review that is appropriate for the
community is one that comes /after/ detailed discussion, debate and
resolution of detailed comments.

This predecessor activity -- which comprises acknowledging points of
agreement and engaging in detailed, constructive dialogue about points
of disagreement -- has been almost completely absent from any phase of
this draft, except for the places in which the author (or you or the
shepherd) have rejected points or summarily declared them in the rough.

> does or does not map to the earlier mailing list

When someone from the community provides detailed comments, the
responsibility rests with the author to /engage/ in actual discussion
about them.  Not ignore or summarily reject them.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Aug 2014 22:43:02 +0100

Dave,

> about them.  Not ignore or summarily reject them.

I realise that that is your take on this discussion.
As you know, it is not mine. I do not believe that
I've seen anything summarily rejected. I have seen
the author engaging in actual discussion.

S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 18 Aug 2014 19:29:50 -0400 (EDT)

> improve the text. Thus most of my comments are still applicable.

It looks like Viktor only showed the commit message of
https://github.com/vdukhovni/saag/commit/07e1bd3bd599266b07a162ae56b2e36fa3d4eead
in his email
http://www.ietf.org/mail-archive/web/saag/current/msg05373.html and not a
link to the actual commit itself.  That should help you determine which
parts (if any) of your feedback were ignored.  I, for one, would be
interested in seeing which parts (if any) those are.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 18 Aug 2014 23:25:40 -0400 (EDT)

> needlessly create a new term, which engenders confusion.

I cannot agree that "protocol design pattern" is "needlessly creat[ing] a
new term"; on the contrary, I think it is precisely the right term for
this document.

> existing terminology whenever possible. This doc is a poster boy for failing

I confess I do not remember what other cases of not reusing existing
terminology you have already pointed out earlier in the thread.  Can I
trouble you to repeat a few of them?

> That's an easy question to answer: NO, it is not clear.

I am forced to agree (roughly spreaking) -- the document does not
*clearly* state the points which are being expressed on the mailing list.
(I am working on some changes which help.)  One thing in particular which
does stand out is "encryption" vs. "security", as Dave Crocker has pointed
out.  I do not believe that the *only* thing the document covers is
encryption, but it does seem that encryption is given more weight than it
should for a document claiming to cover the more-generic "security".

> not longer, if it were rewritten to be clear.

I agree that there are some places which are overly verbose and could be
reworked to be more clear.  I will follow up with more concrete
suggestions when I am happy with them.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 18 Aug 2014 23:49:06 -0400 (EDT)

> might pertain to our comments.

You're not, actually; let me give you a link like I did Steve:
https://github.com/vdukhovni/saag/commit/20379d90a2d3d781907d1d79c29c41e2112d0169

> shepherd) have rejected points or summarily declared them in the rough.

I fear that the kind of dialogue you desire, on all the topics that have
been raised, would require more hours than there are in a day.  We're only
human, and this isn't the only thing we're working on.

> about them.  Not ignore or summarily reject them.

Does "I believe that the latest update of the draft accomodates all the
comments that have been made" not qualify?  Bear in mind the above comment
about realistic time expectations.

-Ben

---

From: Dave Crocker <[email-masked]>
Date: Tue, 19 Aug 2014 05:58:37 -0700

On 8/18/2014 8:49 PM, Benjamin Kaduk wrote:
> comments that have been made" not qualify? 

No.

Not even close.

That's a phrase that should only come after detailed and meaningful
discussion about disagreements and concerns.  It should represent a
summary of that discussion and not attempt to replace it.

The idea that it should qualify as a standalone response underscores a
basic disconnect about the nature how work in the IETF is supposed to be
done.

This is not supposed to be a magical process, where an author mystically
decides what to include and what not to include.  This is supposed to be
a community collaboration, with discussion about disagreements.

Claims that such diligent discussion would take too much time are
strikingly at odds with the core process that has produced quality work
here for 45 years.

Thoughtful comments on a document warrant thoughtful responses and
meaningful engagement in resolving differences.

In simplistic terms, this means that "yes" and "no" are far less
interesting than responses such as "I don't understand" and "what about...?"

Folks who think otherwise should consider RFC 7282, and especially
Sections 2 and 3.

d/

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Aug 2014 15:09:49 +0200

Hi Nico,

>>   the end that was anonymous)

Are you saying you want an example of one-sided authentication where
role-reversal #FAILs?

Eliot

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Aug 2014 11:33:08 -0400

Stephen,

> -03 to the earlier on-list discussion.
You are right that I failed to compare the released -03 version to
the pre-release version. When I began to read the released -03 version
I noted that almost none of the suggested changes appeared in the
abstract or in most of section 1, which promoted my reply. But, I agree
that I should have read the rest of the doc before commenting.
Now that I have read the whole doc, I see that Viktor did adopt make changes
reflecting some of my comments, though not consistently. My apologies for
not reading the entirety of the new version before commenting.

Still, I stand by my comments that the doc was still badly written, 
though it
was better in several respects. The fact that some others have commented 
that
they find the quality of the writing to be acceptable does not change 
reality.
I also note that several of those expressing support for the writing 
(not the design
per se) have authored very few RFCs.

> does or does not map to the earlier mailing list

I've done better that than. I have re-written the doc with an
intent to address all of the issues I raised, retaining the
design principles in the latest version, eliminating a lot of redundant 
text,
and using less ambiguous language. The result is much shorter and, in my 
view,
clearer and better organized.

Steve
----------

Network Working GroupV. Dukhovni

Internet-DraftTwo Sigma

Intended status: InformationalAugust 15, 2014

Expires: February 16, 2015

Opportunistic Security: Some Protection Most of the Time

draft-dukhovni-opportunistic-security-03

Abstract

This memo introduces the concept "Opportunistic Crypto-Security"

(OCS). OCS is a set of protocol design principles that attempt to

remove barriers to the widespread use of encryption on the Internet.

OCS is not a protocol. Protocols that adhere to OCS guidelines may

offer additional crypto-security services, e.g., integrity and

authentication, if these services are supported by all parties

to a communication. The OCS design philosophy departs from the

common practice of other Internet security protocols; they commonly

require cryptographic protection against both passive and active

attacks, or offer no protection at all.OCS protocols strive to

offer encryption even if authentication is not available. This

document encourages designs in which cryptographic protection

against both passive and active attacks can be deployed

incrementally, without creating barriers to communication.

Status of This Memo

This Internet-Draft is submitted in full conformance with the

provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering

Task Force (IETF).Note that other groups may also distribute

working documents as Internet-Drafts.The list of current Internet-

Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months

and may be updated, replaced, or obsoleted by other documents at any

time.It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

This Internet-Draft will expire on February 16, 2015.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the

document authors.All rights reserved.

DukhovniExpires February 16, 2015[Page 1]

Internet-DraftOpportunistic SecurityAugust 2014

This document is subject to BCP 78 and the IETF Trust's Legal

Provisions Relating to IETF Documents

(http://trustee.ietf.org/license-info) in effect on the date of

publication of this document.Please review these documents

carefully, as they describe your rights and restrictions with respect

to this document.

Table of Contents

1.Introduction. . . . . . . . . . . . . . . . . . . . . . . .2

2.Terminology . . . . . . . . . . . . . . . . . . . . . . . . .4

3.The Opportunistic Security Design Pattern . . . . . . . . . .5

4.Opportunistic Security Design Principles. . . . . . . . . .7

5.Example: Opportunistic TLS in SMTP . . . . . . . . . . . . .8

6.Security Considerations . . . . . . . . . . . . . . . . . . .9

7.Acknowledgements. . . . . . . . . . . . . . . . . . . . . .9

8.References. . . . . . . . . . . . . . . . . . . . . . . . .9

8.1.Normative References. . . . . . . . . . . . . . . . . .9

8.2.Informative References. . . . . . . . . . . . . . . . .10

Author's Address. . . . . . . . . . . . . . . . . . . . . . . .10

1.Introduction

The development of Opportunistic Crypto-Security (OCS) is motivated

by the concerns raised in [RFC7258]. Pervasive monitoring (as defined

in that RFC) is feasible because of the lack of widespread use of

encryption for confidentiality. Although the IETF has developed many

security protocols (e.g., TLS, IPsec, SSH, ...) that employ encryption

for confidentiality, most of them also require one-way or two-way

authentication. Authentication is mandated by the protocols to protect

against active attacks. If communicating peers are unable to meet the

authentication requirements imposed by these protocols, the result may

be no communication, or plaintext communication.

The ability to authenticate any potential peer on the Internet requires

an authentication mechanism that encompasses all such peers. No IETF

standards for authentication meet this criteria. The Public Key

Infrastructure (PKI) model employed by browsers to authenticate web

servers (often called the "Web PKI" [cite]) imposes cost and management

burdens that have limited its use. The trust-on-first-use (TOFU)

authentication approach assumes that an unauthenticated public key

obtained on first contact (and retained for future use) will be good

enough to secure future communication. TOFU-based protocols, e.g., SSH

[cite] work well in enterprise environments, but were not designed to

scale for Internet-wide use.

DNS-Based Authentication of Named Entities (DANE [RFC6698]) defines a

way to distribute public keys bound to DNS names. It can provide an

alterative to the Web PKI (for other than EV certificates [cite]).

DANE should be used in conjunction with DNSSEC [RFC4033]. At time,

DNSSEC is not sufficiently widely deployed to allow DANE to satisfy the

Internet-wide, any-to-any authentication criteria noted above. Thus

protocols that mandate authenticated communication cannot generally

do so via DANE (at time).

Internet-DraftOpportunistic SecurityAugust 2014

OCS provides a near-term approach to removing barriers to widespread

use of encryption, while offering a path to authenticated, encrypted

communication in the future. The primary goal of OCS is to counter

attacks, consistent with the goals established in [RFC7258]. However,

OCS does not preclude offering protection against active attacks, if

suitable authentication capabilities are available. OCS is not intended

as a substitute for authenticated, encrypted communication when such

communication is already available to peers, e.g., based on TLS, IPsec,

SSH, etc.

To achieve widespread adoption, OCS must support incremental deployment.

Incremental deployment implies that security capabilities will vary

from peer to peer, perhaps for a very long time. Thus use of an OCS

protocol by one peer may yield communication that is unauthenticated

but encrypted, authenticated and encrypted, or plaintext. This last

outcome will occur if not all parties to a communication support OCS

(or if an active attack makes it appear that this is the case). OCS

protocolswill attempt to establish authenticated, encrypted

communication whenever both parties are capable of such, but will

fallback to unauthenticated encrypted communication if authentication

is not possible. Fallback to plaintext communication will occur as

noted above.

OCS protocols do not prohibit the use of local security policies. A

security administrator may specify security policies that override

opportunistic security. For example, a policy might require authenticated,

encrypted communication, in contrast to the default OCS security policy.

The remainder of this document provides definitions of critical terms,

enumerates the OCS design principles/guidelines, and provides an example

of an OSC design, in the context of communication between mail relays.

2.Terminology

Perfect Forward Secrecy (PFS):As defined in [RFC4949].

Man-in-the-Middle (MiTM) attack:As defined in [RFC4949].

Trust on First Use (TOFU):In a protocol, TOFU calls for accepting

and storing a public key/credential associated with an asserted

identity, without authenticating that assertion. Subsequent

communication that is authenticated using the cached key/credential

is secure against an MiTM attack, if such an attack did not

succeed during the (vulnerable) initial communication.The

SSH protocol makes use of TOFU.The phrase "leap of faith" (LoF,

[RFC4949]) is sometimes used as a synonym.

[note that this is still not quite correct. In an enterprise environment it

is common for the enterprise to provide an out-of-band means of 
verifying the
asserted identity, e.g., based on the hash of the public key.]

One-way and Two-way Authentication <fill in>

DukhovniExpires February 16, 2015[Page 3]

Internet-DraftOpportunistic SecurityAugust 2014

3. Opportunistic Crypto-Security Design Principles

As noted in Section 1, OCS aims to remove barriers to the

widespread use of encryption on the Internet. A secondary goal is

protection against active attacks, by enabling incremental

deployment of authenticated, encrypted communication. OCS seeks

to achieve the best protection possible, based on the capabilities

of communicating peers.

1.Determine Peer Security Capabilities: An OCS protocol first

determines the capabilities of the peer with which it is attempting

to communicate. Peer capabilities may be discovered by out-of-band

or in-band means. (Inband determination implies negotiation between

peers. Out-of-band mechanism include the use of DANE records or

cached keys/credentials acquired via TOFU.) The capability phase

determination may indicate that the peer supports authenticated,

encrypted communication, unauthenticated encrypted communication,

or only plaintext communication. (Note that use of out-of-band

capability determine, e.g., DANE or TOFU, is downgrade resistant,

and thus preferred over in-band negotiation techniques. The goal

of this design principle is to maximize the offered security

services on a pairwise, peer basis.

2.Apply Security Policy: Having determined peer security

capabilities, an OCS protocol next applies any local security polices

in addition to the default OCS policy (see below). Local policies may
require security services in addition to encryption, e.g., authentication.
A policy might restrict the set of algorithms that are employed (for 
encryption,
authentication, integrity, etc.) The OCS default policy is simple: 
establish
encrypted communication if possible; authenticate the peer if the 
capability
exists; revert to plaintext if encrypted communication is not possible.
Reverting to plaintext merely because authentication was not possible is
inconsistent with the default policy! However, explicit, local policy
overrides the default OCS policy.

3.Employ Perfect Forward Secrecy:OCS protocols SHOULD employ PFS

to protect previously recorded encrypted communication from
decryption even after a compromise of long-term keys.

4. No misrepresentation of security:Unauthenticated encrypted

communication must not be misrepresented to users (or in

logs) of non-interactive applications as equivalent to

communication over an authenticated encrypted channel. This principle

is consistent with the goal of not encouraging use of OCS in lieu of

protocols that offer additional security services, when such protocols

can be employed successfully.

DukhovniExpires February 16, 2015[Page 4]

Internet-DraftOpportunistic SecurityAugust 2014

4.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

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 the use of STARTTLS

for SMTP protects only against passive attacks.

MTAs that implement STARTTLS establish either an authenticated,

encrypted session or deliver messages over a plaintext channel.

Recent reports [cite?] 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.

The STARTTLS advertisement is vulnerable to active attacks and

some MTAs that advertise STARTTLS exhibit various interoperability

problems in their implementations.As a result, it is common for a

pair of STARTTLS-enabled MTAs to fall back to plaintext

communication when the TLS handshake fails, or when TLS fails during

message transmission.This is a reasonable trade-off, consistent with

OCS principles, since STARTTLS protects against only passive

attacks; absent an active attack TLS failures are simply

interoperability problems.

Some MTAs employing STARTTLS abandon the TLS handshake when the

peer MTA fails authentication, only to immediately deliver

the same message over a plaintext connection.Other MTAs have been

observed to tolerate unverified self-signed certificates, but not

expired certificates, again falling back to plaintext.These and

similar behaviors are NOT consistent with OCS principles, since

they revert to plaintext communication when authentication fails,

instead of employing unauthenticated, encryption, communication.

Protection against active attacks for SMTP is described in

[I-D.ietf-dane-smtp-with-dane].That draft introduces the terms

"Opportunistic TLS" and "Opportunistic DANE TLS"; this draft is

consistent with the OCS design principles defined in this document.

DukhovniExpires February 16, 2015[Page 5]

Internet-DraftOpportunistic SecurityAugust 2014

6.Security Considerations

OCS supports communication that is authenticated and encrypted,

unauthenticated and encrypted, or plaintext. The security services

offered to communicating peers is not reduced by the use of OCS.

This is because the default OCS policy employs the best security

services available based on the capabilities of the peers, and

because local security policies take precedence over the default

OCS policy. OCS is an improvement over the status quo; it provides

better security than the alternative of providing no security services

when authentication is not possible (and not strictly required)

OCS coexists with and is preempted by local, non-OCS security polices.

Non-OCS policies may inhibit use of encryption when many peers cannot

offer authenticated, encrypted communication. Unless authenticated,

encrypted communication is necessary, non-OCS local policies of this

sort run counter to the goals established in [RFC7258].

7.Acknowledgements

I would like to thank Steve Kent.Some of the text in this document

is based on his earlier draft.I would like to thank Dave Crocker,

Peter Duchovni, Paul Hoffman, Scott Kitterman, Martin

Thomson, Nico Williams, Paul Wouters and Stephen Farrell for their

helpful suggestions and support.

8.References

8.1.Normative References

[RFC3207]Hoffman, P., "SMTP Service Extension for Secure SMTP over

Transport Layer Security", RFC 3207, February 2002.

[RFC4033]Arends, R., Austein, R., Larson, M., Massey, D., and S.

Rose, "DNS Security Introduction and Requirements", RFC

4033, March 2005.

[RFC5116]McGrew, D., "An Interface and Algorithms for Authenticated

Encryption", RFC 5116, January 2008.

[RFC5246]Dierks, T. and E. Rescorla, "The Transport Layer Security

(TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC6125]Saint-Andre, P. and J. Hodges, "Representation and

Verification of Domain-Based Application Service Identity

within Internet Public Key Infrastructure Using X.509

(PKIX) Certificates in the Context of Transport Layer

Security (TLS)", RFC 6125, March 2011.

DukhovniExpires February 16, 2015[Page 6]

Internet-DraftOpportunistic SecurityAugust 2014

[RFC6698]Hoffman, P. and J. Schlyter, "The DNS-Based Authentication

of Named Entities (DANE) Transport Layer Security (TLS)

Protocol: TLSA", RFC 6698, August 2012.

8.2.Informative References

[I-D.ietf-dane-smtp-with-dane]

Dukhovni, V. and W. Hardaker, "SMTP security via

opportunistic DANE TLS", draft-ietf-dane-smtp-with-dane-11

(work in progress), August 2014.

[RFC4949]Shirey, R., "Internet Security Glossary, Version 2", RFC

4949, August 2007.

[RFC5598]Crocker, D., "Internet Mail Architecture", RFC 5598, July

2009.

[RFC7258]Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an

Attack", BCP 188, RFC 7258, May 2014.

Author's Address

Viktor Dukhovni

Two Sigma

Email: [email-masked]

DukhovniExpires February 16, 2015[Page 7]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 19 Aug 2014 16:39:29 +0100

Hiya,

> not reading the entirety of the new version before commenting.

Thanks. And thanks for the substantial suggested text.
I'm sure Viktor will process that as soon he can. (I'll
also do a diff of this vs. -03, if you have text in an
easier to diff form that'd be great to send to Viktor,
Paul and I or whack up on a web site somewhere.)

Cheers,
S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 19 Aug 2014 11:45:44 -0400 (EDT)

> Paul and I or whack up on a web site somewhere.)

Yes, can you please post this somewhere?  The formatting got very badly
mandled in the email processing and it is quite hard to read.

Thanks,

Ben

---

From: Dave Crocker <[email-masked]>
Date: Tue, 19 Aug 2014 08:48:28 -0700

On 8/19/2014 8:39 AM, Stephen Farrell wrote:
> also do a diff of this vs. -03, 

attached

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Aug 2014 12:08:54 -0400

Sorry that the doc was mangled by some MTAs.

I have attached a PDF of the doc, which I edited in MS Word, based
on the .txt file as an input.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Aug 2014 12:09:35 -0400

Dave,

Thanks for the diff!

Steve

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 19 Aug 2014 15:05:44 -0400 (EDT)

I'm happy to see that Steve's proposal shares a fair bit of structure with
the changes I have been making, in particular the breakdown into
"determine the peer's capabilities" and then "figure out what to actually
do given that information", which I think is key to helping readers
understand things.

Steve is being very aggressive about reducing verbosity; I'll need a
closer read to see how much of that I agree with.

One thing that I do see from a quick skim is the change to "Opportunistic
Crypto-Security (OCS)" instead of the existing "Opportunistic Security".
I don't think that Viktor (or the group) is likely to adopt that without
the sense that we have a consensus for that term.

Thanks for the rewrite, I look forward to reading it more carefully.
(And thanks as well to Dave for the diff, it is handy.)

-Ben

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Aug 2014 12:40:28 +0200

Personally I like your proposed version, Steve.  It sorts the definition
issue nicely, retaining the already well defined scope.

Thanks.

Eliot

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 22 Aug 2014 15:30:06 -0400 (EDT)

> Thanks for the rewrite, I look forward to reading it more carefully.

Having gotten a chance to read it more carefully, I offer some general
comments.  There doesn't seem much point in offering specific comments,
since Viktor still needs to integrate the proposal and things may change
in that process.

I generally agree with the new text, and find that it adequately
represents my understanding of what has been proposed and fleshed out in
our discussions on the list.  The text is a bit stiff in some places, and
perhaps overly concise, but on the whole still represents an improvement.
I don't think I would object to publishing this text on the grounds that
it is poorly written.

I forget if I have opined on the list about OS vs. OCS or OE or other
terms already, but I will just say that I prefer OS over any of the other
proposals I have seen.

Thanks again for writing this up, Steve.

-Ben

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Sun, 24 Aug 2014 23:10:50 -0400

+1