Subject: Adept Encryption: Was: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment)

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 20 Aug 2014 18:12:40 -0400

Opportunistic is the wrong word to use because

1) It is used already and has an existing meaning.
2) It short changes authenticated credential approaches such as DANE and PKIX.

Adept is a much more appropriate term to describe an approach that
essentially says

1) Determine the set of available keys by algorithm X.
2) Determine the set of keys that meet the security policy by algorithm Y.
3) The set of acceptable keys is the intersection of X and Y and the
preference within that intersection is determined by algorithm Z.

---

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

> Adept is a much more appropriate term to describe an approach that

The problem with adept is that for non-native English speakers, it is
not very clear what the differences are between adept and adapt (and
possible adopt)

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Aug 2014 02:18:29 +0100

Personally, I think the probability that we suddenly discover
any significantly better term is negligible. Not because OS
is super-good, but rather because nothing is super-good. And
good-enough should be good-enough here.

In fact, I'd say so its so negligible that attempting to find
such (yet again, maybe for the 8th time?) is counterproductive.

But that doesn't stop folks genuinely trying seemingly, I guess
its too tempting a windmill at which to tilt;-)

But I'd appeal to others to consider this before they chime in
here: is your suggestion really that much better that everyone
will immediately say "yeah, that's the one we wanted!"? If not,
them maybe there's not much point in suggesting it.

S.

---

From: Nico Williams <[email-masked]>
Date: Wed, 20 Aug 2014 20:27:51 -0500

> good-enough should be good-enough here.

+1.

OS is not an awesome term.  My hope is that OS will become part of the
broader culture, just like "SSL" and "TLS".  That means that the term
has to be accessible, even if that means it has to be terse.  If OS
does not become part of the broader culture then the term won't burden
us much more than any other term we could pick instead, because it
will at the very least become part of IETF culture.

Once we're accustomed to a term, the fact that others could have been
picked becomes mostly unimportant, and any imperfections of the term
we do pick will not be a burden (because we'll be used to them).

> such (yet again, maybe for the 8th time?) is counterproductive.

Near as I can tell there are no remaining substantive objections to
Viktor's draft, only ones related to wordsmithing, writing style, and
the name we'll give to this concept.  All of these are a flavor of
bikeshedding.  We should stop arguing about such things, make just one
more small effort to adjust Viktor's prose, and publish.

Nico
--

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Aug 2014 18:45:00 -0700

On 8/20/2014 6:18 PM, Stephen Farrell wrote:
> Personally, I think the probability that we suddenly discover any 
> significantly better term is negligible. Not because OS is 
> super-good, but rather because nothing is super-good. And

While there has been repeated, quick dismissal of alternative terms, I
don't recall seeing a careful consideration of candidates, with a clear
explanation for the choice(s) made, making clear why it is better (or
why its deficiencies are less onerous than those of the alternatives.)

The problems with 'opportunistic' and with 'security', relative to the
actual content of this draft, have been pointed out repeatedly.  They
are significant.

Rather than again casually waving away a suggested alternative, could we
see a summary consideration of choices, please?

> In fact, I'd say so its so negligible that attempting to find such 
> (yet again, maybe for the 8th time?) is counterproductive.

This suggests a view that vocabulary choice does not matter all that
much.  For an audience of technical insiders, that's probably true.
Provide definitions and those folk will adjust.

For a wider audience, words carry quite a lot of baggage and so the
choice of terminology matters.

Confusing adept and adapt is an example of this latter case.

So is the considerable ambiguity of the word 'security'.

> But that doesn't stop folks genuinely trying seemingly, I guess its 
> too tempting a windmill at which to tilt;-)

Here again, Stephen, one would not expect the cognizant AD to be so
readily directive and dismissive of points being raised seriously and by
a range of different contributors.

The mere fact that there is such a broad and persistent base of concern
with 'opportunistic security' warrants taking the issue far more seriously.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 21 Aug 2014 00:37:35 -0400

> them maybe there's not much point in suggesting it.

I think -03 was an improvement over -02, but I think we're in danger of 
regressing.  I was able to find time to give the diff of the rewritten draft 
someone posted a quick read and my overall impression was that it did not 
represent progress.

That's an overly terse comment for the amount of effort that went into it, but 
that's all I have time for.

I think -03 does a reasonably good job of describing OS and we should call it  
mostly done.  

Scott K

---

From: <[email-masked]>
Date: Thu, 21 Aug 2014 10:11:14 +0000

aiming to get a term as part of ietf culture is thinking too small. what is opportunistic security -for-? what does it support?

the principle of proactively prudent privacy is the protocol design pattern you're looking for. you can sell prudence and privacy.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf <[email-masked]> on behalf of Nico Williams <[email-masked]>
Sent: Thursday, 21 August 2014 11:27:51 AM
To: Stephen Farrell
Cc: Paul Wouters; Phillip Hallam-Baker; IETF Discussion Mailing List
Subject: Re: Adept Encryption: Was: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment)

+1.

Nico
--

---

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

Dave,

I expect we are not going to agree on this, but that's fine.

> why its deficiencies are less onerous than those of the alternatives.)

That happened on the saag list before the start of IETF LC.
There are quite a few substantive threads on it, I think
the first goes back on March 6th this year started by PHB. [1]

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

So 5 months ago. In my local folder for saag "opportunistic"
matches 332 messages starting there, some were offlist though
and some messages got put elsewhere so that number is maybe
about right.

And before you object and again say that any such discussion
in not relevant and that I'm quickly dismissing careful
consideration and causally waving something away by being
readily directive...

...no, I'm not, (despite the piled-on pejorative prose:-)

The fact that we had multiple rounds of discussion on saag
about a plethora of suggested terms is entirely relevant here
and does I believe indicate that no newly suggested term is
likely to be much better, nor is any such term likely to
garner much better consensus. You are of course entirely free
to believe something else but I think the evidence we have is
on my side of this argument.

> with 'opportunistic security' warrants taking the issue far more seriously.

Hmmm. I do not see broad concern. I do see persistent expression
of concern from you about this being done without sufficient
something (care, seriousness, whatever). I also see some folks
saying that we should just publish and get it done. That is all
in addition to the good and constructive discussion, involving
you and others, with which the above is intertwined, so for
me at least, its not a big deal really, just some more mail to
get through.

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 21 Aug 2014 08:24:22 -0400

>    [1] https://www.ietf.org/mail-archive/web/saag/current/msg04604.html

And in that message PHB presciently wrote:

"There are arguments for all of these but I am just watching a
presentation on 'opportunistic encryption' in DANE and I think the
term is selling DANE short.

DNS is an authoritative path for statements about DNS labels. Ergo
authenticated DNS RRs are authenticated statements about them. DANE
provides authenticated statements about security policy and keys. Ergo
DANE cannot support opportunistic encryption because it is policy
directed encryption (i.e. better)."

With all due respect [1], I don't think this effort is helping the
goal of getting encryption deployed and used.

'Pragmatic Security' is a much better term for what we should do which
is to act on the best available information.

We have a collection of policy inputs:

* The https URI prefix means 'use http over TLS'
* Presence of a DANE record means 'use TLS with key matching these criteria'
* Protocol headers can be defined to mean 'use TLS'
* Manual user config

We have a variety of key publication mechanisms

* Self signed cert
...
* Extended Validation Web PKI certificate

So pragmatic security means 'act on the best available intel'.

Using the terms 'opportunistic security' does not help because I am
not interested in opportunistic security except as a last resort. I
don't expect an RFC titled 'last resort kinda rubbish security' to be
giving me advice relevant to anything other than last resort
situations.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 21 Aug 2014 11:35:26 -0400

Nico,

> more small effort to adjust Viktor's prose, and publish.
I agree that we seem to have settled on a small set of design principles.

I continue to disagree with your assertion that clear, concise wording
is a not an important aspect of this task.

Steve

---

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

> And in that message PHB presciently wrote:

Yes, thanks for that message, it got the ball rolling.

> term is selling DANE short.

The reasons why that's not the case were explained and we are now
defining what it means for DANE to be used opportunistically.  It
can also be used for mandatory authentication just for the key
management part.  TLS can likewise be used for sessions with
mandatory encryption and authentication, or as "opportunistic TLS"
with SMTP.  Neither DANE nor TLS are opportunistic or not, they
are just tools that can be used in multiple ways.

> authenticated DNS RRs are authenticated statements about them.

Correct, and this is precisely why DANE/DNSSEC can be used to
securely discover which peers have published TLSA RRs and can be
authenticated.  The existence of an authenticated out-of-band
(relative to the application protocol) mechanism for publishing
capabilities[*] is what makes it possible to employ opportunistic DANE
TLS.  What's opportunistic is still the use of TLS (with DANE
providing a downgrade resistant commitment to "STARTTLS" and key
material to enable authentication).

    * Yes OS protocols can overload TLSA RRs as a capability
      to employ TLS *with* authentication.

> DANE

But the keys are not always there, in fact currently for SMTP, I
know of ~32 domains with published TLSA RRs for their MX hosts,
and that's probably accurate to within a factor of 10 or so.

So from the perspective of an MTA, TLS with DANE is very much
opportunistic.

    * Look up MX RRset.  If not DNSSEC "secure", back to
      plain opportunistic STARTTLS for all MX hosts.

    * For each MX host (sorted by priority in the usual way) 
      look up up A/AAAA RRset, if not DNSSEC "secure", back
      to plain opportunistic STARTTLS for that MX host.

    * Look up TLSA RRset, unless present and DNSSEC "secure",
      back to plain opportunistic STARTTLS for that host.

    * If all TLSA RRs are unusable, require STARTTLS encryption,
      without authentication (since no usable authentication
      keys available).

    * If some TLSA RRs are usable, require STARTTLS encryption,
      with authentication.

The above is done for each peer domain, and for each peer MX host.
What is opportunistic is the use of possibly authenticated TLS,
with out-of-band signally via DANE enabling downgrade-resistant
authentication.

On Sun, Aug 17, 2014 at 11:20:26 -0400, Phillip Hallam-Baker wrote off-list:

> On Sat, Aug 16, 2014 at 11:17 PM, Viktor Dukhovni <[email-masked]> wrote:
> > On Sat, Aug 16, 2014 at 11:13:23PM -0400, Phillip Hallam-Baker wrote:
> >
> >> DANE isn't opportunistic security. It is authenticated security policy
> >> and keys. Thats the opposite of opportunistic.
> >
> > Have you read the draft?  DANE can be "opportunistically employed",
> > when TLSA records are present, and not when they are absent.
> > While DANE is not opportunistic per-se, a protocol employing it,
> > for example:
> >
> >     http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-11
> >
> > sure is.  This statement suggests you've either not read the draft,
> > or just skimmed it.  It is also possible that my explanation of this
> > is too obtuse, in which case please help me polish it, or at least
> > chime in on the need for me or others to spell this out in more
> > detail, e.g. in the SMTP example at the end of the draft.
>
> Draft, schmaft.
> 
> Opportunistic encryption is a pre-existing term of art. If the draft
> is causing people to get confused about what opportunistic encryption
> is then it should not be published.

Have you read either draft yet?  We're not even defining "opportunistic
encryption".  We're defining "opportunistic security", which is
not surprisingly a broader term.

> * The https URI prefix means 'use http over TLS'

That is mandatory local policy (based on HTTPS URI
semantics), and OS is out of scope.  OS is in scope
for SMTP, IMAP, XMPP, and HTTP where no explicit
security mandate is in force.

> * Presence of a DANE record means 'use TLS with key matching these criteria'

If this in the context of an "HTTPS" URI, then the use of DANE key
management for mandatory authentication is out of scope for the OS
draft.

> * Protocol headers can be defined to mean 'use TLS'

OS is about selecting a mutually supported set of security mechanisms,
even if that sometimes results in less than complete cryptographic
protection or even cleartext.

> So pragmatic security means 'act on the best available intel'.

Well, at least we largely agree on the substance.  If your object
is just to the term, please send your thoughts off-list to Stephen
Farrell, he'll presumably let us how the rough consensus worked out.

> not interested in opportunistic security except as a last resort.

Whichever term we choose will mean exactly the same thing, with
different words.  So it makes no sense to presume that OS means
something other than your suggested term of "pragmatic security",
they are one and the same.  We're just choosing the term.

> I don't expect an RFC titled 'last resort kinda rubbish security' to be

Good thing that's not the phrase we're proposing. :-)

-- 
	Viktor.

---

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

> I agree that we seem to have settled on a small set of design principles.

Thanks.

> is a not an important aspect of this task.

Whether the -03 was adequate, or inadequate, I agree that much of
the proposed text in the abstract and introduction is an improvement,
... Thanks a lot for the text!

[ Wish it were XML, and not extracted from "Word" and sent as HTML,
but that's something I managed to get past with help from lynx and
Perl... ]

I'm working on integrating the improved bits, but keeping more of
the original *content* in place (reworked).  In deleting the
"Pattern" section and compressing the "Principles" section, too
much was lost in the proposed revision.  So that's where my efforts
will be spent, recreating that content with more clarity and less
repetition.

Still working on it, ...

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 Aug 2014 11:28:18 -0500

> I agree that we seem to have settled on a small set of design

That's excellent news.

> is a not an important aspect of this task.

It is important, it's just that agreement on the substance is clearly
the first order of business.

If we're down to wordsmithing then we can have a more leisurely / less
confrontational discussion of said wordsmithing, and finish this up.

Nico
--

---

From: Christian Huitema <[email-masked]>
Date: Thu, 21 Aug 2014 19:23:16 +0000

> Hmmm. I do not see broad concern. I do see persistent expression of concern from you about this being done 
> without sufficient something (care, seriousness, whatever). I also see some folks saying that we should just 
> publish and get it done. That is all in addition to the good and constructive discussion, involving you and others, 
> with which the above is intertwined, so for me at least, its not a big deal really, just some more mail to get through.

I think we should just "publish and get it done."

The draft has a very simple function: tell the community that it is OK to do some form of encryption even if in situations where we cannot do the perfect negotiation of really secure and authenticated keys. In fact, tell the community that is not OK to just fall back to plain text when one particular check was missed in the perfect negotiation.

Watching the discussion, I see three forms of objections:

1) Objection to the particular name that was chosen to designate this "design pattern."
2) Objection to the whole idea that we should settle for better than plaintext when we cannot do perfect. 
3) Objection to the particular wording of Viktor's draft.

Stephen just pointed the archives of the SAAG discussion that eventually converged on the "opportunistic security" term. Nobody is in love with that term. It was chosen as a second best after "opportunistic encryption," which was somehow conflicting with a particular usage of IPSEC. But we also got convinced that the name is good enough. 

The "better than plaintext" consensus is obviously rough. There are two classes of objections. One is the "false sense of security" argument, which is really an argument about the design of user interaction, and which is addressed in the draft. The other is the "middle box" argument, which says that if more traffic stays in plain text middle boxes can do a better job of analyzing or transforming the data in flight. But then, there was a clear consensus at Vancouver to do as much encryption as possible despite these middle boxes, and to evolve middle boxes towards an explicit relation with the end-to-end senders and receivers. So, that part of the consensus is going to remain rough no matter what.

Viktor's draft is basically fine. It is short and clear. The various rounds of edits tend to make it "different," but not better. IMHO, it is time to ship it.

-- Christian Huitema

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 Aug 2014 14:36:32 -0500

On Thu, Aug 21, 2014 at 07:23:16PM +0000, Christian Huitema wrote:
> [...]

Thanks for your categorization of objections thus far!  That's very
useful, even if were incomplete: if we could list them all that pithily,
even when no objections remain, it'd be a useful record.

Nico
--

---

From: <[email-masked]>
Date: Fri, 22 Aug 2014 05:25:17 +0000

Okay, so with opportunistic security, all a man in the middle has to do is block any communications he can't decrypt, and it automatically downgrades to select something he can break?

Ah, there's the opportunity. Got it.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf <[email-masked]> on behalf of Viktor Dukhovni <[email-masked]>
Sent: Friday, 22 August 2014 2:04:02 AM
To: [email-masked]; [email-masked]
Subject: Re: Adept Encryption: Was: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment)

--
        Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 22 Aug 2014 05:35:04 +0000

On Fri, Aug 22, 2014 at 05:25:17AM +0000, [email-masked] wrote:

> Okay, so with opportunistic security, all a man in the middle
> has to do is block any communications he can't decrypt, and it
> automatically downgrades to select something he can break?

And without OS, he need not do anything at all, because the vast
majority of the traffic is cleartext.  However OS can support
downgrade resistant modes of operation, given appropriately secure
out-of-band signalling, (possibly DANE/DNSSEC).

OS is not an effort to displace already working authenticated
encrypted traffic.  Rather, it is an effort to upgrade currently
unencrypted traffic to encryption or currently unauthenticated
traffic to authentication.

Hence, "Opportunistic TLS" with SMTP for the former, and "Opportunistic
DANE TLS" with the latter.

You can point fingers at the shabby clothing of the OS emperor,
but at least he's not naked.

--
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Aug 2014 00:42:15 -0500

> Ah, there's the opportunity. Got it.

Eh?  The idea is to be downgrade resistant.

Nico
--

---

From: <[email-masked]>
Date: Fri, 22 Aug 2014 08:11:38 +0000

no, it's at encyption above a baseline. assume mitm can't crack maximum level,,but can crack baseline and above. if maximum can't be negotiated because mitm prevents it , and less is settled for... well. may as well have fallen back to clear.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Nico Williams <[email-masked]>
Sent: Friday, 22 August 2014 3:42:15 PM
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]
Subject: Re: [saag] Adept Encryption: Was: DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment)

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Aug 2014 13:13:16 +0100

Hi Christian,

On 21/08/14 20:23, Christian Huitema wrote:
> Viktor's draft is basically fine. It is short and clear. The various
> rounds of edits tend to make it "different," but not better. IMHO, it
> is time to ship it.

I think your mail is a good summary though perhaps it doesn't
catch all of the concerns that Dave expressed. In particular
he also had a concern that we may be addressing the wrong
target audience. However, there was no significant discussion
of that when I kicked off a thread so I conclude that others
don't share that concern.

All that said, I agree with your conclusion that we risk going
more sideways than forward with additional iteration. Right now,
Viktor is preparing a -04 taking into account list discussion
on -03 and the substantial editorial inputs from Steve Kent
and Ben Kaduk.

Barring late surprises, my plan is to put that into IESG
evaluation as I conclude we have reached rough consensus on
the concepts here.

For who are those interested, I plan to add the saag list to
the cc for IESG evaluation comments/discuss points so you'll
be able to follow along there as the IESG consider this draft.
That'll probably happen in the run up to the Sep 4th IESG
telechat, or maybe the one on Sept 18th, depending.

And lastly, thanks to everyone for the engaging discussion.

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 22 Aug 2014 14:00:01 +0000

On Fri, Aug 22, 2014 at 08:11:38AM +0000, [email-masked] wrote:

[ top-post rearranged ]

> Nico wrote:
> no, it's at encyption above a baseline. assume mitm can't crack
> maximum level,,but can crack baseline and above. if maximum can't
> be negotiated because mitm prevents it , and less is settled for...
> well. may as well have fallen back to clear.

For the record:

OS is primarily about high level security mechanism selection
(cleartext, passive-only, active and passive protection).  The
draft says deliberately little about the fine details of crypto
handshakes, which may or may not support a range of ciphers and
will typically do exactly the same thing when used opportunistically
in an OS protocol as otherwise.

For example, I don't see TLS changing to become opportunistic.
Rather I see higher level application protocols that can employ
TLS using it opportunistically when previously they might have sent
in cleartext.  (Vocabulary point I try to keep straight, "plaintext"
is input to encryption, or output of decryption, while "cleartext"
is unecrypted content on the wire).

OS does not impact the active attacker's ability to tamper with
unathenticated communication.  However, OS encourages authentication:

   * Any currently protected traffic remains protected, OS does not
     trump existing policy that mandates comprehensive security.
     For example, opportunistic security for HTTP does not downgrade
     HTTPS, all it does is upgrade HTTP to resist passive and
     perhaps some day with some peers also active attacks.

   * OS suggests that it is a good idea to employ downgrade resistant
     mechanisms to discover which peers can be authenticated, and then
     authenticate those peers.

It used to be easy to dismiss opportunistic security as a waste of
time, it is now clear to most that it is not.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 22 Aug 2014 10:13:28 -0400 (EDT)

On Fri, 22 Aug 2014, Viktor Dukhovni wrote:

> encrypted traffic.

What this little exchange above here shows is that people involved in
this dicsussion _still_ don't know whether "OS" is just the anonymous
crypto or whether includes the "design pattern recommendation advise"
of using authenticated encryption if available.

If the people who agree to "just publish it" cannot even keep their
usage straight, I'd say the document needs more work.....

Paul

---

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

I concur with Viktor's reply. I even like his metaphor :-).

OSteve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 22 Aug 2014 15:51:32 -0400

Nico,
> Eh?  The idea is to be downgrade resistant.
It's nice if the OS mechanism is downgrade resistant, but that is not 
required by
the current set of design principles.

Steve

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Aug 2014 19:13:54 -0700

> It used to be easy to dismiss opportunistic security as a waste of time, it is now clear to most that it is ....

[BA] Merely a waste of money. 
"Opportunistic unauthenticated encryption" that does not defend against man-in-the-middle attacks has no value against targeted surveillance.  So if the goal is to protect dissidents, look elsewhere.  Unfortunately, the line between "targeted surveillance" and  "mass surveillance" is a thin one.   
The value against mass surveillance is predicated on the assumption that "large scale targeted surveillance" is infeasible or that the cost of large scale meta-data collection can be increased to the point where it is too costly even for a nation-state.   
The first assertion, is likely to be proven false by the first gear to include built-in man-in-the-middle attack support.  Care to wager which appears first, carrier-class gear supporting man-in-the-middle attacks, or significant deployment of "opportunistic" encryption?  
The second assertion is likely to be proven false as soon as "opportunistic" is deployed widely enough to necessitate a surveillance budget increase (based on purchases of the above gear) necessary to defeat it.

---

From: Theodore Ts'o <[email-masked]>
Date: Fri, 22 Aug 2014 23:02:50 -0400

On Fri, Aug 22, 2014 at 07:13:54PM -0700, Bernard Aboba wrote:
> The first assertion, is likely to
> be proven false by the first gear to include built-in
> man-in-the-middle attack support.  Care to wager which appears
> first, carrier-class gear supporting man-in-the-middle attacks, or
> significant deployment of "opportunistic" encryption?

This assumes that the telecom carriers and/or the suppliers of the
carrier grade equipment would cooperate with the nation-states in
question.  That could happen, certainly, but it becomes much more
difficult to do this surreptitiously.

This won't help in a totalitarian regime, certainly, but in democratic
societies having law enforcement agencies engaging in mass,
surreptitious surveilance might be less likely to be tolerated.

Cheers,

							- Ted

---

From: Christian Huitema <[email-masked]>
Date: Sat, 23 Aug 2014 03:57:22 +0000

> difficult to do this surreptitiously.

It is also fairly easy for OS conscious applications to use channel binding schemes and detect the MITM. At that point, the spies have to move from covert monitoring to overt surveillance, which should have some noticeable political consequences.

-- Christian Huitema

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Aug 2014 23:05:52 -0500

On Fri, Aug 22, 2014 at 07:13:54PM -0700, Bernard Aboba wrote:
> "Opportunistic unauthenticated encryption" that does not defend
> against man-in-the-middle attacks has no value against targeted
> surveillance.  So if the goal is to protect dissidents, look
> elsewhere.  Unfortunately, the line between "targeted surveillance"
> and  "mass surveillance" is a thin one.   

For me OS is not about anti-PM, or at least not mainly anti-PM.  See
below.

> The value against mass surveillance is predicated on the assumption
> that "large scale targeted surveillance" is infeasible or that the
> cost of large scale meta-data collection can be increased to the point
> where it is too costly even for a nation-state.   
>
> The first assertion, is likely to be proven false by the first gear to
> include built-in man-in-the-middle attack support.  Care to wager
> which appears first, carrier-class gear supporting man-in-the-middle
> attacks, or significant deployment of "opportunistic" encryption?  

MITM HW, if need be, will materialize and will be deployed.  I don't
doubt this.

That doesn't mean that active attacks are not more costly than passive
ones, or that it's not worth providing protection against passive
attacks.

Attackers not operating under the color of law can only really build a
massive PM active attack system by building edge-most router botnets,
which seems unlikely to go unnoticed, those routers almost certainly
lacking the necessary CPU oomph...  Therefore OS can go a long distance
relative to criminals in many situations.

Sovereign powers will be able to do build active PM systems, no doubt.

But if the end-state for OS is something like DANE then the sovereigns
will either have to MITM DNSSEC or force services to furnish them with
authentication keys.  Both of those are potentially very expensive
politically (because they will be noticeable intrusions).  If not, then
they will at least be clarifying.  If a nation's people don't mind their
government monitoring them, they still ought to be able to get
protection relative to third parties (routers, criminals, foreign
powers).

Nico
--

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 23 Aug 2014 13:27:52 -0700

Nico said: 

> For me OS is not about anti-PM, or at least not mainly anti-PM.  See below.
 
[BA] I agree - but IMHO it would be useful if we were clear about this in problem statement documents.  

>Therefore OS can go a long distance relative to criminals in many situations.
 
[BA] We certainly do have a problem with criminals targeting payment networks to great effect.  However, given the urgency and potential deployment lags, is OS the most timely potential response to that problem? 

> Sovereign powers will be able to do build active PM systems, no doubt.
 
[BA] In many cases (and certainly in the case of virtually all oppressive regimes), major portions of the Internet infrastructure are under control of the state.  So if the issue is oppressive regimes (and protection of dissidents), something considerably more comprehensive than OS is needed (e.g. more along the lines of Tor). 
 
[nico]  But if the end-state for OS is something like DANE 

                          

    

[Huitema] It is also fairly easy for OS conscious applications to use channel binding schemes and detect the MITM. 
[BA] If we are talking about DANE and channel binding schemes, aren't we out of the realm of "unauthenticated" opportunistic encryption?  
 
[IanG] "Agreed on both points.  And this is a big win.  Because then we know what they are doing and can provide evidence."
[Ted] This won't help in a totalitarian regime, certainly, but in democratic
societies having law enforcement agencies engaging in mass,
surreptitious surveilance might be less likely to be tolerated.

[BA] AFAIK, the surveillance budget is not a matter of public record in most nations of the world.  And as far as "toleration" in democratic societies is concerned, are there democratic societies in which there are comprehensive reform proposals that have a good chance of passage?  Just wondered if I was missing something.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 23 Aug 2014 21:33:27 +0100

Hi Bernard,

For myself, I do think there's value in OS, as do others.
That can and should be debated of course.

However, say we're wrong and someone who thinks OS is a waste
of time is actually correct, what would such a person recommend
that we do as well as, or instead of, OS?

Cheers,
S.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 23 Aug 2014 14:05:07 -0700

> that we do as well as, or instead of, OS?

[BA] It depends on who we are trying to protect, and from what (or whom).  
If the target is protection of dissidents from oppressive regimes, then you need something much more comprehensive than 'unauthenticated opportunistic encryption" (e.g. along the lines of Tor). 
If the target is protection against PM within wealthy nations, then you'd need something that can't be rendered harmless by a modest budget increase.A number of MITM protection mechanisms have been suggested (e.g. DANE, channel binding, etc.). 
Also, in this category should be mechanisms for protecting privacy against private-sector adversaries.  As long as private companies can amass huge dociers without resort to PM (or without the need to subvert OS), and are willing to sell that personal information to third parties (dodgy ones, let alone governments),  one wonders whether government agencies would make better use of their funds by "buying" surveillance, rather than trying to "build" it.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 23 Aug 2014 21:05:50 +0000

> that we do as well as, or instead of, OS?

For the record I started work on "opportunistic DANE TLS", in March
2013, well before PM became a major concern.  It was designed as
a way to scalably enable authentication in SMTP, by making that
opportunistic (enabled peer by peer as DANE TLSA RRs are deployed).

So I see OS as a strategy to incrementally broaden both the use of
encryption AND the use of authentication.

Whether protocols other than MTA-to-MTA SMTP can implement OS *with*
authentication remains to be seen.  I hope that will prove possible
over time.  For mobile device applications, we may have to wait
for the DNSSEC "last mile problem" to be largely addressed before
significant progress in that direction can be made.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 23 Aug 2014 22:33:21 +0100

Hiya,

On 23/08/14 22:05, Bernard Aboba wrote:
> Stephen Farrell:
>> However, say we're wrong and someone who thinks OS is a waste of
>> time is actually correct, what would such a person recommend that
>> we do as well as, or instead of, OS?
> 

Sure.

> If the target is protection of dissidents from oppressive
> regimes, then you need something much more comprehensive than
> 'unauthenticated opportunistic encryption" (e.g. along the lines of
> Tor). 

Right. That's a hard target and involves far more than crypto,
whether OS or not.

One thing clearly involved there is that traffic analysis is
a threat, and I'd fully accept that we should be thinking about
ways in which we could make our protocols better against that
in general, even if we're not tackling the specific problems of
dissidents. For example, if my toilet emits packets with every
flush, encryption of any sort isn't going to disguise that so
traffic analysis will also be relevant for the Internet-of-Toilets.

> If the target is protection against PM within wealthy nations,
> then you'd need something that can't be rendered harmless by a modest
> budget increase. A number of MITM protection mechanisms have been
> suggested (e.g. DANE, channel binding, etc.). 

But isn't that what the IETF and security folks within the
IETF have been aiming for for a couple of decades? I mean aiming
for an end-state where we have mutual-auth more-or-less everywhere.
I don't consider that we've succeeded wildly to be honest;-)

What should we be doing differently is really my question.

> Also, in this category
> should be mechanisms for protecting privacy against private-sector
> adversaries. As long as private companies can amass huge dociers
> without resort to PM (or without the need to subvert OS), and are
> willing to sell that personal information to third parties (dodgy
> ones, let alone governments),  one wonders whether government
> agencies would make better use of their funds by "buying"
> surveillance, rather than trying to "build" it.

As it happens we had some discussion about e2e email security in
Toronto. Current plan is to start a new mailing list for that - a
bunch of us are chatting about how to scope that so we're less
likely to mess up. (More on that next week I hope.)

Now email is of course just one application (though a cornerstone
application). Which other applications/mechanisms should we be
considering that'd help here? FWIW, I'm very open to us trying to
help anywhere we could credibly do that. (Credibility requiring
that stuff be technically doable, be something that should be done
in the IETF and have enough warm bodies interested in doing work.)

Cheers,
S.

PS: If you or someone has a specific suggestion for a thing on
which we should be working, then maybe these lists are too broad
for detailed discussion of that. In such cases, the [email-masked]
list is probably a good place to triage whether a topic is one we
should try pursue in the IETF.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 Aug 2014 11:10:48 -0300

On 08/23/2014 06:05 PM, Bernard Aboba wrote:
> If the target is protection of dissidents from oppressive regimes, then
> you need something much more comprehensive than 'unauthenticated
> opportunistic encryption" (e.g. along the lines of Tor). 

It is quite often the case that, under oppressive regimes, using
encryption technology will already flag you as "suspect" (if not
"guilty"). So in that case, you'd probably want to use something
probably want something more like a cover channel in those scenarios.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Eric Burger <[email-masked]>
Date: Sun, 24 Aug 2014 12:32:15 -0400

I am concerned with the drive to make all traffic totally opaque. I’ll be brief: we have an existence proof of the mess that happens when we make all traffic look benign. It is called “everything over port 80.” That ‘practical’ approach drove the development of deep packet inspection, because everything running over port 80 was no longer HTTP traffic. It meant we could no longer prioritize traffic (in a good sense - *I* want to make sure my VoIP gets ahead of my Web surfing ahead of my FTP). It meant we could no longer apply enterprise policy on different applications. It drove ‘investment’ in the tools that today dominate pervasive monitoring.

Good job folks for unintended consequences.

---

From: Michael StJohns <[email-masked]>
Date: Sun, 24 Aug 2014 15:06:29 -0400

>Good job folks for unintended consequences.

For a longer and more complete discussion on this, please see also RFC3639.  It was drafted at a time a national actor was contemplating blocking VoIP traffic at the actor's borders so it could tariff voice traffic by forcing it onto the PTT POTS system. 

There will be unintended consequences for whatever this OS thing ends up getting called.  It would be nice if we could do enough design and analysis prior to deployment to turn them into "carefully considered, more good for the user than harm to the network" consequences.

Later, Mike

---

From: Dave Crocker <[email-masked]>
Date: Sun, 24 Aug 2014 12:12:54 -0700

On 8/24/2014 7:10 AM, Fernando Gont wrote:
> "guilty").

A premise of trying to move Internet services over to "encrypt
everything for everyone" is to eliminate that flag.

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Aug 2014 08:01:51 +1200

On 25/08/2014 07:06, Michael StJohns wrote:
> For a longer and more complete discussion on this, please see also RFC3639.  

RFC3205 (BCP56) said some of it a bit earlier, and was ignored. I'd say that
RFC3639 was ignored too. For a practical lesson on the same topic, I suggest
a critical study of all the RTCWEB drafts and of draft-ietf-dart-dscp-rtp.
I think they show the depth of the hole we are in.

   Brian

> It was drafted at a time a national actor was contemplating blocking VoIP traffic at the actor's borders so it could tariff voice traffic by forcing it onto the PTT POTS system. 
>

---

From: joel jaeggli <[email-masked]>
Date: Sun, 24 Aug 2014 13:42:13 -0700

> probably want something more like a cover channel in those scenarios.

it's already implausible in many cases  to seperate the sheep from the
goats.

When was the last time you did a google search or accessed a twitter
feed in the clear?

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 Aug 2014 20:57:28 -0300

[...]
> it's already implausible in many cases  to seperate the sheep from
> the goats.
> 
> When was the last time you did a google search or accessed a
> twitter feed in the clear?

Good luck explaining that to the oppressive regime.

---

From: joel jaeggli <[email-masked]>
Date: Sun, 24 Aug 2014 17:09:27 -0700

> Good luck explaining that to the oppressive regime.

I don't have to. They are aware for example that all twitter api calls
had a deadline over ssl since jan 1 2014. You cannot distinguish the
intentions of the user by their (involuntary) use of encryption.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 24 Aug 2014 21:55:49 -0300

[...]
> intentions of the user by their (involuntary) use of encryption.

I suggest you talk to someone that's suffering from an oppressive regime
(both in terms of the stuff that they suffer, and what their regimes are
supposedly aware of).

My response is based on the lesson that I learned when I offered (a few
years ago) one of such folks an encrypted tunnel such that they could
avoid both censorship and monitoring.

Any technical explanation that you can give (no matter how correct or
true it is) is of no use if the guy suffering from an oppressive regime
is still going to have a hard time with their regime.

Thanks,

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Aug 2014 12:36:19 +1000

In message <[email-masked]>, Eric Burger writes:
>
> I am concerned with the drive to make all traffic totally opaque. I'll be
> brief: we have an existence proof of the mess that happens when we make
> all traffic look benign. It is called "everything over port 80." That
> `practical' approach drove the development of deep packet inspection,
> because everything running over port 80 was no longer HTTP traffic. It
> meant we could no longer prioritize traffic (in a good sense - *I* want
> to make sure my VoIP gets ahead of my Web surfing ahead of my FTP). It
> meant we could no longer apply enterprise policy on different
> applications. It drove `investment' in the tools that today dominate
> pervasive monitoring.
>

And everyone went to port 80 because people put up blocks for other
ports often for no other reason than "we can".

You have idiots with firewalls blocking access to submission yet
allowing access to webmail services.

You have idiots with firewalls blocking access to imaps/pops yet
allowing access to webmail services.

You have idiots with firewalls blocking access to ... yet allowing
https through.

As for VIOP traffic, have the originating device set TOS/TCLASS.
It really isn't that hard having set both TOS and TCLASS in the
application sometimes on a per packet basis.

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

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Mon, 25 Aug 2014 01:22:03 -0400

On Aug 24, 2014, at 10:36 PM, Mark Andrews <[email-masked]> wrote:

>> we have an existence proof of the mess that happens when we make
>> all traffic look benign.

By its nature all non-benign traffic will want to *look* benign.

What makes me sad are the idiots with firewalls blocking access to all traffic other than TCP and UDP. We keep trying to make ourselves secure by limiting the standards support of the network instead of using a mix of techniques (defense in depth).

Sorry. Preaching to the choir I’m sure.

Personal email.  [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 25 Aug 2014 00:19:56 -0700

> I think they show the depth of the hole we are in.
​Just so I don't rudely put words in your mouth, I'd appreciate your
unpacking what you practical lesson you anticipate learning there.

regards,

Ted​

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 25 Aug 2014 08:09:04 +0000

> probably want something more like a cover channel in those scenarios.

To some extend I agree with Fernando since I have the practical experience of such places. To be clear, if the purpose of the encryption is to avoid such places to access users' data or try to harden this process, actually it fails because the users force to use their devices and the main internet stream to those countries passed by their devices (where all traffic filtered and analyses and then sent to the users). Therefore, you cannot help them, especially, if you're talking about unauthenticated source of data. When OS or other ways try to help to authenticate this data, then maybe you can be 1% successful. Because this also helps that the users do not recognize this MITM attack. They can recognize this when they receive any warning message. (I am not talking about professional users that might trace their traffic. But about 80% of internet users.)

Nevertheless, In my opinion, encryption, in general, is good. But it depends on what our target users or services are and who we want to hide this traffic from. Whether those people have access to the main internet stream and the user have no way to avoid them? Whether they have a power to apply regulation for internet in a country and user MUST follow them? Or whether they only want to sniff data passively in a way that user do not recognize it. In last case, encryption conditionally can be successful but I do not think it works in the first two cases. 
The conditions are that 1- whether those places can be easily recognized if they do active attacks? (it might be yes if they want to do this attack with the whole internet data stream that belongs to different countries but this is not true if it is only a small portion of traffic such as an enterprise or etc.)

I hope that I could explain my point clearly.

Best,
Hosnieh

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Aug 2014 12:09:53 +1200

> unpacking what you practical lesson you anticipate learning there.

Actually I think my brain was a bit fuzzy when I wrote that, but the point
is that when we start bundling up things that don't naturally belong together,
because we are trying to defeat middleboxes that perform DPI (for traffic
analysis or any other reason) and/or IP header munging, we end up with
artificial complexity that is unlikely to result in reliable, efficient
communication.

An old story, I know. Since before RFC 2775 at least.

   Brian

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 Aug 2014 00:44:08 -0500

On Sun, Aug 24, 2014 at 12:32:15PM -0400, Eric Burger wrote:
> I am concerned with the drive to make all traffic totally opaque.
> I’l be brief: we have an existence proof of the mess that happens
> when we make all traffic look benign. It is called “everything over
> port 80.” That ‘practical’ approach drove the development of deep

Benign?  No, that's not it.  Ports 80 and 443 (*not* just 80) are used
for everything for a variety of reasons, one of which is that no one
could block them entirely, so every site with a firewall simply had to
have the capability to, and processes for permitting HTTP/HTTPS traffic
-- they could NOT afford not to!

Whereas protocols on other ports...  See below.

> packet inspection, because everything running over port 80 was no
> longer HTTP traffic. It meant we could no longer prioritize traffic
> (in a good sense - *I* want to make sure my VoIP gets ahead of my Web
> surfing ahead of my FTP). It meant we could no longer apply enterprise
> policy on different applications. It drove ‘investment’ in the tools
> that today dominate pervasive monitoring.

It's true that using HTTP as the IP of the 'Net hurt all sorts of
things, but it was driven by the massive adoption of HTTP.  Remember the
term "application gateway"?  What a throwback to the late 80s, early
90s.  Application gateways are unheard of now because they're ETOOHARD.

Firewalls can't cope with a raft of arbitrary, custom protocols, whether
over IP or over HTTP, but with HTTP they get somewhat more metadata to
examine.  If you really want to draw a lesson here it is this:
application protocols need a firewall-friendly substrate of metadata.
That's HTTP -- no other such substrate exists.

Sure, it's a bit of a mirage: the HTTP metadata can be faked.  But at
least with HTTP the firewalls^Wproxies can make sure to get hostnames
every time, not just IP addresses.

That's my take.  Maybe it's wrong, but it seems at least plausible.

If VoIPs and such used different port numbers but still HTTP... they'd
get through firewalls eventually and you could get your traffic
prioritization.  It's not so much ports 80/443 that matter.  It's the
HTTP headers request line, status line, and headers that do.  You could
do WebSockets or otherwise tunnel anything over HTTP and the firewalls
will be happy to let you, IF they like your metadata.

Nico
--

---

From: Eric Burger <[email-masked]>
Date: Tue, 26 Aug 2014 06:54:10 -0400

My first reaction to the proposal of having traffic carry metadata to describe the protocol was that it would be a lot more efficient for middle box manufacturers to read RFCs. That way they would know all they needed to know about the protocol without having to analyze the metadata for each session. Moreover, sessions would not need all of that metadata just to describe themselves.

Then I thought that there is a simplicity and elegance to self-describing protocols.

Then I realized that people would complain about the chattiness and overheads of self-describing protocols, and we would end up publishing profiles of metadata. Like SERVICE_PROFILE=25 for mail retrieval, SERVICE_PROFILE=587 for mail submission, SERVICE_PROFILE=5060 for VoIP, SERVICE_PROFILE=389 for directory lookup, etc. We might even call those profiles RFC 5321, RFC 6409, RFC 3261, and RFC 4511, to save IETF work.