Subject: draft-dukhovni-opportunistic-security-04

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

Folks,

A new version of the draft was issued today.

And the Sponsoring AD promptly decided that there is IETF consensus on
the draft, scheduling it for the next IESG telechat.  The Sponsoring AD
has deemed all changes since the -02 version is minor.

This is spite of the fact that /nearly every word/ of the newest draft
is new.

Yes, really:

https://www.ietf.org/rfcdiff?url1=draft-dukhovni-opportunistic-security-03&difftype=--hwdiff&submit=Go!&url2=draft-dukhovni-opportunistic-security-04

I did another detailed review of the draft:

     http://www.ietf.org/mail-archive/web/saag/current/msg05531.html

including:

> Summary:
> 
>    The paper defines and explains flexible approach to the use of
> encryption on the Internet.  It assigns the term 'opportunistic
> security' to this term.
> 
>    The latest draft has extensive changes from the previous version.
> 
>    Although many of the changes are quite helpful, the document still
> suffers from confusing or unexplained terminology and some unfortunately
> initial organization.
> 
>    A number of points from previous reviews have not been addressed.
> 
>    The paper continues to freely make strong assertions, without
> providing any substantiation or even, in some cases, explanation.  At a
> minimum, every term that is used, every assertion that is made and
> anything else that derives from Internet experience should be documented.
> 
>    Concerns with the term "opportunistic security" persist.  It is both
> vague and overblown, given the specific technical point it is meant to
> address.  That concern is about encryption and the term should make that
> clear.
> 
>    The paper still needs extensive revision before it should be
> considered for publication.

Blanket dismissal of substantive concerns is not the usual approach to
work in the IETF.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: <[email-masked]>
Date: Wed, 27 Aug 2014 07:17:13 +0000

"Blanket dismissal of substantive concerns is not the usual approach to
work in the IETF."

It's been the norm ever since perpass and RFC 7258. Because... security!

Security work gets a free pass.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf <[email-masked]> on behalf of Dave Crocker <[email-masked]>
Sent: Wednesday, 27 August 2014 2:12:19 PM
To: IETF Discussion
Subject: draft-dukhovni-opportunistic-security-04

Folks,

Yes, really:

d/

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Aug 2014 10:58:13 +0100

Dave,

(This exchange is mostly a repeat of a mail Dave sent to the
saag list in [1], to which I responded in [2]. But its fair
enough to comment to this list as well I guess.)

You say "promptly decided." That is incorrect. I had sent
a mail to this list last Friday, at the end of the extended
IETF LC, saying that was the plan. (See [2])

Your "blanket dismissal" point is nonsense. There were
literally hundreds of mails about this draft, many of them
from you and many responding to you. I have concluded that
you are just in the rough when it comes to the non-editorial
comments you have made on -04. (All of which you also made
a number of times before I believe and all of which have
been responded to by the author or others as far as I can
see.)

Yes, the diff between -03 and -04 is unusually large. However,
I consider it editorial and for a short informational document
like this, while that's unusual, I think it is ok. And the
changes as far as I can see do reflect the list discussion
since -03 was published.

There is also at this point maybe more risk of damage being
done by endless editorial nitpicking than by proceeding to
IESG evaluation with text that I believe captures the rough
consensus, which is not very rough at all for the meat of
the topic, but is certainly rougher for the specific text.

S.

[1] https://www.ietf.org/mail-archive/web/saag/current/msg05528.html
[2] https://www.ietf.org/mail-archive/web/saag/current/msg05533.html

---

From: Paul Wouters <[email-masked]>
Date: Wed, 27 Aug 2014 11:48:59 -0400 (EDT)

> Subject: draft-dukhovni-opportunistic-security-04

ExecSum: The document sits between a "generic advise" and "specific
protocol recommendations" and accomplishes neither. The definition
is unclear and the used language makes this document hard to read,
especially for non-native English speakers.

> This is spite of the fact that /nearly every word/ of the newest draft

While that in itself isn't a problem, as Stephen said when talking about
a two page RFC of this kind, I do find most of my textual changes that
I proposed to make the document more readab le have been rejected for
far more prosaic fluff language:

    Broadly speaking, Opportunistic Security (OS) is a pragmatic risk
    management approach.  With Opportunistic Security, one applies the
    tools at hand to mitigate the risks that can reasonably be addressed,
    and accepts the rest.

    Definition:  In the context of communications protocols,
       "Opportunistic Security" is defined as the use of encryption when
       possible, with authentication when possible.  In the above, the
       phrase "when possible" means when support for the corresponding
       capability is advertised by the peer, ideally in a downgrade-
       resistant manner.

This in my opinion is not very good text at all compared to much
simplier phrasing. Especially in light on non-native English speakers.
Doubly so for being the introduction text of the document.

I'm also really unhappy about language like:

 	this risk is consistent with the expected level of protection

 	This last outcome [...]

 	if and when all but a negligible fraction [...]

 	In essence, [...]

 	This document proposes a change of perspective. [...]

 	Now, with OS, the new viewpoint is that without specific
 	knowledge of peer capabilities (or applicable local policy),
 	the default protection is no protection, and anything more than
 	that is an improvement.

 	In this document, the word "opportunistic" carries a positive
 	connotation. [...]

 	In such a situation [...]

While "design principle" is a better choice compared to the previous
"design pattern", I still feel it is working around defining a precise
and concrete definition.

I still find the definition of OS to be unclear. It roughly means "use
existing auth/encr protocols, but try unauthenticated encryption in their
absence" but it is unclear when "other protocols" stand on their own
and when those other protocols are "part of OS". Which again comes down
to this really being opportunistic encryption, but people are afraid
of moving towards a definition defining "if other protocols offer no
authenticated encryption, try to throw in unauthenticated encryption".
Because then it becomes clear we are talking about "OE" and not "OS".
So OS keeps including and excluding the "other protocols" throughout
the document.  Example:

 	Opportunistic security protocols may hard-fail with peers for which a
 	security capability fails to function as advertised.

This clashes with the idea that OS must always soft-fail, because the
above listed "advertised capability" is really the "other protocol"
part. Eg, if DANE is used, we have an authenticated protocol, and "OS"
does not really apply at all. The "Opportunistic" part is really a MUST
for soft-fail. That is, if OS is a protocol addition or protocol feature
(or design principle) of unauthenticated encryption, it never hard-fails.
The text does state that, but doing so while squirming around the
definition.

A new section 5 was added that states:

 	OS protocols may need to employ "fallback", to work-around a failure
 	of a security mechanisms that is found in practice to encounter
 	interoperability problems.

This really sabotages the entire document. Again, because the term OS
is unclear. Should my "OS enhanced" IMAP authenticated channel stop using
encryption when there are interoperabilty problems? This documents
suggests that might be valid. If it is making a statement about the
mandatory encryption part of other protocols, it should not even make
any statement regarding applying work-arounds.

 	When protection only against passive attacks is negotiated over a
 	channel vulnerable to active downgrade attacks, and the use of
 	encryption fails, a protocol might elect non-intrusive fallback to
 	cleartext.

Apart from the hard to read sentence, "might elect" ? And seeing there
is non-intrusive fallback, is there intrusive fallback? What does this
even mean? The "design principle" is to give to user LESS toggles, but
this text just ADDS another security toggle. I thought "OS" was all
about adding security opportunisticly without needing the user or
toggles.

In my opinion, this document needs a lot of work. There needs to be
agreement on what it is trying to say, and needs better text saying
that. What this really comes down to, is that one is better of not
reading this 6 page document and telling protocol designers:

 	In absence of authenticated encryption, use un-authenticated
 	encryption with fallback to cleartext, transparent to the user.

That should be a 1 page RFC.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Aug 2014 13:40:13 -0400

> especially for non-native English speakers.

I agree, good summary of the problems.

I decided to hold my nose: it's only going to be succesful in the first case,
but the author seems bent on doing the second.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dave Crocker <[email-masked]>
Date: Sat, 30 Aug 2014 11:04:59 -0700

Folks,

On 8/27/2014 2:58 AM, Stephen Farrell wrote:
> from you and many responding to you.

This fails to distinguish between activity and substance response.  In
fact, Stephen's note here is a good example of this continuing problem.
 He can count it as a response, but it ignores or dismisses all of the
substantive points I raised.

That's been the pattern throughout the development and discussion of
this document.  Stephen has posted quite a number of notes that
similarly dismiss concerns and assert consensus, in spite of no
management effort to track and resolve concerns that are raised.

And there remain some very basic issues with the document:

   1. The latest version (-04) has almost literally no text in common
with the previous (-03). It's likely that 90-95% of the text is different:

      By itself, that should warrant re-issuing a last call and
requiring thoughtful comments on it.    No matter how the changes were
made, classing that amount of new text as merely 'editorial' as Stephen
has done, is absurd.

      And for at least the last two versions of the document, the author
provided no audit of what prompted the changes, relative to the comments
he received.  Rather, those with concerns were each left to do their own
audit.  Each time.

   2. Just in this recent versions, there has been a range of
substantive concerns raised.  None has received substantive responses,
and especially not from the document author.

      Stephen is classing these as nitpicking.  Others got fond of
classing them as bikeshedding.  All of this serves to marginalize
serious comments from serious participants.  Again, it's been the
pattern throughout the life of this document.

      A brief list of pointers to exemplar messages is at the end of
this note.  (And these are only drawn from the latest rounds with the
draft, but the pattern extends to its beginning.)

   3. The author and quite a few others continue to demonstrate very
basic confusion about use of the term.  If even they cannot use it
consistently and provide an explanation that matches that use, then what
is the benefit of the term?

      The author's use of the term "opportunistic DANE" is an example of
the confusion.  "Opportunistic TLS" probably makes sense.  Opportunistic
DANE does not.

Suggestion:

   Merely as a basic exercise to create some semblance of legitimate
IETF constructive discussion, I suggest that the author be directed to
respond to at least the list of postings provided below and to engage
meaningfully in resolving the concerns expressed in them.

d/

- - - - - - - -

Comments and questions that have been ignored, just on the latest drafts:

IETF list:

   Eliot Lear:
     https://mailarchive.ietf.org/arch/msg/ietf/2so5XvtE92x-JxeXoThJuhGn3pk

   Paul Wouters:
     https://mailarchive.ietf.org/arch/msg/ietf/ZNn9XD8uIUnC7eVrFr-jkCI82D8

   Benjamin Kaduk:
     https://mailarchive.ietf.org/arch/msg/ietf/NOe_YK4mBkL2J9DvZdZxRlBTk-Y

   Bernard Aboba:
     https://mailarchive.ietf.org/arch/msg/ietf/nGXy1kOYaNCZWvstaBTE3Rznrxw

   Dave Crocker:
     https://mailarchive.ietf.org/arch/msg/ietf/aXmkdlsmc-n-vJMWTk5RAnZdOsk

   Paul Wouters:
     https://mailarchive.ietf.org/arch/msg/ietf/wgYWDEG_9DVEBpEjwJnzO4tyPCY

   Michael Richardson:
     https://mailarchive.ietf.org/arch/msg/ietf/gVMFfaIcPJYxMKLICA6UEwc2vXg

SAAG list:

   Eliot Lear:
     http://www.ietf.org/mail-archive/web/saag/current/msg05534.html

   Dave Crocker:
     http://www.ietf.org/mail-archive/web/saag/current/msg05536.html

   Steve Kent:
     http://www.ietf.org/mail-archive/web/saag/current/msg05418.html

   Eliot Lear:
     http://www.ietf.org/mail-archive/web/saag/current/msg05464.html

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 30 Aug 2014 20:43:49 +0100

Dave,

On 30/08/14 19:04, Dave Crocker wrote:
> This fails to distinguish between activity and substance response.

Just for the record really, and as I have previously
stated, I do consider that all the substantive points
you raised were responded to properly. A number of
changes were made as a result, but in other cases,
changes you would presumably like to see were not made.

I also consider that you are basically just re-iterating
the same points, on which I consider you in the rough,
and you have raised no new issues.

I do get that you don't agree with the above, though
I do not have any clue how you don't also spot the
repetitive nature of your recent mails on this draft.

S.

PS: Before and in case you ask, no I do not plan to
provide a forensic analysis of the threads resulting
from all the links you sent. I already summarised the
LC to the list a couple of times.

---

From: <[email-masked]>
Date: Sun, 31 Aug 2014 01:17:59 +0000

Dave,

while I applaud your efforts and the efforts of the posters you cite, the fact remains that security rules the IETF these days, and so the security directorate rules the IESG. There is consensus because the security directorate has decreed there is consensus. So, this document, which concerns security, will get published. There is no remaining oversight.

Thus, there is little point in standing in front of the security steamroller for this particular document.  Our one remaining hope is that this document, like so many other IETF RFCs, is simply ignored by the larger outside world. And that goes for any other security document getting fast-tracked through.

A better question would be how to bring more oversight to and use of feedback in the larger process that produces these documents - but that's a governance issue, and likely also a lost cause.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf <[email-masked]> on behalf of Dave Crocker <[email-masked]>
Sent: Sunday, 31 August 2014 4:04 AM
To: Stephen Farrell; IETF Discussion; iesg
Subject: Opportunistic Lost (was Re: draft-dukhovni-opportunistic-security-04)

Folks,

Suggestion:

d/

- - - - - - - -

IETF list:

   Eliot Lear:

   Paul Wouters:

   Benjamin Kaduk:

   Bernard Aboba:

   Dave Crocker:

   Paul Wouters:

   Michael Richardson:

SAAG list:

   Eliot Lear:

   Dave Crocker:

   Steve Kent:

   Eliot Lear:

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 31 Aug 2014 12:39:57 +0200

Hi Dave,

I read your comments below, and I did not read the draft. I don't
understand your suggestions related to draft and your edit recommendations
are not clear so I can vote on. IMHO if you want to get changes done you
need to clarify your amendments to the draft. So community or IESG can make
decision per point.

I will wait for your clear request changes for me to vote.

My comments below;

> substantive points I raised.

I suggest sending one post per clear point (with sequence number of
poster) with suggestion of change. It will be easier to track. You need to
count your points and then reference it, example; Dave-comment#1, #2, ...

> management effort to track and resolve concerns that are raised.

It is the job of the community to have a tracking tool, or you make one by
your sequence number input on the message-subject. Some participant may
make noise out of subject per post but you should maintain your
transmissions and authors must respond to your posts.

> And there remain some very basic issues with the document:

The issues need your suggestions to solve draft-errors and the community or
IESG will make decisions.

> he received.  Rather, those with concerns were each left to do their own

I agree that this is not good process, which is the responsibility of the
draft's AD to adjust or advise.

> pattern throughout the life of this document.

I don't know what serious participants mean, I need clear suggestions from
serious participants. If a serious participant says "the draft is difficult
to read" that is not serious. If a serious participant says "the draft's
terms need change" without giving changes, that is not serious. We need to
get efforts clear in IETF for progress. IMHO I see many of your serious
participants not serious in giving clear points, and I may be wrong.

> draft, but the pattern extends to its beginning.)
I read the points but they are difficult to understand, I need clear
recommendations of changes per text.

> the confusion.  "Opportunistic TLS" probably makes sense.  Opportunistic

This is clear point but you need to recommend clearly to change to
"opportunistic TLS" . Each point discussed separately will help focus.

> meaningfully in resolving the concerns expressed in them.

My experience with authors show that IETF still needs training for authors
and editors. The ADs and WG chairs are responsible for such problem. Your
suggestion point above is not only for this draft but for the process of
LCs. Again I need clear suggestion for the draft because my responsibility
is only to vote on your points in this LC.

Best Regards,

AB

>
>  /
> <https://mailarchive.ietf.org/arch/msg/ietf/2so5XvtE92x-JxeXoThJuhGn3pk>
>
>
>
>

---

From: Theodore Ts'o <[email-masked]>
Date: Sun, 31 Aug 2014 12:20:11 -0400

On Sun, Aug 31, 2014 at 01:17:59AM +0000, [email-masked] wrote:
> 
> while I applaud your efforts and the efforts of the posters you
> cite, the fact remains that security rules the IETF these days, and
> so the security directorate rules the IESG. There is consensus
> because the security directorate has decreed there is consensus. So,
> this document, which concerns security, will get published. There is
> no remaining oversight.

Consensus != unanimity.  And it is the duty of the working group chair
and the area directory to determine whether rough consensus has been
reached.  If someone consistently addresses the same arguments,
ultimately someone has to make a choice about whether or not consensus
has been reached.  So in fact, this is how things are supposed to
work.

There is oversight, which is the established appeal process, but
ultimately, it might be useful to remember the fact that a decision
was reached that happens to disagree with your particular opinion does
not necessary mean that there was a process violation.

Cheers,

					- Ted