Subject: Review of: Opportunistic Security -03 preview for comment

From: Dave Crocker <[email-masked]>
Date: Fri, 15 Aug 2014 08:54:18 -0700

Viktor sent me a preview copy of the latest draft.

I see he made some adjustments, to text I had comments on. (Thanks!)

Below are the comments I provided him that were not responded to or
resolved in the version he just released.  And a few comments on new text...

I'll repeat my point about the problems with saying 'security' rather
than 'encryption'.  This draft is now clearly and solely about
encryption.  And that is exactly the right focus for the draft.

In this draft, authentication is only in the service of better
encryption.  And no security mechanisms other than encryption (and
authentication) are discussed.  Nor should they be.

When a term is intended as the primary reference to a topic, the term
needs to be clearly about that topic, and not something more general.
For this draft, the topic is flexible encryption frameworks, and nothing
else.  The term that is used needs to be clear about that.
"Opportunistic security" is a very, very long way from such clarity.

So I'll repeat my suggestion:  Either use "opportunistic encryption" and
expand upon the existing definition, to increase it's scope.    Or
choose a term like "Best Effort Encryption", which is entirely
intuitive, clear and accurate.

Review:

> Abstract
...
> established practice of employing cryptographic protection against
>    both passive and active attacks, or no protection at all.  As a

"Employing" misses the point. The sentence needs to be clearer that the
protected is required, or else there is not protection:

      established practice of requiring cryptographic protection against
both passive and active attacks, or no protection at all.

> Opportunistic Security: Some Protection Most of the Time

"More" is a promise of success that you and we can't make.

A little restraint in the language will help. In the same style of
catchy phrasing, but with a reduced tone of hype, I suggest:

     Some Protection More of the Time

> 1. Introduction

>    Historically, Internet security protocols have emphasized
>    comprehensive "all or nothing" cryptographic protection against both
>    passive and active attacks.  With each peer, such a protocol achieves
>    either full protection or else total failure to communicate (hard

This is new text.  It's much better than it's predecessor.  A small,
word-smithing quibble, worth pursuing because it relates to a core issue:

"Emphasized" is not really correct.  It implies preference, but with
flexibility.

The mechanisms have imposed, demanded, only permitted, or the like.

They have typically not had a hierarchy of choice with a 'preference'
for stronger protection.  That is, after all, the point of innovation
with opportunistic approaches.  So, replace emphasized with a word
making clear that all-or-nothing has been binary.

>    Designing and deploying a key management for the whole Internet is
>    for now an unsolved problem.  For example, the Public Key
>    Infrastructure (PKI) used by the web (often called the "Web PKI") is
>    based on broadly trusted public certification authorities (CAs).  The

I believe it is not "for" the web.  To my knowledge, there is nothing in
it that is specific to the web.

It is "used by" the web, but I believe it is also used by other services.

Also, in spite of there being an existing working group that does use
the term "Web PKI", I suggest removing references to the term.  The
important point being made --  that there are too many trust authorities
-- is generic.  It really is an essential concern and it doesn't matter
whether it is for the web or email or whois or...

>                        The
>    Web PKI has too many trusted authorities and imposes burdens that not
>    all peers are willing to bear.

To my knowledge, it is only used to validate the server, never ( or at
least, almost never) the client.  This is one of the continuing points
of misunderstanding due to casual use of language, like 'security', that
is overly broad.

>               Web PKI authentication is vulnerable
>    to MiTM attacks when the peer reference identifier ([RFC6125]) is
>    obtained indirectly over an insecure channel, perhaps via an MX or
>    SRV lookup.

Huh?  That needs a citation, to explain and 'prove' it more carefully.

>        However, at this time, DNSSEC is not sufficiently widely
>    adopted to allow DANE to play the role of an Internet-wide any-to-any
>    authentication system.

RFCs typically should not make temporal references.  RFCs often have
utility for decades and the conditions at the moment of writing are no
longer relevant.

This requires a bit of word-play, to make the important point, but
without reference to possibly transient issues.

Perhaps:

   For some scenarios DNSSec and DANE cannot be, or are not, used to
permit authenticated encryption.

> Opportunistic security protocols on the other hand, can begin to use
>    DANE immediately, without waiting for universal adoption.

The term OS has not yet been defined.

Probably the better choice is to eliminate the sentence.  It seeks to
sell the solution, but this section of text is really only giving
substance to the problem statement.  Save the solution discussion for later.

>    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.
> promotes stepping up from cleartext, not down from authenticated
> encryption. 
Actually, it involves stepping /down/.  In addition, the sentence is a
bit challenging to read.

Perhaps:

     An opportunistic design pattern involves using the strongest level
of protection that is compatible among participating peers.  Rather than
devolving to no session or no protection, it permits use of less
stringent protection, when that is all that can be supported amongst the
peers.

> The risk of active attacks should also not be ignored. The
> opportunistic security design pattern features a range of
> cryptographic protection levels, with encrypted transmission

Add a sentence to provide a better bridge to the conclusion that is
being promoted:

     ...not be ignored.  Hence there is benefit in always seeking the
strongest cryptographic protection possible, while allowing a range of
lesser levels of protection.  The opportunistic...

> 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.

Note that that is a 'purpose' statement, and not a technical definition.

And, again, it is about 'encryption' specifically and not 'security' in
general.

>    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?

>   We will use the phrase "opportunistically employed" to mean that the
>    use of a type of protection or a security mechanism was tailored to
>    the advertised capabilities of the peer.  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.

>    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?)

The pattern is about capabilities.

I suggest simply dropping the first sentence and the "Rather".  The
second sentence is reasonable on its own.

>    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 encryption may
>    be used "opportunistically" with peers capable of more than
>    cleartext.

The first sentence is cumbersome, at best. I'm not sure I understand all
of it.  But worse, the beginning of it is probably wrong!

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

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

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.

On reflection, I think that the point intended by this paragraph is
along the lines of:

     Opportunistic patterns require using the strongest protection that
is possible amongst peers.  In particular, authenticated encryption is
to be used whenever possible, rather than unauthenticated encryption.
For example with DANE, the advertisement...

>    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.

> 4. Opportunistic Security Design Principles

>   Emphasize enabling communication:  The primary goal of opportunistic
>       security is to enable secure communication and maximize
>       deployment.  

I think that counts as two goals.

> 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.

>    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.

> 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.

Encryption without authentication is still a useful degree of
'security'. (Actually this point again highlights why using the word
"security" or "secure" is actively unhelpful.)

I assume that the point here is about misleading folk into thinking they
have a degree of protection that they don't really have.  However I
believe there is no widely-used terminology that communicates that.
"secure channel" is most certainly NOT a a widely-used term that
communicates that.

However the bullet point /is/ important.

So perhaps:

   Unauthenticated encrypted communication must not be misrepresented as
providing more protection than it does.  In particular, its use need to
carry the explicit warning that it is vulnerable to MITM attacks.

> 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...

> 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'.

>    encryption), but will employ TLS (and therefore encryption) when the
>    SMTP server announces STARTTLS support.  Since the initial ESMTP
>    negotiation is not cryptographically protected, the STARTTLS
>    advertisement is vulnerable to MiTM downgrade attacks.  Further, MTAs
>    do not generally require peer authentication.  Thus opportunistic TLS
>    for SMTP only protects against passive attacks.
> 
>    Therefore, MTAs that implement opportunistic TLS either employ
>    unauthenticated encryption or deliver over a cleartext channel.

   deliver -> transmit

("deliver" is a term of art in email and for the current discussion,
MTAs don't do it.)

>    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.

>    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...

>    is common practice to fall back to cleartext transmission not only
>    when STARTTLS is not offered, but also when the TLS handshake fails,
>    or even when TLS fails during message transmission.  This is a
>    reasonable trade-off, since STARTTLS protects only against passive
>    attacks, and absent an active attack TLS failures are simply
>    interoperability problems.

> 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.

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.

> 
>    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.

>    opportunistic policy can be counter-productive when it demands more
>    than many peers can in fact deliver.  Non-opportunistic policy should
>    be used with care, lest users find it too restrictive and act to
>    disable security entirely.

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

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

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

> >    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.

> 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.

> is /us/ credible...)  How will use of an opportunistic pattern lea to

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

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.

> 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,

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

> 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.

> 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.

> Ultimately I can't tell what the motivation for this sentence is.

You're still not reading the definitions as stated.

> 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.

> 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.

> fact it is arguably wrong.

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

> Ran out of time.  Haven't reviewed the remainder...

So is this.

> Software does not have a 'will'.  I think what is meant here is 'able'.

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

> >    unauthenticated encryption or deliver over a cleartext channel.

Sure.

> to be distracting when this document is read 20 years from now.  I

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.

> 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.

> security is part of security.

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

> be ok.  It's that it needs to be outside of the scope of an

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".

> 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: Paul Wouters <[email-masked]>
Date: Fri, 15 Aug 2014 15:01:59 -0400 (EDT)

> intuitive, clear and accurate.

Agreed. I still do not think the term Opportunistic Security is right,
for exactly these reasons. I'm not sure if I like going back to
Opoprtunistic Encryption, but I'm less against it than I was before.
Best Effort Encryption seems intuitive to me, but apparently that's not
the case for everyone.

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

Paul

---

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

> Countermeassure 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: Dave Crocker <[email-masked]>
Date: Fri, 15 Aug 2014 12:38:59 -0700

> can debate, it is a definition.

Viktor,

I don't understand your response.  In any event, my point was that the
existing text is actually incorrect.

Opportunistic patterns, here, concern permission to use /decremental/
protection.  The premise is that weaker protection is better than none,
when stronger protection is not usable.

So it is not stepping "up".  It is stepping "down".

And, by the way, I still do not see any text in the draft that
constitutes a 'definition', nevermind being labeled explicitly as such.

> effect to help reach near-universal adoption.

Deployment is already incremental, with respect to the way that term is
usually used for Internet services.

Some sites deploy strong protection.  Some don't.  The capability works
amongst those that deploy it.  It does not require others to deploy it
before that utility is available.

Incremental deployment is usually means that there is utility with
smaller-scale deployment.  In particular, it tends to mean there are few
or no critical dependencies upon infrastructure.

I believe what is meant here is something like:

    The deployment of less stringent protection is easier.  Hence it is
hoped that permitting less stringent protection will encourage wide
adoption of at least some protection, with the incremental improvement
to stronger protection over time.

> predictably fail a significant fraction of the time.

1. "Work out of the box" sound great; it's appealing language.  But it
has no obvious technical or operations meaning in this context.  The
reader has no basis for even guessing what the technical or operational
details are that constituting 'working out of the box'.  Even after
extensive discussions here I don't know what it means, in technical or
operational terms.

2. At the least, there is no 'box'.

3. More seriously, even unauthenticated encryption requires considerable
effort in development, deployment and use.

4. The term "opportunistic authentication" is not defined or discussed
in this draft, and frankly it has no obvious meaning to me, in spite of
the lengthy discussion of opportunistic foo on the various ietf lists.
I strongly urge dropping the term from this draft.

> I still think the original text is sufficient.

Sorry, no.  An estimate is what one can attempt has when one has
/partial/ information and seeks to extrapolate/interpolate from it.  An
estimate based on zero information is merely fantasy.

But again, design patterns do not make estimations.

> value, the point needs to be made.

I don't understand what you mean and the issue not not what I am "not
taking at face value".  I'm reading the text and attempting to
understand it.

In any event, really, the paragraph works far better without the first
sentence.

> than what the draft actually says.

Viktor, that is your second statement commenting on my behavior.

Please stop commenting on what I am doing.  And especially do not
comment on my reading skills or performance.

Otherwise I will have to return the favor, and even more people will
choose to unsubscribe from the IETF list.

>  The draft actually defines a

It does?

Where?

I've looked over every occurrence of "authentication" in the draft and
have not seen any text that seems to "define a way to 'opportunistically
employ' authentication".

> "Required of all peers" is not opportunistic.  Required when advertised

Your use of quotation mark implies that it refers to something that was
said (my me?)  If your comment is not merely a straw man, please point
to the language you are responding to, because I can't find it.

Further, it does not seem relevant to my comments.  Hence I do not
understand what the basis of your comment is.

>> The 'opportunistic' construct is all about permitting lesser protection.

Correct.

It is not about requiring only one kind.  As soon as only one kind is
required, the activity is outside the scope of "opportunistic".

It is not about 'permitting' none.  As soon as there is no security,
clearly it is not "opportunistic".

My best guess is that the desire to have the term opportunistic include
no security and/or strict requirement for specific security, is because
there are scenarios that include opportunistic behaviors AND one or both
of these others, in some situations.

The discipline of a good specification is clarity about its scope of
application.  Including scenarios that are too strict or too permissive
negates any utility in the term.

> defined it that way, but this draft does not.

The text that is definitional does not clearly include or exclude.
Again, and more specifically, I still do not see text in the draft that
constitutes a definition.

I am pointing out a very basic and very important problem with having
the term include activities that contradict the term.

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

A term that is too broad is taken by different listeners as having
different meanings.

The core requirement for "communication" among humans -- and, by the
way, computers -- is "shared meaning".  It is a foundational point in
work on human communication.  As soon as people impart different
meanings for the same term, communication ceases.

Hence, "meaningless".

> You're still not reading the definitions as stated.

Sure I am.  And thank you for being so helpful as to incorrectly claim
otherwise.

Or rather, what definition is that?  I don't see a definition in the
above.  I see a discussion.  And as I said I don't understand it. After
multiple readings.

I make a point of offering what I think might be meant, when I can make
a guess.  I can't do that here.

> of opportunistically enabled authentication that is more of the

The text I am commenting on can be rephrased to have the same meaning,
but say:

     "It is acceptable to permit no authentication for some peers."

That constitutes a fallback from doing authentication.

> S/MIME or PGP.  This could be qualified with "when possible" or

Hop-by-hop is irrelevant to my comment. I was careful in what I stated.

My understanding is that is is not achievable within any current
technology, not merely "not likely".  The difference is important.

Referencing a goal that is beyond the state of the art isn't helpful here.

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

Sorry.  Right.  Current text looks ok.

>> Ran out of time.  Haven't reviewed the remainder...

Sorry, that sentence was left from my pre-release review.  The remainder
were/are comments I formulated today.

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

1. You are describing how things are done or not done.  You are not
describing "bounds".  I do not understand how the term "bounds" is in
any way relevant here.

2. Again, software does not have 'will'.

> a specification.  It is I think useful to highlight a success of

It is not reasonable for someone to be reading a technical specification
-- which is what this document seeks to be -- and have to worry about
when it was written and what was going on at the time.  Otherwise they
might read "recent" and think that the issue is current when, in fact,
it is in the distant past.

This document is not a discussion of current deployment statistics or
the like.  It is a document seeking to define a term and a design
pattern.  Keep the document's scope restricted to that.

> clunky old MTAs fade away, the engineering trade-off will be

The 'status quo' substantiates the legitimacy of the concern but is
otherwise irrelevant.  Establishing the credibility of this concern,
here, isn't that important.

As for interoperability issues fading away, ummm, right.  We have such a
good track record of that happening, I'm sure we can look forward to it
here.

> a baseline where required.

That statement is a non-sequitor.  Security is not made 'usable' by
tolerating no security.  It is made non-security.

It's important that the language here not make silly statements.
Stating that cleartext is security is silly.

> Disagree.  Otherwise we get into "fallback" and all that, but OS

No, what we get into is scope.  "No security" is outside the scope of
opportunistic.  Mandatory, specific security is outside the scope of
opportunistic, since the essence of opportunistic is flexibility.

If you have no security or you require only specific security, there is
nothing 'opportunistic' about what is being done.

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

Clearly it is not.

On 8/15/2014 12:11 PM, Viktor Dukhovni wrote:> On Fri, Aug 15, 2014 at
> Let's talk about the substance of the draft.

That you think choosing confusing terminology is not substantive is a
problem.

That you ignore the confusion caused by prior uses of that term is a
substantive problem.

Making a poor choice in the past is not a very good justification for
repeating the error.

And, by the way, TLS, et al, really were developed with the intent of a
range of different security uses.  So the 'error' then was much less of
an error.

By contrast, the discussion in your draft is only and specifically about
encryption.

d/

---

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

> comment on my reading skills or performance.

I don't believe Viktor is making such a statement on your behaviour.

The draft's definition of opportunism is "encrypt where possible, even
without authentication, but mandate authenticated encryption when
advertised". While you seem to be saying opportunism is "In absence of
mandated authenticated encryption, try to use unauthenticated
encryption".

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.

Paul

---

From: Dave Crocker <[email-masked]>
Date: Fri, 15 Aug 2014 13:26:39 -0700

> I don't believe Viktor is making such a statement on your behaviour.

We disagree.  Worse, the 'response pattern' has been repeated across a
number of notes.  It's ad hominem, mixed with out-of-hand dismissal.

> advertised". 

It does not say the first part, though that language looks quite good to me.

The second part isn't opportunisticx.  If authenticated is mandated,
there is nothing to be opportunistic about.  If mandated is included in
opportunistic, then there is no actual meaning to the term other than
something trivial like "we like encryption".

> While you seem to be saying opportunism is "In absence of

My definition:

     Opportunism is the flexibility to use less-stringent protection,
hen stronger protection is not possible.

> Clearly we have work to do to ensure there is only one interpreation of

Yup.

d/

---

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: Pete Resnick <[email-masked]>
Date: Fri, 15 Aug 2014 15:48:20 -0500

Hatless...

> something trivial like "we like encryption".

Disagree. Paul's definition still missed a bit, and I think it was the 
word "mandate" that confused things.

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. The difference from the 
past is that you don't simply give up on encryption if you can't do 
authenticated strong encryption; you opportunistically use whatever 
encryption you are able to.

> hen stronger protection is not possible.

Using less-stringent protection when stronger protection is not 
available is not an "opportunity". It's a compromise. The opportunity is 
to go *up* from what you currently do, not to go down from what you 
might have done had circumstances been different.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

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:

> when stronger protection is not possible.

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

> > Clearly we have work to do to ensure there is only one interpreation of

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: Dave Crocker <[email-masked]>
Date: Fri, 15 Aug 2014 16:18:56 -0700

> word "mandate" that confused things.

That's merely one of several examples that demonstrate the problem of
conflating a portion of the scenario that allows no flexibility, which a
portion that does.

> Opportunism here is to take the opportunity to do the *best* encryption

Right.  Hence the phrase "best effort" makes sense.

In any case, this entire topic is notably being pursued in response to
the problem of having scenarios that are overly demanding, with either
authenticated encryption or no encryption (or no session.)

That is, the entire point behind this exercise is to specify scenarios
that say "try to do authenticated encryption, but if you can't, then do
unauthenticated."

> encryption you are able to.

Yup.  You use encryption.  Keep that point in mind.

Opportunistic is about choices in encryption.

It is not about 'no encryption'.  It is not about "requiring only and
exactly one kind of encryption'.

> available is not an "opportunity". It's a compromise. 

Clever language play, but entirely the wrong focus.

Worse, the idea that you could put forward such a different perspective
on use the word opportunistic than I've been using -- that is, that we
could have such a basic disconnect -- speaks, yet again, to the failure
of this draft to be clear about its nature and its choices.

The focus on "opportunity" is permitting fallback, rather than choosing
cleartext of no session.  Note the subtitle: Some Protection Most of the
Time.

> The opportunity is

That's simply inaccurate, in terms of how this topic has been
consistently discussed, and more especially in terms of what problem it
is trying to fix.

d/

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Aug 2014 00:30:38 +0100

Dave,

On 16/08/14 00:18, Dave Crocker wrote:
> It is not about 'no encryption'.  

I have only seen you espouse that opinion, which is not
what's in Viktor's draft. Presenting your views as if
those were generally accepted is somewhat distracting.

I myself believe that you are mistaken here and that any
opportunistic security approach has to allow for the
undesirable but potential fallback to no encryption for
some peers (hopefully few) to be viable. Without that
there would be too many failure cases that would hinder
interop and the OS approach would not be adopted as we
have seen over and over that better interop trumps
better security when those are in conflict.

Yes, that is a (reasonable) speculation. Its is also
independent of the term used.

S.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 15 Aug 2014 16:38:27 -0700

> those were generally accepted is somewhat distracting.

I apologize.

It never occurred to me -- and I don't believe I have seen community
support for the idea -- that no encryption is reasonable to count as a
form of encryption.

(Also, c.f., my earlier concern that the work here include silliness.)

I also can't comprehend claims that it is a form of encryption.

> some peers (hopefully few) to be viable.

So when I go to order a meal and decide I don't like anything on the
menu and then decide not to get any food, that still counts as having
ordered food?

That's the logic being used here, Stephen.

There is a difference between the larger issue of 'allowing' opting out
of having any encryption, versus calling no encryption a form of encryption.

> Without that
> interop 

With respsect to encryption, no encryption is not a form of encryption
interop.

d/

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 15 Aug 2014 23:44:07 +0000

On Aug 15, 2014, at 4:38 PM, Dave Crocker <[email-masked]> wrote:

> It never occurred to me -- and I don't believe I have seen community support for the idea -- that no encryption is reasonable to count as a form of encryption.

We could discuss ESP-NULL. While I would not agree that it is a form of encryption, it is a defined algorithm with respect to IPsec ESP. It is usually discussed in the context of authentication, as a replacement for ESP-AH.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 16 Aug 2014 01:13:29 +0100

On 16/08/14 00:44, Fred Baker (fred) wrote:
>> It never occurred to me -- and I don't believe I have seen
>> community support for the idea -- that no encryption is reasonable
>> to count as a form of encryption.
> 
> We could discuss ESP-NULL. While I would not agree that it is a form
> of encryption, it is a defined algorithm with respect to IPsec ESP.
> It is usually discussed in the context of authentication, as a
> replacement for ESP-AH.

Actually I don't think we need to go there.

Opportunistic security (OS) is not a form of encryption.

Nor is no-encryption a form of encryption.

OS, according to the draft, is a protocol design pattern that
can result in the use of encryption or that can result in the
use of no-encryption.

That does not make no-encryption a form of encryption.

Both are potential outcomes when a protocol is designed according
to the OS pattern. In other words when a protocol uses the
OS pattern then stuff (e.g. in-band negotiation or whatever)
happens and the end result is the protocol endpoints have a
security configuration (whether to encrypt or not and in the
former case, how) for this "run" of the protocol.

Done well, we'd all hope that no-encryption is a rare outcome,
but we can't rule it out, says the draft.

S.

---

From: <[email-masked]>
Date: Sat, 16 Aug 2014 02:21:18 +0000

Recognition that security doesn't have to be absolute, and that
security can still be useful for privacy etc even though it is often
incapable of being absolute, is, imo, a good thing, and a nicely
more nuanced approach than the security-ueber-alles approach
of recent years. The idea of the desire to communicate over and
above any demand or requirement for encryption is a pretty clear
user need.

(Oddly, no-encryption as a form of encryption was the DTNRG's preferred
approach to reliability. NULL cases are quite common, if only
for testing.)

I'd like to see this draft discuss http early on - redirecting any http
request to https (via 301/302/303/307 redirection) for login pages etc.
is transparent, opportunistic, and easy to do, and a widespread example
that gets the opportunistic idea across; I've explained this to Stephen
previously.

But implementing something this simple to support the underlying
philosophy is certainly not a 'protocol design pattern', which has to
be the wankiest phrasing I've seen in IETF circles in quite some time.

Lloyd Wood
http://about.me/lloydwood

Oooh! I'm not a draft author, I'm a protocol design pattern originator!
________________________________________
From: ietf <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Sent: Saturday, 16 August 2014 10:13 AM
To: Fred Baker (fred); [email-masked]
Cc: Pete Resnick; Paul Wouters; [email-masked]
Subject: Re: Review of:  Opportunistic Security -03 preview for comment

S.

---

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: <[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: 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: Michael Richardson <[email-masked]>
Date: Sat, 16 Aug 2014 15:44:26 -0400

> That does not make no-encryption a form of encryption.

Agreed, but just to give an example of how ESP-NULL can *enable*
encryption....

One of the potential outcomes of some non-authenticated OS systems might be
that enterprise border systems might be more willing to let various kinds of
"secured" traffic through, such as permitting end-to-end IPsec using
ESP-NULL, as those border systems can now both: a) audit the inner traffic,
b) opportunistically then encrypt between borders, and maybe (c)
encrypt between end system and borders.

This is a mechnanism that I wanted to standardize back in 1996 at my first
IETF meeting... when IPsec impacted against "authenticated firewall
traversal" ideas...

(I think we are boiling the ocean on this document. Publish it)

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

---

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

On Sat, 16 Aug 2014, John Wroclawski wrote:

> 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.

[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:16:08 -0500

> that gets the opportunistic idea across; I've explained this to Stephen

OS should be applied to HTTP, but there may be enough to discuss there
that we'd never finish with this I-D if we had to deal with it now.

But yes, HTTP w/ OS is something we'll definitely want.  At the most
basic level if a server advertises TLSA RRs in DNS, verifiable with
DNSSEC.  Then HTTP clients that support OS should (MUST!) use HTTPS for
all HTTP requests to such a server.

The tricky issue is: how can users and hypermedia authors denote "no
fallback to cleartext" -- adding a new URI scheme is the first thought
that comes to mind about that, but it seems likely not to be that
simple.  Admittedly a "no fallback to cleartext" indication may prove
unnecessary: eventually support for unauthenticated encryption may reach
a large enough proportion of servers that clients can begin disabling
fallback to cleartext.  But you see my concern: it's too soon to tell
whether we'll need to do anything about indicating no fallbackto
cleartext.

Nico
--

---

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:22:09 -0500

> (I think we are boiling the ocean on this document. Publish it)

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.

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: <[email-masked]>
Date: Sun, 17 Aug 2014 01:05:48 +0000

I am uncomfortable with the MUST.

fallback to cleartext is often helpful (web caching and performance proxying of graphics/noncritical items), useful for debugging, and does not inadvertently prevent communication when the security apparatus inevitably screws up.

I view fallback to cleartext as a feature, not a bug. (I often edit https to http in urls - if the server wants to serve https, fine, but I am not going to demand it - and dnssec is just another point of failure.)

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Nico Williams <[email-masked]>
Sent: Sunday, 17 August 2014 6:16:08 AM
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Review of:  Opportunistic Security -03 preview for comment

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: 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: Paul Wouters <[email-masked]>
Date: Sun, 17 Aug 2014 11:10:06 -0400 (EDT)

> all HTTP requests to such a server.

Excellent. If only people had listed to me when I proposed this meaning
to the TLSA record, and people had not gone the HASTLS/nowhere route :)

I'd be happy to write an update to RFC 6698 with such text :P

> simple.

URI's are for software, not humans. Humans cannot do "http" vs "https".

> Admittedly a "no fallback to cleartext" indication may prove

I would leave that to the UI people. Personally, having the red glow
over my page instead of a warning box I'll just click away seems a
reasonable override for "protocol hardfail".

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: John Wroclawski <[email-masked]>
Date: Fri, 15 Aug 2014 21:03:09 -0700

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.

> there do better whenever possible for each peer.

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: 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,

>> (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, ...
> 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: Viktor Dukhovni <[email-masked]>
Date: Tue, 19 Aug 2014 20:54:31 +0000

On Tue, Aug 19, 2014 at 04:42:07PM -0400, Benjamin Kaduk wrote:

> 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.

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:00:21 -0400

Ben,
> so "authenticated sessions" may be better.
I used the term "communication" since it could encompass e-mail, not
only sessions. Admittedly, we are focusing on realtime communication,
but it seems prudent to not be unduly exclusive in the range of
protocols that we try to address.

Steve

---

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

Ian,

> On 20/08/2014 16:03 pm, Stephen Kent wrote:
>> 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,
> It's not more precise, it's either a distinction of no difference or a
> mistake.
so says the man with how many RFCs and other publications to his credit?
> 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.
a lot of security is not at all crypto-based: non-Ipsec firewalls,
IDS's, ...
> So in this sense of high-level viewpoint, the distinction is no
> 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.
> 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 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, ...
> 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.
we disagree on whether TOFU is crypto-related.
> and because it has the advantage of being represented by an
> acronym that isn't so common
> (OCS vs. OS) in our arena.
yes.
> 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.
opp-sec is not an acronym, so I don't see the parallel.

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