Subject: Re: [saag] Alia Atlas' No Objection on draft-dukhovni-opportunistic-security-04: (with COMMENT)

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Sep 2014 22:31:15 +0100

On 17/09/14 22:18, Alia Atlas wrote:
> Alia Atlas has entered the following ballot position for
> draft-dukhovni-opportunistic-security-04: No Objection
> 
> 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:
> ----------------------------------------------------------------------
> 
> First, I am quite supportive of a revision of this document going
> forward.  It provides a pragmatic and useful mindset towards mitigating
> pervasive monitoring.
> 
> However, I do support Barry's Discuss.  I have not followed all of the
> discussion on the IETF list about the draft, but enough to feel
> uncomfortable about the interactions.   There can certainly be rough
> consensus but the reaction seems to be more about transparency of what
> and why things were changes.  

Fair enough. We'll be chatting about that tomorrow for sure:-)

> Secondly, I am not fond of the term "Opportunistic Security" as compared
> to "Opportunistic Encryption" if encryption is really all that is meant. 
>  For instance, does OS have the ability to improve over clear-text to
> prevent replay attacks?  That's something that encryption alone doesn't
> necessarily provide; of course, it can also be protocol-specific.  IF
> this is about OS and not OE, I would find it useful to be clearer about
> the dimensions/aspects of security that can be opportunistic.  It
> definitely reads like this is only about opportunistic encryption and
> nothing else.

AEAD ciphers, even with unauthenticated endpoints (i.e. following
the OS pattern) can provide some replay protection, depending on how
they interact with the protocol in question and how counters/nonces
are handled. So yes some form of replay protection can be part of OS
in some cases.

Cheers,
S.

---

From: "Alia Atlas" <[email-masked]>
Date: Wed, 17 Sep 2014 14:18:40 -0700

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Sep 2014 09:20:57 -0700

> draft-dukhovni-opportunistic-security-04: No Objection
...
...
> to "Opportunistic Encryption" if encryption is really all that is meant.

FWIW, OE is already established as a term in RFC 4322, and AFAICT this 
document's definition would not be consistent with that one.

Joe

---

From: Nico Williams <[email-masked]>
Date: Thu, 18 Sep 2014 14:34:15 -0500

On Thu, Sep 18, 2014 at 09:20:57AM -0700, Joe Touch wrote:
> FWIW, OE is already established as a term in RFC 4322, and AFAICT
> this document's definition would not be consistent with that one.

The other reason to not use OE is that "encryption" doesn't denote as
much as "security".  In particular it doesn't denote "authentication",
but OS can provide it -- OS need not always merely ephemeral-ephemeral
Diffie-Hellman key agreement!

Nico
--

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Sep 2014 06:02:02 -0700

> document's definition would not be consistent with that one.

It's not as if that previous usage has gained much community traction,
nor has the work it is part of.   For that matter, the term is not
essential to that work, in spite of being in the RFC's title.  We update
and obsolete specifications; why not do that for terminology that has no
existing momentum?

So it would not be that disruptive to tweak the term for this newer use,
in order to get a label that is obvious and accurate, rather than one
that is obscure and misleading.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Sep 2014 14:05:49 +0100

> that is obscure and misleading.

Please. That has been discussed to death. I really wish folks
(not just you Dave) would stop attempting to find yet another
term that will not garner any better consensus. There is plenty
of mail on exactly this unproductive topic already. I recommend
people who want to suggest new terms go read that.

S.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 19 Sep 2014 09:32:49 -0400

> that is obscure and misleading.

Dave, I agree with you fully, as noted in my ballot comment.

But, as also noted in my ballot comment, this one's been discussed and
settled.  I'm sad about the result, and I think the reasons for the
decision are weak, but on this point I think we *do* have rough
consensus, and you and I are in the rough.

Barry

---

From: Ted Lemon <[email-masked]>
Date: Fri, 19 Sep 2014 09:53:28 -0400

> people who want to suggest new terms go read that.

OS is a lousy acronym.  It means "operating system" or "open source."   It doesn't need a new meaning.   I agree that OE is not the right word, but I disagree that this discussion is useless.   I proposed a better term, "opportunistic protection" in my comment during IESG review.   It's not better spelled out, but it makes a better acronym.  Whether that's worth making a change for I don't know, but saying that there isn't a problem here isn't correct; the question is whether the problem should be addressed by saying "from among the bad choices we have, we prefer OS" or "from among the bad choices we have, we prefer <insert other proposal here>."

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Sep 2014 07:36:17 -0700

...
...
> much as "security".  In particular it doesn't denote "authentication",

In this opportunistic context, any use of authentication is solely in
the service of a better encryption mechanism.  In this context,
authentication has no life on its own.

For all of the many concerns expressed about the writing of the current
draft, this one point is nonetheless entirely clear.

Challenges to the use of 'opportunistic security' continue to be raised
by one person after another, because it's a terrible choice.  This ought
to give pause to anyone claiming that the choice of term has been
'settled'...

d/

---

From: Alia Atlas <[email-masked]>
Date: Fri, 19 Sep 2014 10:44:43 -0400

> to give pause to anyone claiming that the choice of term has been

I am not going to comment further on the selection of the term, whether
opportunistic security or opportunistic encryption.  My concern that
opportunistic security implied more than opportunistic encryption was
answered by Stephen's comment that additional types of security protection
(e.g. replay) could also be opportunistically offered depending upon the
protocol
and be included in the ideas in this draft.

Alia

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Sep 2014 07:50:13 -0700

On 9/19/2014 7:44 AM, Alia Atlas wrote:
>  My concern that 

Except that the existing draft solely discusses encryption (and
authentication in the service of encryption.)

Other possible 'opportunistic' activities might be quite reasonable, but
have nothing to do with the substance of this draft.

One of the continuing challenges in discussing the draft has been
distinguishing what it actually says, from all sorts of appealing but
abstract theories about what the term might refer to.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Sep 2014 16:19:55 +0100

Dave,

> abstract theories about what the term might refer to.

Sigh. Aside from prolonging a discussion where both Barry and I
have asked you to stop and accept the rough consensus and your
bad grace bordering IMO on disruptiveness in continually not
accepting that... you are also just plain wrong above.

Use of authenticated encryption with additional data (AEAD) with
unauthenticated endpoints does provide some replay protection
in some cases. That's a property of the way AEAD ciphers work and
absolutely not abstract since use of such ciphers is something
that would be expected to be a common enough outcome for protocols
following the OS design pattern. (The use of AEAD ciphers was
already discussed as part of exactly this terminology debate though
the replay protection aspect had not been mentioned which is why
I brought that up in response to Alia's comment.)

For background reading on AEAD [1] is a good place to start. The
replay protection aspect would (as I said) depend on the details
of how the protocol following the OS design pattern handled the
nonces/counters needed by the AEAD cipher but in case you're
wondering, if some part of the additional data is maintained in
local state (e.g. a packet reception counter) then replayed
ciphertext will fail decryption. In a real protocol it'd be a
bit more complex, depending on what happens at reboot time and
whether there are ways to resync local state between encryptor
and decryptor. And none of that detail is needed or should be
stated in this draft of course and if someone wants to further
discuss how OS and replay protection interact, please start a
new thread on the saag list since that level of (interesting)
detail is not needed for the discussion of this draft.

Now can we (actually, you Dave;-) stop this distraction and
allow us to move on?

Thanks,
S.

[1] https://tools.ietf.org/html/rfc5116

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Sep 2014 09:22:49 -0700

On 9/19/2014 8:19 AM, Stephen Farrell wrote:
>    . you are also just plain wrong above.
> 

This is a really excellent example of just how muddled discussion of the
draft has been.  Thanks for demonstrating it so well.

The string 'replay' does not appear in the draft.

As I said, the broader implications of the term could be reasonable, but
they have nothing to do with the substance of the draft.

The draft is about encryption.  Period.  Full stop.

Hence the broader term confuses the focus and utility of the draft.

d/