Subject: Editorial thoughts on draft-farrell-perpass-attack-02

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 07 Dec 2013 03:45:16 +0100

Greetings.

  Regarding http://tools.ietf.org/html/draft-farrell-perpass-attack-02 I
think a document like this needs prose that is clear, straight to the
point, easy to follow, persuasive, confident, convincing, inspiring. It
should be, at least more than your ordinary RFC, a work of art, and in
art it is often necessary to start over from scratch than making a few
tweaks here and there. An important reason is that, as I understand it,
some would like to use the document as substitute for debate. It is not
good enough for that.

If an IETF Working Group participants wants the group to consider wire-
tapping requirements, and a pointer to RFC 2804 puts an end to that, I
think that's fair. If I saw draft-farrell-perpass-attack-02 used this
way or otherwise having such an effect, I think that would not be fair.
This is my intuitive reaction from reading through the document a few
times; I suspect there are material reasons, but some editorial issues
are easy to identify. I think it may be useful to point some of them out
while I continue to review the document. (This is a mind-dump provided
as-is from first impressions, not something I intend to argue over).

The Abstract is this:

   The IETF has consensus that pervasive monitoring is a technical
   attack that should be mitigated in the design of IETF protocols,
   where possible.

The last two words do not belong here. If they mattered they should not
be left as a hanging appendage to the sentence but appear prominently,
but they do not even matter, the Abstract does not need to highlight
that the IETF does not have consensus on something impossible.

The qualifier "technical" makes the document appear deceptive. I do not
understand what it means, why it is there. I will have to keep this in
mind throughout the rest of the document, but human brains have a rather
limited set of registers, odds are I will forget about the four touch-
downs in a single game. I think the document does not actually explain
why this qualifier is in the Abstract. My impression is that it is not
needed there.

The document continues:

   1. It's an Attack

   The technical plenary of IETF 88 [IETF88Plenary] discussed pervasive
   monitoring.  Such pervasive surveillance requires the monitoring
   party to take actions that are indistinguishable from an attack on
   Internet communications.  Participants at that meeting therefore
   expressed strong agreement that this was an attack that should be
   mitigated where possible via the design of protocols that make
   pervasive monitoring significantly more expensive or infeasible.

There are many problems here. The biggest is probably that I get the
impression that this is twisted on a technicality. The logic is thus:

  1. X is not an attack.
  2. X is indistinguishable from an attack.
  3. X is therefore an attack.

If X was an attack then "indistinguishable from an attack" would be un-
necessary, so I get the impression that I am missing some important
detail here. Also note that this appears to be the central argument of
the document, but unlike the Abstract, it's just "attack", not "techni-
cal attack". The first time I looked at the document this was the point
where I stopped reading and instead scroll through the document to see
what else is there, and then put it aside for later when I can concen-
trate better.

Another problem is that the second sentence equates "pervasive moni-
toring" with "pervasive surveillance". That makes me wonder whether the
two are actually precisely the same thing, and I note that the document
does not actually introduce or define either of them before this point
and never defines "pervasive surveillance".

We are thrown right into "It's an Attack". Contrast this with RFC 2804
which takes care to start with a "Summary position" section, later
discusses "The Raven process", and then provides "A definition of
wiretapping". That is a clear separation of concerns, this draft throws
it all together.

The document continues

   This Best Current Practice (BCP) formally documents that consensus,
   having been through an IETF last call.

Before the document talked about meeting participants expressing strong
agreement. "That" is not consensus, some people in Vancouver expressing
something is not a method of finding IETF consensus. The "oh yeah, there
was also a last call" appendage does not help here. It seems to me that
this should be the other way around, IETF Consensus, oh yeah, and there
was a meeting in Vancouver, by the way.

I am sorry if this seems petty, but the dominant capitalisation is "Last
Call"; "last call" gives an impression of carelessness and haste, not an
impression of careful attention to detail.

I think "Best Current Practice" is a qualifier that cannot stand on its
own (something like "document" should follow), and it is probably not a
good idea to emphasise the formal document status in the document, it
gives too much of a sense of "look at me! I'm important! And I need to
point this out! Because, actually I am not that important after all". I
also think this document is probably intended for a wide audience, so it
should avoid abbreviations as much as possible. (To stick with the re-
ference, RFC 2804 only abbreviates and explains the abbreviation for
"IESG" and "IAB" and uses them only in immaterial sections).

Later in the document

   The term "attack" is used here in a technical sense that differs
   somewhat from common English usage.  In common English usage, an
   "attack" is an aggressive action perpetrated by an opponent, intended
   to enforce the opponent's will on the attacked party.  In the
   Internet, the term is used to refer to a behavior that subverts the
   intent of a communicator without the agreement of the parties to the
   communication.

I speak English only as a third language, but my impression is "intended
to enforce the opponent's will on the attacked party" is not in fact
part of how the word is usually or even commonly understood.

I think "In the Internet, the term is used" is not suitable prose for a
general audience. This is more something like "when the Security Con-
siderations sections of IETF specifications refer to an 'attack', then".

I suspect the document probably should not give the impression to IETF
outsiders that "we" speak in some sort of "code" where words do not mean
what they ordinarily mean. It might be an option to simply say what the
memo means by the word "attack" without reference to other definitions.

Later on

   In particular, the term "attack", when used technically, implies
   nothing about the motivation of the actor mounting the attack.

My initial impression was that this contradicts the earlier definition,
for instance, it seems to me that the "motivation" is to subvert "the
intent of a communicator without the agreement of the parties". I do not
see how "monitoring" and "surveillance" are free of "motiviation", so I
am not sure if this is trying to explain "attack" independently of the
main points of the document, or what else might be the point.

Later in the same paragraph

   ... The same techniques can be used regardless of motivation and
   we cannot defend against the most nefarious actors while allowing
   monitoring by other actors no matter how benevolent some might
   consider them to be. ...

This probably is a Central point of the document but it is lumped to-
gether with other things in a single paragraph.

The "other" section of the document carries this headline

  2. And We Will Continue to Mitigate the Attack

This is like saying that we will "further perfect the optimisations". To
me this mainly conveys insecurity, don't want anyone to think "we"'ve
not done this before now. Right, it's like calling something "Network
News Transfer Protocol Great International Consensus Standard" instead
of just "NNTP". It's desperate and probably means the opposite. And
clearly, starting a sentence with a conjunction is very transparent.

As Bender learned, "When you do things right, people won't be sure
you've done anything at all."

In the hope this helps,
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: SM <[email-masked]>
Date: Sat, 07 Dec 2013 01:52:13 -0800

Hi Bjoern,

I liked the comments as they provide an insight from the reader's 
point of view.

>memo means by the word "attack" without reference to other definitions.

It is easy to forget that the English used on this mailing list is 
not as easy to understand for people who speak it as a second or 
third language.  There may be an assumption that the reader is 
well-versed in English literature and the way English is used in the 
IETF (see "words do not mean what they ordinarily mean"). The last 
part also occurs in other groups as it is a matter of what people 
have in common.

Regards,
-sm

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 09 Dec 2013 12:45:16 +0000

Hi Bjoern,

Thanks for the thoughtful comments. I've added this to my
list of threads to revisit [1] so it won't get forgotten
later.

  [1] http://down.dsg.cs.tcd.ie/misc/ppbcp-text-suggestions.txt

Mostly, I think the current draft is ok as-is, but would
be happy to see alternative wording suggestions if you
or anyone else has them.

At the same time I hope we all recognise the danger of
wordsmithing/bikeshedding on a list this big, so maybe if
folks have purely wordsmithing changes to suggest just
send those to Hannes and me off list?

Anything substantive should of course go to the list.

On 12/07/2013 02:45 AM, Bjoern Hoehrmann wrote:
> tweaks here and there. 

Well, a "work of art" is quite a target, but yes, we should try
make this short document as good as we can. However, short and
accurate still outweighs artistic merit I think.

> An important reason is that, as I understand it,

I'd be uneasy with "substitute for debate" but if what you mean
is that this be usable in the same way that 1984 and 2804 are
then I'd agree. People still can and will debate how those and
this apply to e.g. what their WG is doing and that's the right
thing to happen. What this BCP and those RFCs can do though
is avoid having to continually debate the same background or
more fundamental points in each WG.

> way or otherwise having such an effect, I think that would not be fair.

Having read your mail, I'm not getting why but let's see...

> that the IETF does not have consensus on something impossible.

While I think you're correct that they aren't logically needed,
the last two words are nonetheless still useful I think. If
someone only read the abstract I think they'd get a more correct
picture as-is compared to the abstract without those two words.

> why this qualifier is in the Abstract. My impression is that it is not

Maybe we could always say "technical attack" but the intent in the
abstract is to hint that the term is being used in a way that's not
common English usage. Thinking about it though, I do think its ok
to mix the terms "technical attack" and "attack" since we explain
the term.

>   3. X is therefore an attack.

No. Your #1 isn't there. There is an implicit "Some people claim
this is not an attack, but it is" that I'd prefer we keep
implicit and not make explicit. If we made it explicit that'd
beg the question "Who thinks that?" and I don't think we want
to or need to answer that for this BCP to be correct and have
the effect we want.

> detail here. 

That is important. Since the actions required are indistinguishable
from what even defenders of pervasive monitoring would agree is an
attack, those defenders are placed in the awkward position of having
to agree that yes, pervasive monitoring should be treated as an
attack in the design of IETF protocols.

Again though, I'd suggest that we don't include that logic in
the draft, since it'd just provide text that'd be fodder for more
argument later on. If that argument needs to be thrashed out,
then we should do it now and anyone interested can find it in
the archives.

> Also note that this appears to be the central argument of
> cal attack". 

Again, I think its ok to use attack rather than technical attack
when/if that reads better, since we define what we mean.

> The first time I looked at the document this was the point

Does the above help? (Or make it worse;-)

> and never defines "pervasive surveillance".

Fair point. That was deliberate though but could maybe be
improved.

I think the term pervasive monitoring is generally better since
its less emotive and surveillance (for me, YMMV) has an implication
of being more targeted. So I wanted to define pervasive monitoring,
at least well enough to be usable for this document, i.e. I don't
think we need to be exhaustive or give loads of examples here to
get done what we want to get done here.  But I also wanted to
sort-of equate that with surveillance in case some readers
understand the latter word but might otherwise be confused by
as to what "pervasive monitoring" meant.

I think using them as synonyms once does the above well enough.
(It might be better to change the last para of section 2 though
to say monitoring.)

> wiretapping". That is a clear separation of concerns, this draft throws

2804 is a fine document but I don't think we need to follow its
layout.

> was a meeting in Vancouver, by the way.

Better wording welcome, but the intent of this is to validate the
consensus that was overwhelming in the room via an IETF LC'd
draft, which is the "right thing" given our processes. So saying
exactly that seems entirely appropriate.

Presenting it as if the meeting was ancillary to forming the
consensus wouldn't be accurate.

> impression of careful attention to detail.

I (carefully:-) don't care about that to be honest. I can say
it wasn't written in haste.

> own (something like "document" should follow), 

I think that's fine as-is in terms of English usage.

> and it is probably not a

wrt acronyms & abbrevs... sure, will-fix:-)

I do think calling out the BCPness of this BCP is worthwhile since
I expect it will have readers who'll not get meaning of the RFC
meta-data at the top of the front page.

We could add a reference to 2026 section 5 though maybe. That
might be a good addition.

> siderations sections of IETF specifications refer to an 'attack', then".

We added that as a result of comments on the perpass list. I'll look
at it again and wordsmith when/if Jari tells me to shoot out a new
rev. Having said that I think its ok good enough as-is, but not a work
of art.

> memo means by the word "attack" without reference to other definitions.

Maybe. In this case, the point was made that "attack" might be
misconstrued so as to mean that we are discussing the motivations
of e.g. NSA. We are not discussing those motivations and we need
to be clear that we are not if this BCP is to have its proper
effect. But see below...

> main points of the document, or what else might be the point.

This bit does need to be clear and if its not we should fix.
I've not heard from others that its unclear though.

The point is not that the attacker has no motivation, but that the
IETF don't need to think about their motivations, since the actions
are indistinguishable from other (technical) attacks.

What we're saying is just that.

And its important that we say it, since the current attacker's
stated/claimed motivations include things  (e.g. "apprehend
terrorist") on which the IETF is not in a position to comment.

> gether with other things in a single paragraph.

See above. Lumped-together is going to happen though if we want
to keep this short and sweet, and I think we do.

> clearly, starting a sentence with a conjunction is very transparent.

Yep, that could be better. Suggestions welcome, but I'll think
about it. (In fact, one of the non-native English speaking folks
who commented earlier suggested this, but based on my initial
equally bad section heading;-)

> you've done anything at all."

Heh. A good target though.

> In the hope this helps,

It does. Still not promising a work of art though:-)

Thanks,
S.

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 Dec 2013 11:51:36 -0500

I have two major editorial comments too.

I want this draft and the IETF effort it (potentially) represents to
succeed on a difficult global stage. For that, it needs to be simple,
clear, and solid in what it says, without much extra to keep readers
entertained while they absorb the substance. Consider RFC 2804, where
the face-to-face discussion was passionate but the resulting document
is straightforwardly factual and technical.  That approach worked very
well for us.

This draft should be a basis for further work at layers 1 through 8+,
media analysis of what we ("those nerds") are up to, and discussions
in government, criminal organizations, and other organizations around
the world. I'm not trying to dampen the message or the enthusiasm,
just to get it presented carefully, so that no one can misuse what we
say.

Recommendation #1, the section headings: Currently they are "It's an
Attack" and "And We Will Continue to Mitigate the Attack".  Just those
headings are all the media needs for high entertainment value. They
are also all various organizations need as leverage to dismiss us as
extremists. :-)  I suggest making the first section "Pervasive
Monitoring is Indistinguishable from an Attack". "It's an Attack" is a
great title for a slide presentation to an appreciative audience, but
it is only accurate at a high level and is immediately qualified in
the text anyway. The heading for Section 2 is great as long as Section
1 is changed to be clearer.

Recommendation #2, where to put discussion of definitions: Statements
are made at the front of each section and then _after_ that, the
concepts used in those statements are developed. In Section 1,
"attack" is presented as a technical term after it is used in what
appears to be a non-technical way. I would move discussion of its
meaning up to the top of the section. The discussion of "pervasive
monitoring" can probably stay where it is -- let's see after the next
editing pass.  In Section 2, the discussion of the meaning of
mitigation should be tightened up and moved to the top of the section.
 It's not good to give general readers the soundbites they are going
to run with unless you make sure they understand what you're saying
first.

FYI I'm also the assigned gen-art reviewer for this draft, but I'll
put that off as long as possible until this all settles out. I expect
a new draft version soon :-).

Scott

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 Dec 2013 17:02:23 +0000

Scott makes some important points here.

A more clinical and less dramatic approach would
I think serve us better.

Stewart

On 11/12/2013 16:51, Scott Brim wrote:
> .

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Dec 2013 17:35:38 +0000

Fair points.

Added to my list of threads to go back to when Jari tells
us do do a -03. [1]

S.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 11 Dec 2013 09:44:15 -0800

Scott,

Thanks for thinking about this.  In your caution, though, I believe you are
downplaying a real issue.  In particular, here:

> the text anyway.

The reality is that it is not simply indistinguishable from an attack, it
represents actual harm to the use and users of the network.    While we
often use the term "self censorship" when pervasive monitoring causes us to
limit our speech, the actual agency belongs with the monitors, not with
us.  In some cases this limitation may be a side effect; in some cases it
is a desired outcome by the state actors taking this action.  While
"attack" may come across as a loaded term, the impact and the threat are
real.

If the language does change, I could see value in saying "Pervasive
monitoring represents a threat" and "We will work to mitigate that threat";
that change could acknowledge that in some cases the impact is a
side-effect of the activity rather than the direct result of an attack.
But I would not be okay with a change that did not acknowledge that this
activity has an active harm, as "Pervasive monitoring is indistinguishable
from an attack" would do.  That could channel our energies in ways which do
not actually address either the threat or the harm.

regards,

Ted Hardie

> The heading for Section 2 is great as long as Section

---

From: Eliot Lear <[email-masked]>
Date: Wed, 11 Dec 2013 19:04:57 +0100

On 12/11/13 6:44 PM, Ted Hardie wrote:

> The reality is that it is not simply indistinguishable from an attack,
> it represents actual harm to the use and users of the network.

So that there's no doubt, I 100% agree.  And so...

> monitoring represents a threat" and "We will work to mitigate that

Absolutely we should. 

Where practical to do so (and I do expect that to evolve over time).

Eliot

---

From: Scott Brim <[email-masked]>
Date: Wed, 11 Dec 2013 13:28:16 -0500

On Wed, Dec 11, 2013 at 12:44 PM, Ted Hardie <[email-masked]> wrote:
> limit our speech, the actual agency belongs with the monitors, not with us.
> In some cases this limitation may be a side effect; in some cases it is a
> desired outcome by the state actors taking this action.  While "attack" may
> come across as a loaded term, the impact and the threat are real.

For clarity are you talking about the impact of monitoring, or of
awareness of monitoring? There are people who never think someone
might be monitoring, and the existence of monitoring does not lead
them to self-censor.

Also, earlier today we had to allow that "need not be part of a
pervasive monitoring attack" ... but it can still be indistinguishable
from one.

Even so,

> monitoring represents a threat" and "We will work to mitigate that threat";

... that would work for me.

Scott

---

From: Jari Arkko <[email-masked]>
Date: Sun, 15 Dec 2013 13:07:58 -0500

Scott raised important points and so did Ted. I like Ted's wording, but it leave it to document editors to figure out the exact draft now that we agree with the sentiment.

FWIW when I have talked about this issue, I've usually talked about the fact that Internet has a vulnerability for pervasive monitoring and that we need to address that vulnerability just like we do with other vulnerabilities. (To our ability, just like with the other vulnerabilities.) "Threat" would work well for me, too.

Jari

---

From: Dave Crocker <[email-masked]>
Date: Sun, 15 Dec 2013 10:17:40 -0800

> FWIW when I have talked about this issue, I've usually talked about the fact that Internet has a vulnerability for pervasive monitoring and that we need to address that vulnerability just like we d…

+1

Within the IETF, I'm used to hearing security folk talk in terms of 
'threats', so the word 'attack' was a bit of a surprise.

It's worth using language that is already common in the IETF, and is as 
boringly neutral as we can get away with.  (In most of the world, the 
word 'threat' wouldn't be considered neutral, of course, but within 
technical security discussions, it seems to be.)

As others keep noting, within the IETF, our job is to focus on the 
technical issues of this topic.  That means we should avoid anything 
that excites opportunities for those other issues.  They're relevant, of 
course, but not in the IETF.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 16 Dec 2013 16:11:03 +0000

ISO 27000 (Information technology - Security techniques - Information security management systems - Overview and vocabulary)
defines both terms, and differently:

2.4
attack
attempt to destroy, expose, alter, disable, steal or gain unauthorized access to or make unauthorized use of
an asset (2.3)

2.45
threat
potential cause of an unwanted incident, which may result in harm to a system or organization

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: 15 December 2013 18:18
To: Jari Arkko; Scott Brim
Cc: Ted Hardie; Bjoern Hoehrmann; IETF discussion list
Subject: Re: Editorial thoughts on draft-farrell-perpass-attack-02

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

+1

Within the IETF, I'm used to hearing security folk talk in terms of 'threats', so the word 'attack' was a bit of a surprise.

It's worth using language that is already common in the IETF, and is as boringly neutral as we can get away with.  (In most of the world, the word 'threat' wouldn't be considered neutral, of course, but within technical security discussions, it seems to be.)

As others keep noting, within the IETF, our job is to focus on the technical issues of this topic.  That means we should avoid anything that excites opportunities for those other issues.  They're relevant, of course, but not in the IETF.

d/

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Dec 2013 11:56:36 -0500

Christopher,

> defiChristopher,nes both terms, and differently:
>
> 2.4
> attack
The definition for attack seems appropriate.  The definition for threat 
is not
bad, but I prefer an older one, commonly used in the military context, 
and which
matches with a trio of definitions for understanding security contexts:

Vulnerability - a flaw in a design of implementation of a security-relevent
protocol or system

Attack - more of less as above

Adversary - an entity with a set of motivations and capabilities to 
effect an attack

Threat - a motivated, capable adversary. An adversary who is capable, 
but not motivated, is not a threat. An adversary who is motivated, but 
not capable, is not a threat.

A threat model articulates adversaries and often enumerates classes of 
attacks, and
then discusses the perceived motivation and ability of adversaries to 
effect attacks
against a system of interest.

We lack a threat model for the Internet. Most of our security protocols 
do not
have published threat models (we didn't encourage this until recently) and
what is published typically is an attack model, not a threat model.

Most aspects of pervasive monitoring are indistinguishable from our 
traditional attack
model, since that model already assumes adversaries that can engage in 
passive and active wiretapping. If we had a real threat model, either it 
would have included a discussion of nation states as adversaries with 
the capabilities to do what we have seen that they
do, and a motivation to do so, or not. I'd like to see this document 
explicitly discuss this.

Steve

---

From: t.p. <[email-masked]>
Date: Mon, 16 Dec 2013 17:54:20 +0000

----- Original Message -----
From: "Stephen Kent" <[email-masked]>
To: <[email-masked]>
Sent: Monday, December 16, 2013 4:56 PM
> Christopher,
>
> > ISO 27000 (Information technology - Security techniques -
Information security management systems - Overview and vocabulary)
> > attempt to destroy, expose, alter, disable, steal or gain
unauthorized access to or make unauthorized use of
> not capable, is not a threat.

Stephen

As you know well, we have published RFCs with definitions of these terms
so we could use our own definitions - or we could use someone, anyone,
else's:-)

Tom Petch

PS for those who are not engaged with the IETF view of security, I am
referring to RFC2828 and its successor, RFC4949.  Sterling works.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 16 Dec 2013 13:34:47 -0500

Tom,

You're right that 4949 should be the preferred starting point for 
security terminology.

Steve

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 17 Dec 2013 10:10:17 +0000

I'm merely reporting what one international standard settled on. The point was just to note that the term attack is in use.

I'll just note that what you use for threat is a threat actor in some usages, but not ISO 27000's.

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: 16 December 2013 16:57
To: [email-masked]
Subject: Re: Editorial thoughts on draft-farrell-perpass-attack-02

Christopher,

> ISO 27000 (Information technology - Security techniques - Information 
> security management systems - Overview and vocabulary) defiChristopher,nes both terms, and differently:
>
> 2.4
> attack
> attempt to destroy, expose, alter, disable, steal or gain unauthorized 
> access to or make unauthorized use of an asset (2.3)
>
> 2.45
> threat
The definition for attack seems appropriate.  The definition for threat is not bad, but I prefer an older one, commonly used in the military context, and which matches with a trio of definitions for understanding security contexts:

Vulnerability - a flaw in a design of implementation of a security-relevent protocol or system

Adversary - an entity with a set of motivations and capabilities to effect an attack

Threat - a motivated, capable adversary. An adversary who is capable, but not motivated, is not a threat. An adversary who is motivated, but not capable, is not a threat.

A threat model articulates adversaries and often enumerates classes of attacks, and then discusses the perceived motivation and ability of adversaries to effect attacks against a system of interest.

We lack a threat model for the Internet. Most of our security protocols do not have published threat models (we didn't encourage this until recently) and what is published typically is an attack model, not a threat model.

Most aspects of pervasive monitoring are indistinguishable from our traditional attack model, since that model already assumes adversaries that can engage in passive and active wiretapping. If we had a real threat model, either it would have included a discussion of nation states as adversaries with the capabilities to do what we have seen that they do, and a motivation to do so, or not. I'd like to see this document explicitly discuss this.

Steve