Subject: [saag] Adrian Farrel's Abstain on draft-dukhovni-opportunistic-security-04: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 15 Sep 2014 10:13:34 -0700

Adrian Farrel has entered the following ballot position for
draft-dukhovni-opportunistic-security-04: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It is good and helpful, in my opinion, for the IETF to give an 
explanation of Opportunistic Security and advocate its use.

The data tracker currently shows "Consensus: Unknown" and I think that
is actually a fair representation of the state of affairs. It is,
however, not a state in which we can publish an IETF Stream RFC.

Having read a lot of the email thread resulting from IETF last call
and looked at the changes in the last few revisions I conclude that
there is general support for the technical content of this document,
but that there are a good number of unaddressed issues with the 
development and presentation of that content. It may be true that
addressing those points would not make a substantive difference to the
technical ideas in the document, but that does not mean that the
document would not be improved by attentive work.

At the moment I am sufficiently unclear on the consensus for the  
publication of this document to be either able to place a Discuss on
the absence of consensus or to be able to ballot No Objection. Hence
this Abstain.

I wish more work had been / would be done to build consensus or that
the document was advanced either as "published without consensus" or
on the Independent Stream.

==========

I have spent too long hanging around with sales staff and this has made 
me over-sensitive to the use of language that smells of marketing. I
apologise for any over-reaction on my part, but I presume that the 
purpose of publishing the document is to deliver a useful and clear
statement, so I think that polishing might not be a waste of time.
If I was entering this Comment as part of IETF last call I would expect
a reasonable discussion of the cost/benefit of not changing the text to
address my thoughts. But, obviously, I am not. Furthermore, I am not 
raising these points as Discusses so you can work through them with your
shepherding AD and ignore me if you think that I am wrong or that the 
effort is not worth the results.

- - - -

Abstract...

   Protocol designs based on
   Opportunistic Security remove barriers to the widespread use of
   encryption on the Internet by using encryption even when
   authentication is not available

So, this says "remove barriers to X by using X".
I think there is probably something additional you need to say before
this sentence. For example, "Most approaches to the use of encryption
on the Internet depend on the use authentication to foo.  This makes
encryption unattractive because bar."

---

Introduction

   Broadly speaking, Opportunistic Security (OS) is a pragmatic risk
   management approach.

"pragmatic" is redundant in the description of "risk management".

"...approach" to what?

---

Introduction

   With Opportunistic Security, one applies the
   tools at hand

This implies to me that no changes or modifications to protocols are
needed to achieve OS. I don't believe that is true.

---

The definition presented in Section 1 is OK as far as it goes, but 
isn't it missing also the existence of the capability in the protocol
itself?

Isn't a fundamental part of OS that the operation of encryption can be
without manual keying and therefore without the configuration of 
security adjacencies? I think that what is missing from this document,
and possibly from this definition, is a description of why security
(specifically encryption) is not widely used in the Internet today.

It is also a little questionable to me what is "opportunistic" in this
definition. You seem to be defining "Best Effort Security". Hey-ho. It's
only a name, and just words.

---

Introduction

   Since encryption alone mitigates only
   passive attacks, this risk is consistent with the expected level of
   protection.

"Since encryption alone..." can be read two ways:
1. Only encryption can do this
2. Using only encryption with nothing else can only go so far
I suggest you make some clarification to remove this ambiguity.

"this risk is consistent with the expected..." I don't think so. I think
the risk defines the level of protection that can be delivered. 
Expectations need to be set and this document can do so by describing 
the risks and the likelihoods.

---

   For authentication based on peer capabilities to protect
   against MiTM attacks, capability advertisements need to be over an
   out-of-band authenticated channel that is itself resistant to MiTM
   attack.

I had a lot of trouble parsing the first clause in this sentence. Is it
the peer capabilities that can protect against MiTM attacks? Or is it 
the authentication that does the protection? I think you are saying...
   In order that authentication mechanisms can protect against active
   MiTM attacks on capability exchanges between peers, those capability
   exchanges need to be performed over...

But why are you insistent on an out-of-band channel? Surely any 
authenticated channel that is resistant to MiTM attacks will be good
enough?

---

   OS protocols will attempt to establish encrypted communication
   whenever both parties are capable of such, and authenticated
   communication if that is also possible.  This last outcome will
   occur if not all parties to a communication support encryption (or if
   an active attack makes it appear that this is the case).

Is there any element of choice here? The text says not.

---

   For a particular protocol or application, if and when all but a
   negligible fraction of peers support encryption, the baseline
   security may be raised from cleartext to always require encryption.
   Similarly, once support for authentication is near-universal, the
   baseline may be raised to always require authentication.

I don't know what this means!
I think it says that at some moment in time the Internet Police will 
ban the use of unencrypted use of a protocol or application. Or maybe
it says that new implementations can require encryption and refuse to
operate with legacy implementations. Or perhaps you mean that the
default behaviour should be to try for encryption. Or perhaps you are
just talking about what the user can expect.

---

The abbreviation "CA" is used without expansion.

---

Section 1.1

   DNSSEC is not
   sufficiently widely deployed to allow DANE to satisfy the Internet-
   wide, any-to-any authentication requirement noted above.

Did I miss the any-to-any requirement? I looked back but didn't find it.

---

Section 1.1 makes a good case about encryption without authentication
being of value. But this seems to be making a different (although 
equally valid) case from the basis of the document that is about OS.
This comes back to the "opportunistic" versus "best effort" thing.

---

Section 1.1

   The use of encryption defends against pervasive monitoring
   and other passive attacks (which are employed not only by nation
   states).

The parenthesised text can probably be dropped. It is not a discussion 
you need to have here.

---

Section 1.1

   For some applications or protocols the set of potential peers
   includes a long tail of implementations that support only cleartext.

On third reading I got what the "long tail" refers to. How about...

   For some applications or protocols it is anticipated that the set of
   potential peers that only support cleartext will persist for a long
   time.

---

Section 1.2

   This document proposes a change of perspective.

Why is it a proposal in what you plan to publish as an IETF Consensus
RFC? I assume you don't really want this to be Experimental.

---

I am fine with the concept of opportunistic security and like it. But
I think I reject the hypothesis in Section 1.2 that the old world is
"expect full security and notify when not achieved" and that the new
world is "expect no security and get the best you can." I think the new
world is / should be "configure the level of security that is acceptable
to you, get at least that security and maybe better, or get notified if 
it is not as good." This is more subtle than your proposal but involves 
the user in a way that I think is important. That is, if a user desires 
security, it is not enough to say "the protocol is designed to get as
much security as it can" - the user actually wants to know if the
security level is low, and may want no traffic if the security level is
too low.

This does not reject the idea of OS, but merely the choice presented in
Section 1.2.

In fact, Section 3 makes these trade-offs pretty clear, so I think
that all that is needed is to moderate the language in this section.
(Although Section 5 seems to favour some sort of autonomy within the 
protocol or protocol implementation such that various fallbacks might
"just happen".)

---

Section 3

   OS provides a near-term approach to counter passive attacks by
   removing barriers to the widespread use of encryption.

This is probably true, and definitely a motivation, and not a Design
Principle. Not appropriate in this section of the document.

---

Section 3

I had to read "Emphasize enabling communication" and the following text
a couple of time to extract the right meaning. What you have has two
different meanings, and you mean "enablement of" (otherwise "an 
enabling communication" is inferred).

---

Section 5 has...

   The choice
   to implement or enable fallback should only be made in response to
   significant operational obstacles.

...but no mention of who makes the choice for enablement. I think you 
need that such fallback is never a default action and always requires
operator/user intervention since forcing such a fallback sounds like an
effective attack.

---

One point that I would possibly have entered as a Discuss were I not
Abstaining is that I am surprised that there is no discussion of 
mechanisms that can be used to detect MiTM attacks on unauthenticated
encryption key exchanges. Detection is a useful tool since, while it 
can't help with protection of data, it can at least warn the user to 
stop relying on the security of the data channel.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Sep 2014 11:43:34 +0100

Hiya,

Thanks for the detailed review.

> http://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/

We should just get rid of that checkbox, which as you know is
only about boilerplate text selection and is misleading in
many ways, including the new one you've now just invented:-)

> development and presentation of that content. 

Actually I do not agree that those were not addressed and I claim
that is apparent if one reads all the many LC mails and the various
versions of the draft. I think it is entirely fair to say that the
consensus for the specific text is rough, with some people in the
rough who were significantly invested in the LC. That does not mean
that concerns were not addressed.

If there are specific points raised that were never addressed
then I would be very interested in those. That is however, not the
same as a point having been repeatedly re-raised after having been
addressed some time previously. Mails that re-raise such issues
do not IMO deserve a blow-by-blow response every time they are
sent. And nor do all editorial suggestions especially when the
editor is faced with multiple overlapping and sometimes conflicting
suggestions from different folks.

> It may be true that

My take of the diffs between -02, -03 and -04 is that we have in
fact being going sideways. I see no reason to assume that would
change by extending the IETF LC. (IESG evaluation comments might
help there though I hope, since you all have been less involved
in the LC. And yes, that's not supposed to be how we fix stuff
like this, but perhaps in this case its the best we can do.
Apologies for abusing your time like that to the extent I am;-)

> the absence of consensus or to be able to ballot No Objection. Hence

That's a comprehensible position I guess. Seems like a bit of an
innovation in the semantics of abstain ballots, but innovating like
that is fine by me.

> on the Independent Stream.

I also wish we had a less rough consensus, and am partly to blame
there, sharing that blame with all of those heavily involved in
the LC). I do not agree at all that "roughness of consensus on
the text" as we have here implies taking the ISE route is a good plan.
In this case the ISE route would not be a good plan.

Once we have the full set of ballots I'll work with the author and
shepherd to handle your comments below. Some of 'em are very good
(I don't think MITM detection was raised during the LC, though it
is research-level tricky in the general case), other ones seems
just fine (modulo the "going sideways" point) and yet others might
need a bit of back and forth better done when we've a full set of
comments.

Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 18 Sep 2014 15:42:20 +0100

Hi Adrian,

More detailed initial responses below. (From Viktor as marked).

> So, this says "remove barriers to X by using X".

More: "remove barriers to X using *X even without Y*"

> encryption unattractive because bar."

Not sure if we really need it in the abstract as its in the body
I think. (It does need saying, just not sure if twice.)

> "pragmatic" is redundant in the description of "risk management".

Disagree. Insisting on mutual authentication of all sessions is
(historically) considered a valid approach to risk management (by
us:-) but is less pragmatic than OS.

> "...approach" to what?

I think the phrasing is clear. Is that just a wording preference
or do you think its really not clear?

> needed to achieve OS. I don't believe that is true.

TLS is a tool. Modifying how TLS is used with HTTP to follow the OS
pattern as is being considered by httpbis does involve using the
tools at hand and also involves change.

So I don't get how you draw that implication tbh. You are correct of
course that changes are needed when following the OS pattern.

> isn't it missing also the existence of the capability in the protocol

Not sure what that means if its not what's in the next para.

> (specifically encryption) is not widely used in the Internet today.

Hmm. Sorta. I'm not sure fundamental is correct, nor that we need to
identify and describe all the fundamental parts of OS, nor decide
exactly what is fundamental and what is not.

The draft already does say that we lack an Internet-scale key management
scheme, which is the point you're making I think. I'm not sure it'd be
a good idea to call out one aspect of that as you've done above since
there are others arguably equally fundamental (what authorities to use,
how to revoke bindings, how to discover capabilities and keys etc.).

> only a name, and just words.

I don't think we'll benefit from talking other terms.

> I suggest you make some clarification to remove this ambiguity.

Ack. #2 is clearly what's meant but sure.

> the risk defines the level of protection that can be delivered. 

Not in the usual sense in which the term risk is used in security, no.

> the risks and the likelihoods.

I don't know what you mean there sorry. (Maybe due to the above for
me odd use of the word risk.)

> authenticated channel that is resistant to MiTM attacks will be good

Viktor said:

Neither of the above alternatives are it.
"authentication based on peer capabilities" is intended to be read
as a single long compound noun.  The intended meaning is then:

    When authentication is used only if advertised by the peer,
    protection against MiTM attacks requires that the advertisement
    be over an out-of-band authenticated channel ...

Because active attacks on the the advertisement can otherwise strip
or modify the authentication capability data and then compromise
the communication with the peer.

> Is there any element of choice here? The text says not.

You take "will attempt" as the same as MUST? I don't think that is
the intent. Maybe s/will attempt/attempt/ would work?

> just talking about what the user can expect.

Viktor says:

RFCs updating the protocol may then specify that implementations
should not support cleartext, and correspondingly updated
implementations will then refuse to communicate in cleartext (based
on presumptively near-universal support for encryption even among
legacy peers).

> The abbreviation "CA" is used without expansion.

Ack.

> Did I miss the any-to-any requirement? I looked back but didn't find it.

Its arguably implicit in an Internet scale key management scheme,
but could be made expicit or this re-worded yes.

> This comes back to the "opportunistic" versus "best effort" thing.

I'm not getting the import of that comment.

> The parenthesised text can probably be dropped. It is not a discussion 

True. OTOH, its no hard. (I can't recall it it was added because of
some earlier comment.)

>    potential peers that only support cleartext will persist for a long

Sure, that'd be fine.

> RFC? I assume you don't really want this to be Experimental.

I think the text is clear there.

> protocol or protocol implementation such that various fallbacks might

I'm not clear what you mean by moderate. And we definitely don't
want to say "user" too often or in the wrong places (that and
UI issues have been discussed a lot already). So I'm not sure what
changes here might help.

> Principle. Not appropriate in this section of the document.

I disagree. But am maybe less concerned at Design Principle being
strictly interpreted. But I agree that the 1st 2 sentences in
section 3 could be moved elsewhere.

> enabling communication" is inferred).

Ack.

> operator/user intervention since forcing such a fallback sounds like an

Viktor says:

It is difficult to be prescriptive here.  With SMTP, fallback from
STARTTLS (after handshake failure) to cleartext is often automatic
(default MTA behaviour).  It is not expected that defenses against
passive attacks are immune to active attack.  However it may be
reasonable to give users/operators the choice to override default
behaviour by enabling or disabling fallback as appropriate.

Stephen says:

I thought the "who" was clear given the section title, but it'd be
fine to clarify that I think. I'm less sure one can confidently
say that such fallback is "never a default" as there might be
cases where some algorithm would be fine.

> stop relying on the security of the data channel.

Viktor says:

Specific recommendations are difficult.  I think that any such
mechanisms will be significantly protocol/application specific.
One might encourage protocol designers to consider the issue.

OS will be primarily used where nothing better than cleartext is
expected, and warnings of MiTM attacks on unauthenticated encryption
may be counter-productive if more often than not the cause is
routine key rotation by the peer.

Stephen says:

I think some text there would be good, but we should be cautious
to not say that e.g. just because D-H is used, one can easily
catch a MitM post-facto. (In the general case there are tricky
issues with that.) But there will be cases where some later
OOB communications could post-facto catch an otherwise
successful MitM attack.

Cheers,
S.