Subject: Re: [saag] : Review of: Opportunistic Security -03 preview for comment

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 Aug 2014 17:36:00 +0000

On Fri, Aug 15, 2014 at 08:54:18AM -0700, Dave Crocker wrote:

> >    Designing and deploying a key management for the whole Internet is
> >    for now an unsolved problem.

Oops the word "system" got lost after "key management"...  Will
have to add that back when I next get a chance.

> >    The opportunistic security design pattern involves stepping up from a
> >    baseline security policy compatible with all relevant peers to the
> >    most secure policy compatible with the capabilities of a given peer.

> Actually, it involves stepping /down/.

The draft is providing a *definition*.  Definitions should be taken
at face value.  This is not an empirical statement whose truth one
can debate, it is a definition.

> >    A related goal is broader adoption of protection against active
> >    attacks, by enabling incremental deployment of authenticated
> >    encryption.
> 
> Although this sounds entirely reasonable, there is no explanation
> provided to make it credible.  (n fact it is not at all clear to me that
> is /us/ credible...)  How will use of an opportunistic pattern lea to
> broader adoption?

By enabling deployment that is incremental and yet on by default.
With "all or nothing" security there is no way to allow the network
effect to help reach near-universal adoption.

> >    Both opportunistically
> >    employed encryption and opportunistically employed authentication
> >    need to avoid deployment roadblocks and need to be designed with care
> >    to "just work".
> 
> I have no idea what the last sentence means.

It means mechanisms that consistently work out of the box, no need
to tune explicitly for each peer or prompt the user when they
predictably fail a significant fraction of the time.

> >    Opportunistic security does not start with an over-estimate of peer
> >    capabilities only to settle for lesser protection when a peer fails
> >    to deliver.  Rather, opportunistic security sets a minimum protection
> >    level expected of all peers, which is raised for peers that are
> >    capable of more.
> 
> This paragraph is not very helpful.  The issue here has nothing to do
> with estimation.  (Can a design pattern make an estimation?)

An estimate is what one has, when one has not ye performed the
measurement.  Perhaps a better word could be crafted here, suggestions?
I still think the original text is sufficient.

The first sentence is what you're consistently not taking at face
value, the point needs to be made.

> If authentication is required, we have classic authenticated encryption,
> not opportunistic <foo>.

Again no, you're still reading what you would have said, rather
than what the draft actually says.  The draft actually defines a
way to do "opportunistically employ" authentication.  And this is
important, and is the main point of departure from Steve Kent's
earlier draft.

"Required of all peers" is not opportunistic.  Required when advertised
By a given peer

> The 'opportunistic' construct is all about permitting lesser protection.
> If it isn't permitted, we are not in an opportunistic scenario.

Again, that's not the *definition* in this draft.  You might have
defined it that way, but this draft does not.

> The term needs to be quite disciplined about what is excluded and what
> is included.  As soon as the term is too broad, it is meaningless.

No, not meanigless, just not the meaning some would have come up with.

> >    Enforcement of authentication is not incompatible with opportunistic
> >    security. If an OS-enabled peer (A) makes available authenticated
> >    key material, e.g., via DANE, to peer (B), then B should make use of
> >    this material to authenticate A, if B is OS-enabled and supports
> >    DANE.
> 
> This is worded a bit differently than in the preview draft I saw, but I
> still have no idea what that sentence means.  The language that follows
> is about preference, not enforcement.
> 
> Ultimately I can't tell what the motivation for this sentence is.

You're still not reading the definitions as stated.

> > If authentication is only possible for some peers, then it is
> > acceptable to authenticate only those peers and not the rest.
> 
> It is only sometimes acceptable.  It is essential that the text here
> highlight that such a fallback needs to be the result of careful
> analysis and choice and not a casual default.

There is no fallback from a suitably advertised capability to be
authenticated (e.g. via DANE).  Similarly the TACK draft is a type
of opportunistically enabled authentication that is more of the
TOFU style.

> 
> 
> >    Employ PFS:  Opportunistic Security should employ Perfect Forward
> >       Secrecy (PFS) to protect previously recorded encrypted
> >       communication from decryption even after a compromise of long-term
> >       keys.
> 
> I'm told that PFS isn't really possible for asyncrhonous, object-based
> encryption, such as for email.

PFS works for hop-by-hop SMTP, but yes, not likely for end-to-end
S/MIME or PGP.  This could be qualified with "when possible" or
some such.

> > No misrepresentation of security:
> > 
> > Unauthenticated encrypted communication must not be misrepresented as
> > communication over a secure channel.
> 
> Oh boy.  That sentence is far too compact and not obviouly correct.  In
> fact it is arguably wrong.

That's the -02 draft text you're responding to.

> > In summary, the opportunistic security design pattern encompasses
> > protocol designs that remove barriers to the widespread use of
> > encryption on the Internet. The actual protection provided by
> > opportunistic security depends on the advertised capabilities of the
> > communicating peers. Opportunistic security aims to encrypt all
> > network traffic, while allowing fallback to cleartext with peers that
> > do not appear to be encryption capable.
> 
> Ran out of time.  Haven't reviewed the remainder...

So is this.

> 
> > 5.  Example: Opportunistic TLS in SMTP
> > 
> >    Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS
> >    ([RFC3207]) ESMTP extension.  MTAs acting as SMTP clients are
> >    generally willing to send email without TLS (and therefore without
> 
> Software does not have a 'will'.  I think what is meant here is 'able'.

Except that we're describing tolerated lower-bounds, not abilities.

> >    Therefore, MTAs that implement opportunistic TLS either employ
> >    unauthenticated encryption or deliver over a cleartext channel.
> 
>    deliver -> transmit

Sure.

> >    Recent reports from a number of large providers suggest that the
> >    majority of SMTP email transmission on the Internet is now encrypted,
> >    and the trend is toward increasing adoption.
> 
> This anecdotal comment isn't needed, isn't substantiated, and is going
> to be distracting when this document is read 20 years from now.  I
> suggest removing it.

The example is an anectote, a protocol case-study if you like, not
a specification.  It is I think useful to highlight a success of
OS in this space.

> 
> >    Not only is the STARTTLS advertisement vulnerable to active attacks,
> >    but also at present some MTAs that advertise STARTTLS exhibit various
> >    interoperability problems in their implementations.  As a result, it
> 
> Again, the ephemeral frame of refernce won't be helpful.
> 
> So:
> 
>     but also an MTA that advertises STARTTLS can produce various
> interoperability problems in its implementation.  As a result, it might
> choose to fall back to cleartext...

Except that the wisdom of the cleartext retry is rooted in the
operational status-quo.  When the interoperability issues with
clunky old MTAs fade away, the engineering trade-off will be
different.

> > 6.  Security Considerations
> > 
> >    Though opportunistic security potentially supports transmission in
> >    cleartext, unauthenticated encryption, or other cryptographic
> >    protection levels short of the strongest potentially applicable, the
> >    effective security for peers is not reduced.  If a cryptographic
> >    capability is neither required by policy nor supported by the peer,
> >    nothing is lost by going without.  Opportunistic security is strictly
> >    stronger than the alternative of providing no security services when
> >    maximal security is not applicable.
> 
> I'll repeat that counting "cleartext" as part of an opportunistic
> pattern is a strategic error.  In simple terms, it is saying that no
> security is part of security.

Yes, in order to make security usable, we tolerate no security as
a baseline where required.

> The issue is not that cleartext is bad or that permitting it might not
> be ok.  It's that it needs to be outside of the scope of an
> opportunistic pattern.

Disagree.  Otherwise we get into "fallback" and all that, but OS
is about attempting to get more than minimum (possibly none)
security.  Not about settling for less.  As defined!  Not empirical
fact to debate.  You could argue for a different definition, but
it should be clear that you'd prefer a different formulation, not
that the current one is "wrong".

> >    Opportunistic security coexists with and is preempted by any
> >    applicable non-opportunistic security policy.  However, such non-
> 
> This first sentence makes no real sense to me or worse is confusing.  It
> does not "coexist".  If it is preempted, it is at best subordinated.

Well, coexists and is subordinate to.  But that is clearly evident from
the text...

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 Aug 2014 19:11:29 +0000

On Fri, Aug 15, 2014 at 03:01:59PM -0400, Paul Wouters wrote:

> Background Encryption ?
> Preemptive Encryption ?
> Preventive Encryption ?
> Preventative Encryption ?
> Countermeassure Encryption ?
> Remedial Encryption ?

This boat has sailed:

    TLS -> TLE: Transport Layer Encryption?
    IPsec -> IPenc: IP encryption?
    SSH -> ESH: Encrypted SHell?
    HTTPS -> HTTPE: HTTP over TLE?
    ...

Let's talk about the substance of the draft.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 15 Aug 2014 16:29:12 -0400 (EDT)

>    HTTPS -> HTTPE: HTTP over TLE?

All these four protocols require AUTHENTICATION plus ENCRYPTION. Thus
there have a legitimate reason to call it security and not just
encryption.

> Let's talk about the substance of the draft.

This draft proposes encryption in the possible absence of
authentication. While I can call it privacy or encryption,
I have a very hard time calling it security. On top of that,
we all know we would have called ie opportunistic encryption
if that term had not been picked already. We know the term is
a workaround. Some just feel it is a bad workaround. For its
implied (misleading) meaning and for its terrible acronym of "OS".

RFC 4949 states:

$ security
       1a. (I) A system condition that results from the establishment and
       maintenance of measures to protect the system.

       1b. (I) A system condition in which system resources are free from
       unauthorized access and from unauthorized or accidental change,
       destruction, or loss. (Compare: safety.)

       2. (I) Measures taken to protect a system.

       Tutorial: Parker [Park] suggests that providing a condition of
       system security may involve the following six basic functions,
       which overlap to some extent:
       -  "Deterrence": Reducing an intelligent threat by discouraging
          action, such as by fear or doubt. (See: attack, threat action.)
       -  "Avoidance": Reducing a risk by either reducing the value of
          the potential loss or reducing the probability that the loss
          will occur. (See: risk analysis. Compare: "risk avoidance"
          under "risk".)
       -  "Prevention": Impeding or thwarting a potential security
          violation by deploying a countermeasure.
       -  "Detection": Determining that a security violation is
          impending, is in progress, or has recently occurred, and thus
          make it possible to reduce the potential loss. (See: intrusion
          detection.)
       -  "Recovery": Restoring a normal state of system operation by
          compensating for a security violation, possibly by eliminating
          or repairing its effects. (See: contingency plan, main entry
          for "recovery".)
       -  "Correction": Changing a security architecture to eliminate or
          reduce the risk of reoccurrence of a security violation or
          threat consequence, such as by eliminating a vulnerability.

The draft covers none of these listed items - it should not be called
"XXX security"

Paul

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 15 Aug 2014 16:35:09 -0400 (EDT)

> authentication. While I can call it privacy or encryption,

That is not an accurate summary of the proposals made by the draft.

The draft proposes to use what tools are available to do the best you can.
If the peer you're talking to has configured DANE records that you can
retrieve via DNSSEC, then you can authenticate that particular connection,
securely.  A protocol that performs such a lookup and authenticates that
connection is an opportunisticly secure protocol, because it does not
require that all connections have that lookup succeed -- the
authentication is performed opportunisticaly, when it is possible.

That is not to say that the draft is perfect; I have not finished a
detailed read of the -03, and there are certainly things that could be
improved.  Failing to do more than cover encryption is not one of them.

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 Aug 2014 20:48:14 +0000

On Fri, Aug 15, 2014 at 04:29:12PM -0400, Paul Wouters wrote:

> authentication.

No, this draft proposes encryption in the presence of peer encryption
support, and authentication in the presence of peer authentication
support as determined via suitable peer signalling mechanisms.

> While I can call it privacy or encryption,
> I have a very hard time calling it security.

Opportunistic DANE TLS for SMTP is security, but is only comprehensive
when the SMTP server publishes DNSSEC validated and MX RRs and
associated TLSA RRs for the MX hosts.  It is an example of OS.

Opportunistic (non-DANE) TLS (as in the draft's example section)
for SMTP is also security.  It is security against passive attacks,
that is, for a different threat model.

Both are OS, but the draft promotes designs that can do both
comprehensive (passive and active) and partial (passive-only)
channel security.

> On top of that,
> if that term had not been picked already.

I would have objected regardless.  Opportunistic security is a
better match than OE for the content of the draft.  I would not
have objected to Opportunistic Cryptosecurity, but it is not a
compelling improvement.

-- 
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 15 Aug 2014 17:06:45 -0400 (EDT)

> support as determined via suitable peer signalling mechanisms.

We already have drafts/RFCs for using advertised authenticated encryption,
such as webpki and DANE. This draft adds an opportune component
to strongly recommend unauthenticated encryption over cleartext in
ABSENCE of support of other drafts/RFCs for authenticated encryption.

> Opportunistic DANE TLS for SMTP is security

Some disagree about the use of the term opportunistic in this case.
If an SMTP client supports DANE, and is contacting an SMTP server
supporting DANE, there is nothing opportunistic about it. It MUST use
encryption and MUST NOT fall back to cleartext.

> It is security against passive attacks,

I don't disagree. But it is still only encryption.

> have objected to Opportunistic Cryptosecurity, but it is not a

While not compelling, it is an improvement :P

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 Aug 2014 21:14:57 +0000

On Fri, Aug 15, 2014 at 01:26:39PM -0700, Dave Crocker wrote:

> > While you seem to be saying opportunism is "In absence of
> > mandated authenticated encryption, try to use unauthenticated
> > encryption".
> 
> My definition:
> 
>      Opportunism is the flexibility to use less-stringent protection,
> when stronger protection is not possible.

This is a definition of something else.  That something is not the
subject of the draft.

> 
> > What Viktor is saying is that the parapraph in question makes sense
> > using his interpretation of the definition, and does not make sense
> > with your interpretation of the definition.
> > 
> > Clearly we have work to do to ensure there is only one interpreation of
> > the definition.
> 
> Yup.

Insisting that the draft should be defining something else is not
progress towards helping more readers arrive at a convergent
interpretation of the subject matter.

This sub-thread will become more productive, once the subject of
the definition or exposition (as imperfect as that might be) is
accepted as a starting point, and what we're discussing is how to
improve the clarity.

The subject is introducing the OS design pattern.  The OS design
pattern as introduced, is to set a least common denominator baseline
(crypto)security policy (that might well be cleartext) and from
there do better whenever possible for each peer.

For some unathenticated encryption is the best one can do.
For other peers authentication can be signalled and enforced.

The somewhat clumsy phrase "opportunistically employed" attempts
to capture this, without running into terminology trouble by talking
directly about "opportunistic encryption" or "opportunistic
authentication", at least the first of which is a booby trap due
to conflicting usage.

If someone can help improve the text that uses that construct, that
would be great.

Constructive comments will help to clarify the exposition of the
idea that can be casually summarized as: "spring forward" not "fall
back".

Another key pillar of the draft, is that OS designs need to not
create obstacles to communication.  In any OS design, whatever
security mechanisms are enabled based on peer signalling need to
be much more operationally reliable than present state of the art.

If an OS design cannot be enabled by default, and constantly pops
up dialogues for users to approve exceptions, then that design is
a failure.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 15 Aug 2014 21:19:50 +0000

> encryption and MUST NOT fall back to cleartext.

This myopically focuses on a single interaction of the protocol.
When an SMTP client supports DANE, it applies DANE security when
TLSA RRs are present, and not when they absent.  The use of DANE
is opportunistic.  

Thus the clumsy phrase "opportunistically employed" in the current
draft.  If anyone can suggest better language, please send a patch
for the XML:

    git clone https://github.com/vdukhovni/saag.git

-- 
	Viktor.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 15 Aug 2014 23:37:46 +0200

Hi Victor,

Having read through the latest draft, I have a few comments.

The principles stated in the draft seem like really good ones.  I
personally care more about those principles and less about the
definition.  But I agree with Dave on his point about the definition. 
If we could focus on the core principles and perhaps note that the term
is imperfect (and we just don't have a better one), then perhaps we have
a way forward.

I actually like your term "opportunistically employed", but I do agree
that it is possible to wordsmith the explanatory text to be a little
less... cryptic.  Fundamentally I think that's the key to the whole draft.

Eliot

---

From: Randy Bush <[email-masked]>
Date: Sat, 16 Aug 2014 06:51:30 +0900

> draft.  If anyone can suggest better language, please send a patch

as i said (privately) to pete,

the problem is that "opportunity" does not convey "as well as can be
done in the circumstances."  it means "something that works."

i can not think of an american english word that conveys what you want.
gambatte, which can mean "do your best," comes closer but is a verb.

randy

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 16 Aug 2014 04:48:54 +0000

On Fri, Aug 15, 2014 at 09:03:09PM -0700, John Wroclawski wrote:

> From my point of view, these two wordings are indistinguishable.
> Setting a least common denominator and doing better whenever possible
> *is* using less-stringent protection when stronger protection is
> not available. I understand there?s nuance, relating to per-peer
> (which I think everyone agrees with), to the multiple dimensions
> of protection, and to whether ?none? is a variant of ?least? or
> not. But IMO, fundamentally these two sentences say the same thing.
> If the intent is that they don?t, *very* different words may be
> needed.

Except that it is different.  There is no need to make a big "your
security may be degraded" fuss when doing better than expected.
However, when failing to achieve a security goal, and settling for
less, applications have tended to put up all sorts of warnings,
fussy dialogues, ...  And are often unwilling to do less that the
maximum, and simply fail.

The change of perspective is crucial to making progress.  Cleartext
is the baseline, not comprehensive protection.  You don't fall back
from comprehensive protection, when it is does not work out, ...
You do better than the baseline when that is possible, and just
works, without disrupting communication in the absence of an attack.

This is a design guide (manifesto), not not a protocol specification,
and setting things in the right perspective matters.

It is important to understand that peer capabilities you can assume
to be there are only those that are required and available to all
peers, anything else is something that requires a specific capability
advertisement.

It makes little sense to talk about fallback from authenticated
encryption, because authentication is mostly only useful when it
is enforced.  It makes more sense to talk about enforcing authentication
when the peer publishes the appropriate key material (DANE, TACK,
...).

The mandated model of security, where everybody has to implement
it or they don't play the game, makes sense in top-down environments
like the military or enterprises.  It is not a good model for the
Internet.  We've tried it for a few decades now, it has not worked
well.  It is time for a more flexible, pragmatic approach.  I expect
opportunistic security to provide more security to more peers than
the top-down models we've grown accustomed to.

The language matters, it sets the correct mental model for moving
forward.  We need to prioritize the user's needs (move the bits)
first, and layer as much security on top of that as we can, but no
more.  Yes, you can describe a fun-house mirror view of this, in
which we're falling back from comprehensive security, But that is
not a good way to think about it.  Especially when you conclude
that authentication is not opportunistic or cleartext is outside
the artificial boundary drawn around opportunistic security,
making just unauthenticated crypt be opportunistic security, and
everything else is out.

The result of that view would be everyone implementing unauthenticated
crypto, and calling it a day.  That would be a shame, because in
the long run we do want protection from active attacks, and a way
of getting that deployed, and enabled by default, and yet not
disrupting communication when not under attack.

Perhaps I should expand the example section to explain opportunistic
DANE TLS for SMTP (even if that spec is still some weeks from LC),
not just opportunistic TLS.  Then people might have a better
understanding of how opportunistic authentication works with DANE,
and should work generally.  I don't want the draft to over-emphasize
DANE, it not just about DANE, but leaving out that example may have
resulted in text that is a too abstract.

-- 
	Viktor.

---

From: ianG <[email-masked]>
Date: Sat, 16 Aug 2014 14:10:32 +0100

> there have a legitimate reason to call it security and not just

Yes, but where is it written that SECURITY requires AUTH + ENC?  As far
as I know, this derives from a model sometimes called the Internet
Threat Model, referenced in one of those RFCs that Stephen posted a
month back.  The model itself dates back to CIA (the term not the
spooks) and military context where MITM is a game they play if they can.

That's a particular model of security, or a pattern or a tradition.  It
isn't synonymous with security per se.

> a workaround. Some just feel it is a bad workaround.

I disagree, I'm not part of that consensus.  From where I sit, AUTH is
just as good a target for opportunism as ENC, it's something that can be
reasonably left to a higher layer if that higher layer has some better
approach.  E.g., SSH & Skype.

> For its

>From a human/user perspective, that's a very curious definition of
security.  I'd rather define security by the protection that the user
usefully received than by measures that the system prescriptively stated
and imposed on the hapless user.

But, looking at the definition as it is writ:  'Measures' is left
undefined by definition, probably outsourced to some model (or standard
or whatever you want to call it).

So in one hypothetical model, if 'Measures' equals encryption then the
definition is met, yet in another hypothetical if 'Measures' equals
authentication, it is also met.

A system is therefore secure if it says it is.  Opportunistic security
therefore meets its own objectives because it says what it does;  it
just sets a variable number N of 'Measures' dynamically, doesn't fix
them in static policy.

>       destruction, or loss. (Compare: safety.)

Right, so this might be seen to set a higher conceptual set of
requirements, closer to my view of usefully protecting the user, as
opposed to 'Measures' in 1a.

>          threat consequence, such as by eliminating a vulnerability.

(These aren't 'Measures' of a security system as per 1a, they are more
characteristics of a mitigation deriving from a risk analysis;  to unify
1 & 2, perhaps mitigations is a better word for 1a than 'Measures'.)

> The draft covers none of these listed items - it should not be called

Is it the consensus that RFC4949 should be followed on the definition of
security?  From the snippets above, I'd say that's a bad idea.  But if
so, let's say so...

iang

---

From: Theodore Ts'o <[email-masked]>
Date: Sat, 16 Aug 2014 09:12:27 -0400

> works, without disrupting communication in the absence of an attack.

Yes.  This.  It would be good to have something which states this
explicitly in the introduction of the I-D.  A careful reader can infer
this, but I think it's good to state this explicitly.

Something else that I think would be good to include in the
introduction is as we improve from cleartext to "authenticated,
encrypted, and protected against passive and active active attacks",
that the way station of "protected only against passive attackers" is
a _still_ better than just staying at cleartext.

The second paragraph of the abstract:

   This document promotes designs in which cryptographic protection
   against both passive and active attacks can be rolled out
   incrementally as new systems are deployed, without creating barriers
   to communication.

... seemes to emphasize more the concept of "some of the time" and
doesn't spell out that the rollout might include protection against
passive attacks only as being (a) within the scope of this document,
and (b) desirable if the alternative is cleartext.

> and setting things in the right perspective matters.

Something that might be useful along this front, if we can find an
appropriate reference, is the (possibly apocryphal, or maybe the
authorative source is classified, perhaps out of embarassment?  :-)
story about air force pilots who would deliberately disable their
fancy NSA-provided crypto gear because in a combat situation, when
friendly fire can really ruin your day (or not getting support to
ground forces who were using an incompatible crypto system),
communicating in the clear is far more important than not
communicating at all....

						- Ted

---

From: Dave Crocker <[email-masked]>
Date: Sat, 16 Aug 2014 07:44:52 -0700

> gambatte, which can mean "do your best," comes closer but is a verb.

The usual phrase to approximate that meaning is "best effort".

Not a single word, but a common enough term.

The focus of the draft is quite clearly encryption.  Any other security
mechanism that is cited is in the service of encryption only.

Hence the simplest, clearest and most intuitive term for what is being
described is "best effort encryption".

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Sat, 16 Aug 2014 08:16:51 -0700

> approach.  E.g., SSH & Skype.

In a general discussion about 'flexibility' in security-related
mechanisms, you would be correct.

However the current draft has a more limited scope.

Its focus is encryption.  Any other security-related topic, such as
authentication, is ONLY discussed in terms of encryption.

I'll emphasize that the assertion of scope is not just what I'd like it
to be but an observation of what the draft actually IS.

This draft is not a general exploration of opportunism in the world of
security mechanisms.  It is supposed to be an attempt to define and
explain flexibility in mechanisms providing encryption.  It achieves the
exploration.  It lacks text that qualifies as a definition.

d/

---

From: ianG <[email-masked]>
Date: Sat, 16 Aug 2014 16:30:17 +0100

> exploration.  It lacks text that qualifies as a definition.

I do not derive this assertion of scope from the draft.  Can you outline
where this limitation comes from?

I'm aware that the inspiration for the draft comes from the PM side.
But unless we believe that the anti-PM project only inspires hammers
that will hammer anything to submission, nail or not, I can't see
immediately why a tool can't be more general.

iang

---

From: John Wroclawski <[email-masked]>
Date: Fri, 15 Aug 2014 21:03:09 -0700

Oh *man* I’m going to regret this.

Hi. Jumping randomly into this conversation from the point of view of someone who is fascinated by the dynamics but, yes, _has not read the draft_, I’d like to observe something.

On Aug 15, 2014, at 2:14 PM, Viktor wrote:

>> <D. Crocker’s definition:
>> 
>>     [D. Crocker] Opportunism is the flexibility to use less-stringent protection,
> subject of the draft. […]
> 

From my point of view, these two wordings are indistinguishable. Setting a least common denominator and doing better whenever possible *is* using less-stringent protection when stronger protection is not available. I understand there’s nuance, relating to per-peer (which I think everyone agrees with), to the multiple dimensions of protection, and to whether “none” is a variant of “least” or not. But IMO, fundamentally these two sentences say the same thing. If the intent is that they don’t, *very* different words may be needed.

Similarly,

On Aug 15, 2014, at 1:48 PM, Pete Resnick <[email-masked]> wrote:

> Hatless...
> 
> […]
> Opportunism here is to take the opportunity to do the *best* encryption you can do. If the other end advertises authenticated encryption, you take the opportunity to do authenticated encryption. If that's unavailable but you can do unauthenticated encryption, that's the best you can do and you opportunistically do that. […]
> 
>> [Crocker, again] Opportunism is the flexibility to use less-stringent protection, when stronger protection is not possible.
>>   
> Using less-stringent protection when stronger protection is not available is not an "opportunity". It's a compromise. 

Again, to my mind there is *no difference* between the words "If X is unavailable but you can do Y, that's the best you can do and you opportunistically do that” and the words "Using less-stringent protection when stronger protection is not available …”, yet in one case it’s being given as an example and in the other case it’s being stated as an incorrect non-example. “this won’t do”, as they say.

To be clear: I am not at all meaning to pick on Victor or Pete or Dave specifically. But I thought it might be useful to mention that from the perspective of someone who’s randomly walked into the back of the virtual room and is trying to understand things just from the emails, you guys are saying exactly the same thing, and then claiming you aren’t.

cheers
john

---

From: <[email-masked]>
Date: Sat, 16 Aug 2014 05:01:59 +0000

The phrase I would use here is something like 'graceful escalation in the security of communication capability, from cleartext to best, and graceful degradation to cleartext as a minimum where necessary'. Only reworded to be less wanky, of course.

As Viktor says, in security minds, there does not appear to be a concept of graceful degradation - either it's considered secure to all possible attacks, or it's (just) been broken and it's not - hence the whole never-ever-use-MD5-ever-in-any-context kerfluffle of old.

Expanding the examples to cover http/https will give a better idea of the scope, I think.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf <[email-masked]> on behalf of Viktor Dukhovni <[email-masked]>
Sent: Saturday, 16 August 2014 2:48 PM
To: [email-masked]; [email-masked]
Subject: Re: [saag]: Review of: Opportunistic Security -03 preview for comment

--
        Viktor.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 16 Aug 2014 09:20:10 -0700

On 8/16/2014 8:30 AM, ianG wrote:
>> explain flexibility in mechanisms providing encryption. 
...

It is pervasive in the document:

> Abstract
...
> For example, the majority of Internet
>    SMTP traffic is now opportunistically encrypted.

No reference to authentication.

> Terminology
...
> Authenticated encryption:
...
> Unauthenticated encryption:

No definitions related to authentication itself.

> 3.  The Opportunistic Security Design Pattern
> 
>    Opportunistic Security is a protocol design pattern that aims to
>    remove barriers to the widespread use of encryption on the Internet.
...
>    o  No encryption (cleartext), which provides no protection against
...
>    o  Unauthenticated encryption (definition in Section 2), which
...
>    o  Authenticated encryption, (definition in Section 2) which protects
>       against both passive and active attacks.
...
>    An opportunistic security protocol first determines the capabilities
>    of a peer.  This might include whether that peer supports
>    authenticated encryption, unauthenticated encryption or perhaps only
>    cleartext. 

No equivalent, /separate/ reference to authentication or any other
security mechanisms.

The rest of that section continues with the same focus, as does the rest
of the document.

Throughout the draft, the standalone references -- that is the term that
focuses a statement -- is either "opportunistic security" or "encryption".

The first term is used, perhaps, as if it means more than encryption,
but there is never any substance provided to make that real.  All of the
substance concerns encryption.

I believe that's because that is the actual focus right now.  I also
believe that's entirely appropriate.

Everything else is abstract and without current effort or, frankly,
thought.  Hence the term should make clear that the issue at hand is
encryption.

d/

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Aug 2014 16:07:43 -0400 (EDT)

On Sat, 16 Aug 2014, John Wroclawski wrote:

> Hi. Jumping randomly into this conversation from the point of view of
> someone who is fascinated by the dynamics but, yes, _has not read the
> draft_, I’d like to observe something.
>
> From my point of view, these two wordings are indistinguishable. Setting
> a least common denominator and doing better whenever possible *is* using
> less-stringent protection when stronger protection is not available. I
> understand there’s nuance, relating to per-peer (which I think everyone
> agrees with), to the multiple dimensions of protection, and to whether
> “none” is a variant of “least” or not. But IMO, fundamentally these two
> sentences say the same thing. If the intent is that they don’t, *very*
> different words may be needed.

[trimmed the other example]

Perhaps the part that is missing is what Ted was referencing, namely the
unstated goal that the baseline can be raised over time, after gradual
adoption of the better-protection options has reached a sufficient
proportion of the population such that the downside of increasing the
baseline is minimal.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Sat, 16 Aug 2014 15:19:47 -0500

> resulted in text that is a too abstract.

For me DANE is the critical piece to understanding how the OS protocol
design pattern can raise the floor without lowering the ceiling and
without encouraging a general reduction of security against active
attacks.  The key lies in DNSSEC's authenticated non-existence
functionality.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 16 Aug 2014 15:53:13 -0500

> No reference to authentication.

That is a description of reality, and the reality is IIUC that SMTP is
now opportunistically encrypted without authentication, thus no mention
of it.

Anyways, I don't see the abstract as evidence of any pervasive flaw in
the I-D.  It is true that SMTP -being a store-and-forward protocol- is a
bit far removed from user experience (therefore authentication
requirements and status are a bit difficult to denote), therefer perhaps
not the best OS use case for this I-D, but it's also the _first_ and
most widely deployed OS application, therefore it is a great use case
for this I-D.  It is what it is.

> No definitions related to authentication itself.

Propose text!

> No equivalent, /separate/ reference to authentication or any other

Eh?  As in integrity protection without confidentiality protection?  If
so, "meh".  I don't think listing that would improve anything here.

> thought.  [...]

It is abstract.  Necessarily.  Because it's not proposing specific
protocols.  The "without thought" part is clearly incorrect (is there
any way to take it as anything other than intended to slight??).

>   [...].  Hence the term should make clear that the issue at hand is
> encryption.

You're the one focusing on encryption.  The DANE use cases can result in
strong authentication in addition to mere encryption!  That makes
"encryption" unsuitable for the term we need for this protocol design
pattern: encryption is not the only trick this opportunistic pony can do.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 16 Aug 2014 16:01:18 -0500

> > All these four protocols require AUTHENTICATION plus ENCRYPTION. Thus

Not.

 - SSH's initial success is largely due to TOFU.
 - TLS supports unauthenticated use cases (ADH ciphersuites).
 - IPsec has BTNS.

> isn't synonymous with security per se.

Right.  Security is relative.  Relative to: adversaries, and baselines.
If your baseline is _no_ security, then any improvement _is_ "security"
(again: SSH and TOFU).  If the threat is massive collection of
plaintext, then unauthenticated encryption is a massive improvement over
cleartext communications.

Security is a very relative term.

Encryption pretty much isn't.

Since encryption is meaningless without a discussion of key management,
everyone I know in this industry regularly regards with scorn any
product advertisements that highlight AES-256 or "256-bit security", and
so on -- it's all snake oil unless all the details are discussed and
analyzed.  This is why "TLS" >> "AES" in marketing materials, for
example.  And this is why "security" >> "encryption" for the term at
hand.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 16 Aug 2014 16:04:54 -0500

> The usual phrase to approximate that meaning is "best effort".

No.  "Best effort" has negative connotations.  "Opportunistic" has both,
negative and positive connotations.  And the protocol design pattern at
hand is very much a positive, not a negative.  It would be destructive
and awful marketing to settle for a term that has negative connotations
when the thing for which the term will stand has positive value.

> described is "best effort encryption".

No, a thousand times no.  It's not about encryption.  It's about
security.  Security is a relative term (see separate post).  See above
as to "best effort".

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 16 Aug 2014 16:19:20 -0500

> immediately why a tool can't be more general.

I believe technology is morally neutral.  I have no idea what anti-PM
technology will inspire, nor do I think that relevant here, though to
humor you, my guess is that massive cleartext collectors won't pack it
up and go home.  I offer that guess to make this clear: OS is NOT about
anti-PM, but about greatly improving security for every day users of the
Internet.

That's all neither here nor there.  Anti-PM may or may not have been an
inspiration for Viktor's I-D; either way is irrelevant at this point.

These questions that I think are relevant:

 - Is the OS protocol design pattern bad in any way?

   It took me some time to reach my answer ("no").  DANE was the key to
   my reaching that answer.

 - Can we improve the proposed OS protocol design pattern?

Questions as to wordsmithing are also relevant, but much less important
than those two questions above.

Thus far I see no one making any serious arguments that the proposed OS
protocol design pattern is bad in any way except that it might encourage
settling for unauthenticated encryption as the most common, and maybe
only common usage.  My answer to that (Viktor's answer to that!) is
"DANE", and I believe this is fairly well accepted by now amongst
reviewers who had this concern (which includes myself!).

As for improvement on the protocol design pattern, so far I've seen no
discussion.

My take is that we have consensus about what matters most here.  Publish
the thing!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 16 Aug 2014 16:52:22 -0500

> encryption and MUST NOT fall back to cleartext.

I suppoe it's all about definitions.  Viktor's point is that the client
is willing to use TLS or not depending on whether it knows (local
config) or could know (DANE) that it must, with the latter being
opportunistic.  The opportunity in the DANE case is really the server's:
if it publishes TLSA RRsets...

> While not compelling, it is an improvement :P

Cryptosecurity reals like snake oil to me.  Or, at least, that's how I
fear it will read to non-initiates.  I _feel_ that cryptosecurity is
worse than not an improvement.  It's a feeling, difficult to back up
with facts and readon.  But bikeshedding is like that (please do not
take that as an insult.  Bikeshedding is a very common kind of argument,
and I've done it myself.  It happens, we call it, and then generally it
ends.).

---

From: Dave Crocker <[email-masked]>
Date: Sat, 16 Aug 2014 15:05:00 -0700

>>> where this limitation comes from?

Please note that my message was in response to this query by you.

I provided documentation of the document's limited scope.

The limitation is in the nature of what it discusses and what it does
not discuss.

> That is a description of reality, 

That's not the point.  The point is that it is what the document discusses.

>> No definitions related to authentication itself.

No.

I documented the reality of what the document discusses.  I happen to
agree with that limited scope, so I've no interesting in aiding the
mistake of expanding it.

Since you are so enthusiastic about insisting that its scope be
expanded, the task of providing text falls on you.

> so, "meh".  I don't think listing that would improve anything here.

Again, the issue I was responding to was not about 'improving' the
document (nor about its 'deficiencies, but documenting that its content
is clearly limited quite strictly to a focus on encryption.

> You're the one focusing on encryption.

The document is.

The burden now falls on you to cite text in the draft that does not have
encryption as its focus.

d/

---

From: Nico Williams <[email-masked]>
Date: Sat, 16 Aug 2014 17:44:27 -0500

> expanded, the task of providing text falls on you.

If the proposed score expansion is to include ESP Null, then "meh".

If the proposed expansion is to cover authentication, then that is already
covered.  Perhaps you want more emphasis given to it?

If the proposed score expansion is something else, please restate it.
There has been so much written so far that I've lost track.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 16 Aug 2014 15:59:23 -0700

On 8/16/2014 3:44 PM, Nico Williams wrote:
> On Aug 16, 2014 6:07 PM, "Dave Crocker" <[email-masked]
> <mailto:[email-masked]>> wrote:
>>
...
> If the proposed expansion is to cover authentication, then that is
> already covered.  Perhaps you want more emphasis given to it?

The only discussion that the draft has about authentication is in terms
of encryption.

There is no standalone discussion of anything that might be taken as
"opportunistic authentication" or even an indication of what that means.

> If the proposed score expansion is something else, please restate it. 

Again, Nico, I am not proposing an expansion of scope.  You are claiming
it's already expanded and I have documented that it is not.

> There has been so much written so far that I've lost track.

Indeed.

d/

---

From: Nico Williams <[email-masked]>
Date: Sat, 16 Aug 2014 21:23:55 -0500

> "opportunistic authentication" or even an indication of what that means.

There is.  I'm not in a position to quote from it at the moment though.

> it's already expanded and I have documented that it is not.

Are we reading the same I-D?  But look, I have opined that more text on the
DANE case would be good.  Would that satisfy you?  (If so I'll have
completely misunderstood you earlier.)

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 16 Aug 2014 23:13:23 -0400

> attacks.  The key lies in DNSSEC's authenticated non-existence

???

DANE isn't opportunistic security. It is authenticated security policy
and keys. Thats the opposite of opportunistic.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 16 Aug 2014 23:17:56 -0400 (EDT)

> and keys. Thats the opposite of opportunistic.

There is a protocol design pattern that involves optimistically checking
for and using DANE records where they exist, and not using them when their
existence has been authoritatively denied.  The overall protocol is
optimistic, in that the use of DANE is not required, but its benefits are
used when available.

-Ben

---

From: Dave Crocker <[email-masked]>
Date: Sun, 17 Aug 2014 06:20:55 -0700

On 8/16/2014 8:17 PM, Benjamin Kaduk wrote:
>>> DANE isn't opportunistic security. It is authenticated security
>>> policy and keys. Thats the opposite of opportunistic.
> There is a protocol design pattern that involves optimistically
> checking for and using DANE records where they exist,

This is an example of confusion about the meaning of the term design
pattern.  It is, equally, an example of the draft's limitation in
carefully documenting the concepts it is attempt to teach.

There is nothing in the document that clarifies the point.

By my reading of the current draft, it discusses the distinction between
authenticated and unauthenticated encryption.  However it does not
indicate that there is an important difference between one kind of
authenticated versus another kind of authenticated.

In other words, does the term design pattern concern basic functional
differences (eg, authenticated vs. not authenticated) or does it concern
specific functional differences (CA-based authenticated vs. DANE-based
authenticated)?

My own view is that the utility of the term offered in the current draft
concerns only very basis differences, and such details as which kind of
exsternal authentication 'anchor' is used is of less import.

Well...  perhaps the difference between a TOFU and an "anchored"
authenticated matter.  But I do not see what significant utility is
achieved by distinguishing between different types of anchored
(independent, fixed, ...) authentication is used.

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 17 Aug 2014 06:28:13 -0700

> There is.  I'm not in a position to quote from it at the moment though.

Then you have some homework to do.

Please do post another note when you have found the necessary details.

> Are we reading the same I-D?

Probably not.

However I've made a point of documenting what I've seen in the draft.

Your turn.

d/

---

From: ianG <[email-masked]>
Date: Sun, 17 Aug 2014 14:52:31 +0100

> carefully documenting the concepts it is attempt to teach.

I am not confused at all about the term 'design pattern', it's a term in
wide-spread usage.

I'd also say that if there is any confusion, the draft is not the right
place for that to be defined.  Once the draft decides to define concepts
and terms in ordinary and routine use, then it's gone too far.

(OK, so perhaps the words above should have read:  DANE follows the OS
design pattern of optimistically checking...)

> authenticated versus another kind of authenticated.

It should not need to do that.  The point is to take auth as
opportunistic in general and not to categorise different ways of doing auth.

> specific functional differences (CA-based authenticated vs. DANE-based

The term design pattern can do either.  But the use of the term in the
draft is to indicate that any auth method, be it ca or dane, can be seen
as an element in an opportunistic approach.

Once you see many auth methods as just more tools in the kit, there is
no point in cataloging them.

> (independent, fixed, ...) authentication is used.

If there is a point, it is to show that we can pick and choose?  In
order to illustrate the sense of the design pattern at hand.

iang

---

From: ianG <[email-masked]>
Date: Sun, 17 Aug 2014 14:56:32 +0100

> "opportunistic authentication" or even an indication of what that means.

Perhaps the problem here is that the draft title should be seen as more
like:

    "Opportunistic Security, with examples for encryption."

iang

---

From: Paul Wouters <[email-masked]>
Date: Sun, 17 Aug 2014 10:44:32 -0400 (EDT)

> and keys. Thats the opposite of opportunistic.

And this is why OS is a bad term. People still don't see this new term
as meaning "do authenticated encryption protocols when possible, anonymous
encryption with fallback to clear if not".

Paul

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 18 Aug 2014 00:20:41 -0400 (EDT)

> carefully documenting the concepts it is attempt to teach.

I hope you will forgive my confusion, but I'm not sure what confusion my
statement is supposed to be an example of.  My best hypothesis so far is
that this is supposed to refer to your question about whether the term
"design pattern" concerns basic functional differences or specific
functional differences, but I'm not entirely sure.

> There is nothing in the document that clarifies the point.

I do not dispute that the draft could make this point in a much clearer
fashion; I have not gone over it with a fine-enough-toothed comb to make
the claim that it contains "nothing" to clarify the point, though.

> exsternal authentication 'anchor' is used is of less import.

I would say that the term "design pattern" can apply to either basic or
specific differences, depending on the context in which it is being
applied.  In this specific case, I would like it to actually apply to both
(in that I see the optimistic security family of protocols including both
general recommendations ("use encryption") and specific ones ("if you can
use DANE as a trust anchor, attempt to do so, but fall back if there is no
record").

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 18 Aug 2014 15:44:56 +0000

On Mon, Aug 18, 2014 at 12:20:41AM -0400, Benjamin Kaduk wrote:

> "if you can
> record"

[ Just want to add a possibly useful terminology improvement in
  light of the draft.  ]

Note, I'd like to promote the view that not negotiating a stronger
mechanism is not fallback.  In the next (2.12) Postfix development
snapshot or so, while opportunistic DANE TLS still employs DANE
when TLSA records are present and not otherwise, one can also
specify a "fallback" TLS security level of "encrypt" or "may",
which is used when DANE TLSA records are present, but authentication
fails!  This is effectively an "audit" mode of authentication
enforcement, where mail is delivered even if authentication fails
(possibly even in the clear with "may"), but warning are logged,
making MiTM at least tamper-evident for those who enable this and
don't just ignore the logs.  Sending sites concerned with the
potential impact of enabling opportunistic DANE TLS on mail delivery
can initially turn it on in "audit-mode".

So I'd like to think of "fallback" as the kind of noisy "your
security is degraded, here's a dialogue to say it's OK" mess that
we're currently in when not able to create a suitably secure channel.
With opportunistic security, when the peer does not advertise
support for some mechanism, and as a result that mechanism is not
employed, there is no fuss, the peers operate closer to the baseline
security level.

[ Note, there is no specific recommendation to use DANE in the
  draft.  This is deliberate, I wanted to avoid giving mechanism-specific
  advice.  Be it at the cost of greater abstraction.  ]

The text about DANE in the draft, carefully suggests that it is
but one of many possibilities.

     Opportunistic security protocols should provide a means to
     enforce authentication for those peers for which authentication
     can be expected to succeed based on information advertised by
     the peer via DANE, TOFU or other means.  With DANE, the
     advertisement that a peer supports authentication is
     downgrade-resistant.  What is "opportunistic" here is the
     selective use of authentication for certain peers; much in
     the same way as unauthenticated encrypted communication may
     be used "opportunistically" with peers capable of more than
     cleartext.

     Enforcement of authentication is not incompatible with
     opportunistic security.  If an OS-enabled peer (A) makes
     available authentication key material, e.g., via DANE, to peer
     (B), then B should make use of this material to authenticate
     A, if B is OS-enabled and supports DANE.

Of course at this time only DANE provides (for as yet too few
domains) an authenticated channel with authenticated denial of
existence for publishing peer authentication material.  So I cannot
offer practical examples of this with a different underlying
technology.

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 18 Aug 2014 17:18:07 -0400

Nico,

> On Sat, Aug 16, 2014 at 03:44:26PM -0400, Michael Richardson wrote:
>> (I think we are boiling the ocean on this document. Publish it)
let's not. The doc is very poorly written. It has internal consistency 
problems,
is haphazard in its organization, sloppy in choices of wording, ...
> This.
>
> Either folks find a bug in the concept/text, they propose new text, or
> they accept it.  So far I see lots of bikeshedding.
I have provided concrete suggestions, almost all of which have been ignored.
Pride of authorship seems to be getting in the way here.

Steve

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 18 Aug 2014 23:28:25 -0400 (EDT)

> is haphazard in its organization, sloppy in choices of wording, ...

I expect that we've published documents which have much worse quality of
writing.  (That doesn't necessarily mean that we need to settle for what
we've got, here.)

I do have a great deal of sympathy for Viktor, trying to keep up with all
the traffic being written about this document.  It is hard to find the
time to keep up with everything and give responses everywhere.

-Ben

---

From: Dave Crocker <[email-masked]>
Date: Tue, 19 Aug 2014 07:37:15 -0700

> I am not confused at all about the term 'design pattern', it's a term in

The examples I cited were for very different meanings. They undermine
the current usage.

Since you say it is in common usage -- presumably with a related meaning
as that in the draft -- please provide some pointers to examples.

> opportunistic in general and not to categorise different ways of doing auth.

It very much /does/ need to do that.

If the document is to have practical benefit, it needs to define things
carefully and to make the use of the term concrete.  The alternative is
a term that has no meaningful anchor in the real world.

The concrete discussion in the document is about encryption. There is no
discussion at all about authentication or any other aspect of security,
as stand-alone functions.

If the document is meant to apply to anything other than encryption, it
needs to make the explicit, including discussion of concrete usage, or
at least examples.

> as an element in an opportunistic approach.

I don't see text that says that, independent of encryption.

Worse, the extent to which it is claiming an important,
protection-related distinction between a CA-based independent validation
mechanism and a DANE-based validation method, it does not explain how
that difference is important in security terms.

Arguably, in terms of general concerns about protection, they aren't
meaningfully different.  Consequently, casually citing them doesn't
accomplish much.

One could imagine a discussion that explores having a single service
with the ability to use a variety of different authentication validation
methods, but that isn't in this document.

> order to illustrate the sense of the design pattern at hand.

I could imagine having a paper that explores such choices and then
provides a variety of examples.

This draft isn't that paper.

d/

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 19 Aug 2014 16:42:07 -0400 (EDT)

> as that in the draft -- please provide some pointers to examples.

I think probably the easiest way to find some examples is to load up
www.amazon.com and search for "design patterns" in the "books" category.

[lots of point-by-point commentary trimmed]

> This draft isn't that paper.

Dave, I think you've done a great job reading the document and pointing
out places where the text of the document does not match well to how
people are describing what they want the document to say in the list
discussion.  I think it would be a much more productive use of everyone's
time to actually go and make the document say what people want it to say,
rather than continuing to discuss the ways in which the current text is
flawed.

I, for one, have been trying to do so.

As a case in point, we seem to have some concern that the term
"authenticated encryption" is poorly defined or confusing or otherwise
problematic.

In
https://github.com/kaduk/saag/commit/1e10ebc320d1a4d13dd0c693b07bba2492aa1947
, I propose to define a new term "authenticated connection" and define
authenticated and unauthenticated encryption in terms of whether or not
the encrypted data is transiting an authenticated connection.  By
separating the two security mechanisms, I think that the potential for
confusion is reduced.

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Aug 2014 20:54:31 +0000

> separating the two security mechanisms, I think that the potential for

Based on Steve Kent's earlier suggestion, I had updated my
work-in-progress document to avoid the problematic term.

Note, in many cases what we have is "authenticated sessions".  Not
all protocols are "connection oriented", and notably TLS supports
session resumption.  So "authenticated connection" is perhaps not
optimal.  I had used "authenticated encrypted communication" as
suggested, but will see whether that is still needed after further
suggested revisions.

Thanks for the concrete feedback, it is much easier to work with
suggested text than without.

-- 
	Viktor.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 19 Aug 2014 17:02:59 -0400 (EDT)

> suggested, but will see whether that is still needed after further

I agree that non-connection-oriented protocols can cause confusion here,
so "authenticated sessions" may be better.

-Ben

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Aug 2014 11:03:52 -0400

Ben,

You noted my use of the phrase "Opportunistic Crypto-Secruity" instead 
of "Opportunistic Secruity."
I made the change after someone else suggested it as a more precise 
description of what we're
doing, and because it has the advantage of being represented by an 
acronym that isn't so common
(OCS vs. OS) in our arena.

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Aug 2014 16:11:22 +0100

Steve, Ben,

With no hats, I prefer OS to OCS myself. Can't recall if I said
that on list before or not, sorry;-)

Wearing my "will have to figure out rough consensus" hat - let's
not debate that again, I think everyone who stated a position on
it was already clear, so I can't imagine what's left to be said.

But if someone who's not yet stated an opinion wants to, that'd
be fine. And since this is a straight forward OCS vs OS thing,
sending to me (and say Paul H. as shepherd) offlist is fine and
I'll summarise any offlist mails I get on this when we're done
(incl. email addresses, so no cheating:-)

Cheers,
S.

On 20/08/14 16:03, Stephen Kent wrote:
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
> 
>

---

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

Benjamin,

> www.amazon.com and search for "design patterns" in the "books" category.

Note that I offered some citations for the term, a day or three ago,
that I found through an online search.  Also note that their meaning was
not obviously related to the use here.

Since the term is in such common use, we ought to be able to find some
useful references that do not require buying a book.

More significantly, please note Steve Kent's observation that there is
little obvious need for this specialized term in this draft, especially
since the use of the term 'design pattern' in the draft is not
well-defined nor all that meaningfully used.

> rather than continuing to discuss the ways in which the current text is

Sorry for my confusion, but it appears you are suggesting that the way
to improve a document is to ignore its problems?

In any event, I've suggested how to improve the document, when I could.
 I've asked for clarifications (albeit sometimes by indicating what I
don't understand) and have noted few responses that respond with
clarifications.

Basically, I do not know how to make a document better when folks don't
engage in developing shared, concrete, substantive understanding.

Since you seem to feel that you know how things should proceed
constructively, then please explain how to 'make the document say what
people want it to say'.  It's certainly a a worthy goal.

> "authenticated encryption" is poorly defined or confusing or otherwise

Oh?  I haven't noticed concern with that term.

The concerns I've noted have been with other terms.

d/

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 20 Aug 2014 13:42:43 -0400 (EDT)

> not obviously related to the use here.

I saw those.  I concluded that the online search used to find them was
finding results for an unrelated topic, and that more accurate search did
not find them.  I thought I covered this in
http://www.ietf.org/mail-archive/web/saag/current/msg05388.html ; if you
disagree, perhaps you could reply to that message?

> useful references that do not require buying a book.

My implied assertion was that this term is used by textbooks used for
undergraduate CS classes.

> well-defined nor all that meaningfully used.

To me, the meaning of the term is self-evident: we are attempting to
describe a common pattern shared by designs for certain internet
protocols, and promote the use of that pattern.  I am open to being
persuaded that an explicit definition should be given in this document,
but my understanding is that most readers will understand the meaning
intended.

I guess I did not particularly note Steve Kent's statement at the time (I
assume you refer to
http://www.ietf.org/mail-archive/web/saag/current/msg05369.html).

Perhaps we can break down the term, which (again, to me) divides naturally
into (protocol) + (design pattern).  Since both you and Steve Kent do not
see the meaning of the combined term as naturally as I do, I am forced to
consider the possibility that it is not in fact a phrase that needs no
explicit definition.  What does the phrase "design pattern" just by itself
mean to you?

> to improve a document is to ignore its problems?

No, of course not.  I'm saying that there is no need to point out the same
problems repeatedly using different language, once those problems have
been acknowledged.  (I will grant that it is less clear that anyone other
than me has acknowledged some of the issues in question, to date.  But,
per RFC 7282 as you noted in a separate message, I expect our ADs to take
note regardless.)

> don't understand) and have noted few responses that respond with

If I remember correctly, the "lots of point-by-point commentary" that I
trimmed from my reply boils down to basically the question of encryption
vs. more-than-encryption, and different ways to authenticate a connection.
The author and his fanclub have repeatedly stated that the document is
intended to be about more-than-encryption.  In many places in the
current form of the document, the word "encryption" is used and it
detracts from the meaning intended by the authors, you are correct.  I
have attempted to go through the XML source and change them, as part of
https://github.com/vdukhovni/saag/pull/2 .  On the question of ways to
authenticate a connection, I believe that multiple examples in the
document have been quoted on this list.  This seems to be becoming
well-trodden ground; I would rather have a new version of the text that
makes these examples more clear and prominent than continue to discuss the
known flaws.

> people want it to say'.  It's certainly a a worthy goal.

Patch the XML make a pull request?

All I can do is quote
http://www.ietf.org/mail-archive/web/saag/current/msg05368.html:
% If anyone can suggest better language, please send a patch
% for the XML:
%
%     git clone https://github.com/vdukhovni/saag.git

I have some out-of-band reason to believe that the author has been
reluctant to take sweeping changes, but I hope that the recent proposals
from myself and Steve Kent have indicated that doing so will greatly
improve the quality of the document.

As you yourself have said, we have a long history of spending the time
needed to produce quality documents.  (Speaking of time, it looks like
I've spent some forty minutes drafting and researching this email.  That
level of detail becomes a huge mental drain when one is trying to keep up
that quality of response and yet there keep pouring in tens of messages
per day even while one is still composing responses.  This is what I mean
by my remark about "require more hours than there are in a day".)

> The concerns I've noted have been with other terms.

I did not intend to imply that my example was relating to concerns that
you in particular had raised.  It was rather an example of a concrete
suggestion made in the form of a github pull request, that happened to be
easy to describe in emailed prose.

-Ben

---

From: Nico Williams <[email-masked]>
Date: Wed, 20 Aug 2014 15:46:26 -0500

[I've been too busy to comment on Stephen K.'s proposed changes, but I
will soon.]

First, my sense of Stephen K.'s proposed changes is that they don't
change the substance of the draft.  I.e., we really are and have been
down to matters of style and wordsmithing.

Second, OCS is not a good term.  I've given my reasons for this before
several times, and if need be I'll repeat them again; I repeat some
below.

Third, I'm not a stickler for purity when it comes to terminology
because we already have many conflicts between the protocols in
Internet security space.  I'm uncomfortable enough with Viktor's use
of "authenticated encryption" that I second using "authenticated
sessions".

Back to OS vs OCS vs OE vs any other options:

 - OE is no good: OS denotes more than mere encryption with
unauthenticated key exchange, whereas OE doesn't denote the
possibility of strong authentication.

 - That OE was used before does NOT bother me.  If I didn't have other
reasons to reject OE, I'd take it.

 - OCS is a bad term because I expect that this document, like many
other RFCs, will bleed into popular culture, and so we need a term
that users can understand.  OCS is too long, to start, and it's not
clear to me that "crypto" will mean much to users.  Whereas OS is
short, sweet, to the point, does not misrepresent, and denotes roughly
the right meaning.

Nico
--

---

From: Dave Crocker <[email-masked]>
Date: Wed, 20 Aug 2014 20:31:14 -0700

Ben,

...
> finding results for an unrelated topic, and that more accurate search did

That's fine, but the alternatives you found really do not look any more
satisfying.

Remember that the claim was that the term was in common use.  Again, if
it is so common, online explanations should be readily available.  Yet
there aren't.

My guess is that folk are confusing the common term "design pattern"
with "protocol design pattern".  The former is a nice innovation of
perhaps 30+ years ago, but it's a very general concept.  The latter has
little or no established use, I believe, and the lack of online examples
encourages this view.

Any online use that is close, isn't all that close.

> undergraduate CS classes.

We are not in a CS class. If the term is in common use, it will be in
use beyond classrooms and textbooks.

In any event, the current draft needs to explain the term well enough
for the reader to know what it means, just as it needs to define the
'protocol design pattern' 'os'.  It doesn't do that, either.

> To me, the meaning of the term is self-evident: we are attempting to

To you, perhaps. The next reader might think the same thing, but wind up
applying a different meaning.

Again, this document is supposed to be a specification. (A definition is
a form of specification.)  Specifications do not make assumptions,
especially when the readership is highly diverse in training, culture
and primary language, as it very much is in the IETF and the rest of the
Internet.

Once again, to the extent that the phrase 'protocol design pattern' is
essential, it needs to be defined carefully and practically.  The draft
does not do it.

Also again, the draft is supposedly defining 'os' as a design pattern
but never specifies the detailed characteristics of that pattern.  So
there is no way to tell in the future which protocols fall within the
design patterns and which do not.

In an offlist message Stephen noted another I-D that uses the term:

    Observing Resources in CoAP
    Section 1.2 Protocol Overview
    https://tools.ietf.org/html/draft-ietf-core-observe-14#ref-GOF

He thought that it might make the use in the 'os' draft more comfortable.

My response was:

     It's clear and concrete,
...
     Anyhow, note that coap-observe is invoking an /existing/ pattern --
presumably defined in that book -- which it cites very specifically and
then gives a very clear summary of what the pattern is, that is being
used. This is very crisp text.

     In contrast, the opp-sec draft uses the term 'design pattern' but
does not invoke or define what that means, substantively, nor explain
pattern is being used. Nor is the use of the term used all that
meaingfully or consistently in the document.

And 'os' is being defined as a /new/ pattern, but has no description
anywhere near as clear and concise as what is in the CoAP draft.

> but my understanding is that most readers will understand the meaning

I've no idea where that understanding is coming from, but we have
decades or perhaps centuries of experience that teach the folly of doing
specifications in that fashion.

> http://www.ietf.org/mail-archive/web/saag/current/msg05369.html).

yup.

And its essential point about this is that the term 'protocol design
pattern' is not essential to this draft.  It become just another term
tossed in, without being used productively.

> explicit definition.  What does the phrase "design pattern" just by itself

Not sure why the vagaries of my personal meaning for the term are
relevant.

Again, we ought to have a common, public anchor for terms.  And indeed,
the term does provide ready and reasonable examples online, such as:

http://en.wikipedia.org/wiki/Design_pattern#Alexander.2C_A_Pattern_Language

> been acknowledged. 

First, they mostly have been either ignored or summarily rejected.
(It's been amusing to see my assertions of this also get summarily
rejected, rather than discussed.)

What is needed when someone raises a concern is to engage in ensuring a
shared understanding of the issue.  That is, engaging in a process that
is often called "discussion".  With few exceptions, there has been very
little of that.  Rather, folk have tended to consider responses like "I
don't agree" or "That's not true" as substantive and sufficient.

>  But,

By the time ADs deliberate, the community process is over and should
have established a very clear track record of engaging in resolving
differences in views.

> vs. more-than-encryption, and different ways to authenticate a connection.

(Side comment:  Kent's preference "communication" rather than
"connection" or "session" is well-taken, IMO, for the reason he gives.)

Yup.  Encryption, with or without some form of authentication.

> makes these examples more clear and prominent than continue to discuss the

Encryption w/ or w/out authentication is the real topic of immediate
concern, is the concrete topic of discussion in the draft, and is (IMO)
entirely sufficient to justify the document.

So the real problem (IMO) is a scope creep infection that is affecting
folks' vision.

The document does not need to do a better job of explaining the
applicability of the 'pattern' for security functions other than
encryption.

It needs to stick with the actual substance already in the draft, and
drop the claim that it is covering more.

A challenge for any interesting project is focus.

> improve the quality of the docement.

Steve's draft is definitely an improvement.

> you in particular had raised.

Sorry I wasn't clear.  I wasn't commenting on my concerns (about this)
but that I hadn't noticed concern amongst /others/ with that specific
term.  Perhaps some debate about nuances (eg, does TOFU qualify as an
acceptable example of authenticated encryption) but nothing major.

d/

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Aug 2014 20:26:11 +0200

Hi Nico,

> down to matters of style and wordsmithing.

The reason there was a need for such a document in the first place was
that people were struggling with terminology in our working groups,
starting with the HTTPBIS working group, and the term had been thrown
around in other drafts.  The crypto folk (you included) were rather put
off with the term, OE.  Fine.  But in as much as we are focusing down on
crypto-related stuff (and we are), let's limit the scope of the term to
crypto-related stuff.
> several times, and if need be I'll repeat them again; I repeat some

I'd be grateful if you would send me a pointer off list to the other
reasons.
> possibility of strong authentication.

Ok.
> reasons to reject OE, I'd take it.

Ok.
> that users can understand.

This, I had thought, was Dave's point: who is your audience?  In this
case I didn't think it was users, but developers, and they darn well
ought to understand what the expansion is.  And really what is needed by
IETF spec writers is a term that can be commonly understood to mean a
set of specific practices (or, if you must, a design pattern) they can
employ in their drafts.  Seems like the draft really does a good job at
that.  Do you believe users will really understand what a design pattern
is?  But supposing you are correct that the term does bleed into popular
culture (and I suspect you're right): do you want OS to be so narrowly
considered, as it is in this document?  And again, I like the scope of
this document as it is.  More text won't help.

Worse, I am a little nervous that by catering to users this document
will neither be fish nor fowl (meaning it will not be optimal for either
users or developers).

Eliot

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 Aug 2014 13:58:31 -0500

> case I didn't think it was users, but developers, and they darn well

Only Internet protocol designers will very likely read the RFC.

Implementors will very likely read the RFCs documenting the protocols
they implement, which will hopefully describe what to do in those
particular protocols' implementations to get OS semantics.  They might
also read this RFC.

Users will be aware of the term though, and -hazily- its semantics,
that's my prediction.  More than that: I think we'll have a better
chance of success if we aim for this, or at least if we don't try to
impede it.

(Of course, users will most definitely not read the RFC; they never do.)

My argument is that OS is a very subtle but significant change in our
collective attitude to Internet protocol security, one extremely likely
to greatly improve security on the Internet.  If that's right then it's
also extremely likely to become well known to the public, like SSL/TLS.

We need a name and/or acronym that's accessible to the public at large.

At the very, very least we need it to be accessible to developers and
marketers, not just the IETF in-crowd.

We should definitely want users to be somewhat aware of OS: so that they
may demand products that support OS.  It might be key to OS' success.

IMO we cannot ignore potential user awareness of OS.

> ought to understand what the expansion is.  And really what is needed
> by IETF spec writers is a term that can be commonly understood to mean
> a set of specific practices (or, if you must, a design pattern) they
> can employ in their drafts.  [...]

OS is a very significant change of attitude for us, so much so as to
deserve a name and doc of its own.

>                      [...].  Seems like the draft really does a good
> job at that.  [...]

Eh?  How?  It captures one concept, not a set of good security
practices.  Or did I miss that?

>       [...].  Do you believe users will really understand what a
> design pattern is?  But supposing you are correct that the term does

Indeed, no way.  But they'll understand a marketing term.  They know to
look for "SSL" and "TLS".  We should want them to know to look for "OS".

> bleed into popular culture (and I suspect you're right): do you want
> OS to be so narrowly considered, as it is in this document?  And

Yes, I do.  I'm open to that being ill-considered on my part, but
remember: the public has become quite aware of security failures.
Shouldn't we want the public to become aware of security successes??

> again, I like the scope of this document as it is.  More text won't
> help.

You're just down to debating the name then?

> will neither be fish nor fowl (meaning it will not be optimal for either

This is true, but the document isn't catering to users.  The _name_ is
catering to users: that's as much as we can hope they'll know, with a
minimum of its semantics -- semantics which the name, short as it must
be, had better denote to some degree...

Nico
--

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Aug 2014 21:20:39 +0200

> You're just down to debating the name then?

Somewhat yes, because that was how all of this started.

Eliot

---

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

> Somewhat yes, because that was how all of this started.

That's progress.  It took a long time to get to agreement on the
substance of Viktor's proposal.

There's a lot to naming.  We must choose carefully, no doubt.

I'm quite convinced that we won't find a better term.  We've tried so
many variants...  That alone is strong evidence that we're likely not
going to please everyone.

I know I've been a bit forceful as to the name, but really, if you find
a better term, I'll be all for it.  But so far every name pitched has
failed to be better than OS.

Back when we first discussed this I made a list of many possible names
and pitched them to friends and family.  None was great, but OS seemed
like the best name, and when explained they seemed to get it.

If we really want a better name then we should repeat that exercise, but
more scientifically (standard questionnaire and polling procedures,
larger sample size + some record keeping).  It'd mean a significant
delay, but given how long we've been debating it, and how much longer we
could continue to, it might be no big deal.  Have we ever done something
like that??

I would rather we didn't run a scientific poll _now_.  I proposed it a
while back and no one said peep.  Who would run the poll?  We're
volunteers, with limited resources...

Nico
--

---

From: ianG <[email-masked]>
Date: Fri, 22 Aug 2014 13:07:13 +0100

On 20/08/2014 16:03 pm, Stephen Kent wrote:
> doing,

It's not more precise, it's either a distinction of no difference or a
mistake.

What we are doing is Opportunistic Security.  That is, we are securing
the users' interests using an opportunistic approach.

We are then applying this approach to protocols.  Now, obviously, when
we are doing protocols, most security ends up being crypto in nature.

So in this sense of high-level viewpoint, the distinction is no
distinction, OS is crypto-security.

But, at a more detailed level, this simplification is reversed:
sometimes we come across a technique that isn't crypto-related.  For
example, TOFU.  This is based on the limited time/space window, the
knowledge of the human operators, and the economics of attacking every
possibility all the time.

TOFU is not crypto, yet it is OS.

So, by saying crypto-security we are in danger of eliminating one of our
best and most successful techniques [0].  And, as we are talking
opportunistically, we indeed want to not be so prejudicial.  We'll take
a benefit where we find it.

> and because it has the advantage of being represented by an

Yeah, overloading is a nice to avoid, but not essential.  How about
opp-sec?  Of if someone points out a clash with operational security,
then oppo-sec.

Frankly, I don't think that is important.  In any field of such breadth,
we have to deal with overloading of terms.

iang

[0]  If one believes the words matter.

---

From: ianG <[email-masked]>
Date: Fri, 22 Aug 2014 13:43:42 +0100

> it is so common, online explanations should be readily available.  Yet

Pattern or design pattern is a term that has been in use for at least 15
years to my knowledge.  It is a subtle term, and I can understand that
there might not be good definitions.  I suspect the definition is a
little pointless because without a good understanding of the concept of
design patterns, any definition isn't meaningful.  Which is to say that
the way to understanding is to learn several design patterns and then
triangulate backwards to the meaning of the term.

For those who find this unsatisfactory, oh well.  The language works
that way, learning works that way, human nature is, and our use of the
common term is far more important than finding a definition.

> little or no established use, I believe, and the lack of online examples

Perhaps it makes more sense expressed as "design pattern for protocols"
?  Otherwise I can't see the confusion here.

> for the reader to know what it means,

Disagree.

It may be someone's job to explain all the words that we might use.  But
the English language is descriptive;  we use the words and then later on
the wordsmiths come in and hammer out their meaning in committee.  They
get to do that at their leisure, and we get to the words at our
pleasure, including the joy of making new words on the fly.  It is not
the job of this draft to define every word in common use, nor the
conjunction of two common terms 'protocol' and 'design pattern' just as
it isn't the job of this draft to define MUST or 'is'.

> just as it needs to define the

Granted, we may want to define the term 'os'.  That's harder.  Mostly it
is harder because like all patterns we want to define it by explaining
some common examples, *but* also we don't want to get dragged into too
many examples, nor to get dragged into the minute detail and religious
warfare that is typically attendant.  We need a helicopter view, and we
may end up describing it rather than defining it.  I believe that's
acceptable to readers, YMMV.

> and primary language, as it very much is in the IETF and the rest of the

Well, that's wrong then!  One cannot "specify" opportunistic security.
It's an approach that can be employed, by its very nature it defies
specification because it defies measurement;  it'll take the
non-opportunistic successful method as much as deliver nothing.

So maybe the IETF process for 'specifications documents' is simply the
wrong path.  Oh well.  Do we care?  Better to have the document out
there so we can start to slay some of the policy dragons and model
gremlins than to pass yet another burdensome and inappropriate
bureaucratic hurdle...

> essential, it needs to be defined carefully and practically.  The draft

The term is not essential.  It's just a really good descriptive term for
that community that has it.  If you grok the two, it comes together
naturally.  If not, well, apologies, but let's move on...

> design patterns and which do not.

It's a way of thinking that we need to put out there.  The last thing we
want to do is ontologise the successes and give people gold stars for
their prescriptive delivery.

...
> meaingfully or consistently in the document.

as above...

> anywhere near as clear and concise as what is in the CoAP draft.

OS is perhaps a new approach to IETF.  Outside IETF, no, the approach
has been in use for decades.  If one needs a basis for that, one could
look at risk analysis and risk taking behaviour of people, well studied
in psych and finance.  SSH and Skype celebrated the approach.

The term itself isn't so common mostly because people just do it, it
might be that the term is in a 'coming of age' transition and we haven't
noticed until now, like NoSQL.

....
> tossed in, without being used productively.

Perhaps.  People who understand the two terms will instantly see where
we are heading.  People who don't, won't.

>> into (protocol) + (design pattern).

That.

...
> So the real problem (IMO) is a scope creep infection that is affecting

Well.  Encryption is the need of choice for PM, but the approach that
will put it into play is OS.  Calling it OS isn't scope creep because
encryption without an opportunistic security context isn't going to
mitigate the threat (or, didn't for the recent history).

> applicability of the 'pattern' for security functions other than

I would have thought it quite reasonable to explain the applicability of
the pattern by describing example(s) in encryption.

...
> ....  Perhaps some debate about nuances (eg, does TOFU qualify as an

As the draft is about OS not AE, asking whether TOFU qualifies as AE
should be out of scope.

iang

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Aug 2014 12:57:33 -0500

> It's not more precise, it's either a distinction of no difference or a

I can make a [totally contrived] case for opportunistic
non-cryptographic security that nonetheless uses the same principles
as OS.  I won't bother to here, but the point is that you're quite
right, though I don't think that's enough of an argument to settle the
matter.

Besides, personally I find OCS a reasonable term for _us_.

If the name were the only sticking point (I think it is) left and we
absolutely had to ditch OS to get published, I'd settle for OCS, no
doubt, and I'd hope that OCS turns out to make a decent marketing
term.  I've explained my rationale for why OS is better.  I admit that
what's better depends on the audience.  Perhaps it's a terrible idea
to try to come up with a name that the public can be aware of.  I'm
not sure of this (and a lot of other things); it's a gamble.

But I continue to think that on the whole we're better off giving this
new attitude an accessible name, especially since we've not found a
hands-down awesome name for it.  We've given the naming thing many
go-arounds...

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 22 Aug 2014 15:56:04 -0400 (EDT)

I see that ianG has already replied to some points, saving me the trouble.
This message is twice as long as the previous one I replied to (which took
me forty minutes to compose); I could not afford that kind of time
yesterday.

> little or no established use, I believe, and the lack of online examples

Yes, I think people are saying that "design pattern" is in common use, and
"protocol design pattern" clearly is equivalent to "design pattern for
protocols".  ianG said a bit more on this, so I won't.

> essential, it needs to be defined carefully and practically.  The draft

I am somewhat indifferent to whether the text of the document includes the
string "protocol design pattern" or "design pattern for protocols".  I see
"protocol design pattern" as being of greatest utility for talking about
this document (or other ones) in other places; it is not particularly used
internally within the document.  Since the document itself does not rely
on the term for matters of much substance, I am not very convinced that a
rigorous definition need be included in the document itself.

> tossed in, without being used productively.

[See my previous paragraph.]

> rejected, rather than discussed.)

I do not dispute this claim.  Indeed, having once been rejected/ignored,
one might expect that similar actions would get similar reactions, causing
only more email to the list for no real change.

> don't agree" or "That's not true" as substantive and sufficient.

This is unfortunate.  Alas, I can only be responsible for my own behavior.

> have established a very clear track record of engaging in resolving

I did not refer to intra-AD deliberations, rather to when the ADs call the
consensus of the group.  Outstanding unresolved issues should preclude a
decision that there is consensus.

> drop the claim that it is covering more.

I claimed that Steve K's new text is an adequate representation of what
has been fleshed out on the list.  It does appear to only cover encryption
and authentication, so perhaps you are right.  I don't think this need
preclude couching the proposal in a more general light if that can be done
while maintaining an adequate treatment.

> acceptable example of authenticated encryption) but nothing major.

Okay.  My claim was based solely on memory, and it is hard to keep track
of all of the discussions in memory.  Perhaps my memory was faulty in this
case; it doesn't seem like a big deal, regardless.

-Ben

---

From: Stephen Kent <[email-masked]>
Date: Fri, 22 Aug 2014 16:04:53 -0400

Ian,

> It's not more precise, it's either a distinction of no difference or a
so says the man with how many RFCs and other publications to his credit?
> we are doing protocols, most security ends up being crypto in nature.
a lot of security is not at all crypto-based: non-Ipsec firewalls,
IDS's, ...
> distinction, OS is crypto-security.
I agree that what we are discussing is crypto security.
I am not wedded to the OCS name alternative; I proposed OS
and someone else suggested OCS.
> possibility all the time.
TOFU is a key management mechanism, i.e., it is used to distribute a
public key, which is then cached along with the proffered ID. I'd
say that any key management mechanism is crypto-related.
> TOFU is not crypto, yet it is OS.
TOFU is one key management mechanism that MAY be part of an OS solution.
DANE is another; unauthenticated Diffie-Hellman is another, ...
> a benefit where we find it.
we disagree on whether TOFU is crypto-related.
> (OCS vs. OS) in our arena.
yes.
> opp-sec?  Of if someone points out a clash with operational security,
opp-sec is not an acronym, so I don't see the parallel.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 22 Aug 2014 16:31:39 -0400

Ben,
> protocols".  ianG said a bit more on this, so I won't.
A more relevant issue, in my view, is whether we have tended to use
these terms in RFCs and whether we have appropriate terms that we do use
in RFCs instead. I think the answer to the first question is NO, and to
the second is YES, as illustrated by my revised text.

Steve

---

From: <[email-masked]>
Date: Fri, 22 Aug 2014 23:28:02 +0000

> so says the man with how many RFCs and other publications to his credit?

that is very ad hominem. I fail to see the relevance of the question.

are you capable of formulating a better argument?

Lloyd Wood

you say crypto, I think cryptosporidium
________________________________________
From: ietf <[email-masked]> on behalf of Stephen Kent <[email-masked]>
Sent: Saturday, 23 August 2014 6:04:53 AM
To: [email-masked]; [email-masked]
Subject: Re: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment)

Ian,

yes.

Steve

---

From: ianG <[email-masked]>
Date: Sat, 23 Aug 2014 12:45:25 +0100

Hi Stephen,

> so says the man with how many RFCs and other publications to his credit?

I thought everyone knew me, but let me explain:  I do counter-cultural
writing.  You'll not find my name on an RFC, maybe by definition?
Strictly for amusement, here's one:

http://iang.org/ssl/reliable_connections_are_not.html

Please take this in the spirit of amusing saturday reading, not as an
actual call to arms to disband TCP and start again :)

>> *we are doing protocols* , most security ends up being crypto in nature.

Indeed, that was the subtlety I was getting at.  In protocols, it ends
up being almost mostly crypto, but not 100%.  Rhyming for Internet
security, it seems as though it is a crypto task, but there are some
areas where it decidedly is not.

> say that any key management mechanism is crypto-related.

Of course, the protocol needs a key.  How to deliver it is the question.

Model- or policy-based security says that the key has to be
reliable/authentic or your model or policy is broken.  In contrast, TOFU
says the reliability can be non-deterministic (?) if you take that risk.

That choice is what this is about, not whether it's a cryptographic key,
a password or one of those new-fangled grainy photos of numbers they use
in CAPTCHAs these days.

> DANE is another; unauthenticated Diffie-Hellman is another, ...

Right, full agreement.  But if we use TOFU with a password, is that
still crypto?

> we disagree on whether TOFU is crypto-related.

TOFU is also human-related.  When you drive to a new town, and go into a
store, did you need anyone to tell you "that is a store" ?  No, you will
use your own internalised methods to take a risk on an open door with a
bunch of ads and parked cars out the front.

Same with SSH.  When a sysadm connects to a box the first time, she
knows that nobody is trying to MITM her to a very high reliability,
because because.

So if we agree that TOFU comes into the OS bailiwick, and we agree that
risk taking based on human learning is a part too, then we'd also have
to expand the new term to be 'opportunistic
crypto-human-risk-probabilistic-security.'

> opp-sec is not an acronym, so I don't see the parallel.

Anyway, to summarise my position.  IMHO, trying to refine the term OS
further isn't helpful, because although at the protocol level security
is mostly about crypto, it isn't 100%.

OS is as much about opening minds to things outside the cultural norms
as it is about the design pattern of
encrypt-if-possible-then-auth-if-possible.

On the other hand, it is granted by pretty much everyone here, that
regardless of good work done, the draft speaks more to encryption than
to the title.  I'm not sure what to do about that.  Add an example on DANE?

iang