On 8/15/2014 10:34 AM, Viktor Dukhovni wrote:
> On Fri, Aug 15, 2014 at 08:54:18AM -0700, Dave Crocker wrote:
>>> 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.
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.
>>> 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.
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.
>>> 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.
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.
>>> 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.
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.
> The first sentence is what you're consistently not taking at face
> 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.
>> 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.
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
> way to do "opportunistically employ" authentication. And this is
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".
> 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
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.
>> 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 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.
>> 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.
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".
>>> 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.
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.
>>> 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.
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.
>>> 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.
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.
>>> 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.
Sorry. Right. Current text looks ok.
>>> 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...
Sorry, that sentence was left from my pre-release review. The remainder
were/are comments I formulated today.
>>> 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.
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'.
>>> 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.
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.
>>> 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.
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.
>>> 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.
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.
>> 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
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.
> 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...
Clearly it is not.
On 8/15/2014 12:11 PM, Viktor Dukhovni wrote:> 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.
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/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net