ietf
[Top] [All Lists]

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

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

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

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

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

Actually, it involves stepping /down/.

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

   A related goal is broader adoption of protection against active
   attacks, by enabling incremental deployment of authenticated
   encryption.

Although this sounds entirely reasonable, there is no explanation
provided to make it credible.  (n fact it is not at all clear to me that
is /us/ credible...)  How will use of an opportunistic pattern lea to
broader adoption?

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

   Both opportunistically
   employed encryption and opportunistically employed authentication
   need to avoid deployment roadblocks and need to be designed with care
   to "just work".

I have no idea what the last sentence means.

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

   Opportunistic security does not start with an over-estimate of peer
   capabilities only to settle for lesser protection when a peer fails
   to deliver.  Rather, opportunistic security sets a minimum protection
   level expected of all peers, which is raised for peers that are
   capable of more.

This paragraph is not very helpful.  The issue here has nothing to do
with estimation.  (Can a design pattern make an estimation?)

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

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

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

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

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

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

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


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

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

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

This is worded a bit differently than in the preview draft I saw, but I
still have no idea what that sentence means.  The language that follows
is about preference, not enforcement.

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

You're still not reading the definitions as stated.

If authentication is only possible for some peers, then it is
acceptable to authenticate only those peers and not the rest.

It is only sometimes acceptable.  It is essential that the text here
highlight that such a fallback needs to be the result of careful
analysis and choice and not a casual default.

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




   Employ PFS:  Opportunistic Security should employ Perfect Forward
      Secrecy (PFS) to protect previously recorded encrypted
      communication from decryption even after a compromise of long-term
      keys.

I'm told that PFS isn't really possible for asyncrhonous, object-based
encryption, such as for email.

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

No misrepresentation of security:

Unauthenticated encrypted communication must not be misrepresented as
communication over a secure channel.

Oh boy.  That sentence is far too compact and not obviouly correct.  In
fact it is arguably wrong.

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

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

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

So is this.


5.  Example: Opportunistic TLS in SMTP

   Many Message Transfer Agents (MTAs, [RFC5598]) support the STARTTLS
   ([RFC3207]) ESMTP extension.  MTAs acting as SMTP clients are
   generally willing to send email without TLS (and therefore without

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

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

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

   deliver -> transmit

Sure.

   Recent reports from a number of large providers suggest that the
   majority of SMTP email transmission on the Internet is now encrypted,
   and the trend is toward increasing adoption.

This anecdotal comment isn't needed, isn't substantiated, and is going
to be distracting when this document is read 20 years from now.  I
suggest removing it.

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


   Not only is the STARTTLS advertisement vulnerable to active attacks,
   but also at present some MTAs that advertise STARTTLS exhibit various
   interoperability problems in their implementations.  As a result, it

Again, the ephemeral frame of refernce won't be helpful.

So:

    but also an MTA that advertises STARTTLS can produce various
interoperability problems in its implementation.  As a result, it might
choose to fall back to cleartext...

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

6.  Security Considerations

   Though opportunistic security potentially supports transmission in
   cleartext, unauthenticated encryption, or other cryptographic
   protection levels short of the strongest potentially applicable, the
   effective security for peers is not reduced.  If a cryptographic
   capability is neither required by policy nor supported by the peer,
   nothing is lost by going without.  Opportunistic security is strictly
   stronger than the alternative of providing no security services when
   maximal security is not applicable.

I'll repeat that counting "cleartext" as part of an opportunistic
pattern is a strategic error.  In simple terms, it is saying that no
security is part of security.

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

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

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

   Opportunistic security coexists with and is preempted by any
   applicable non-opportunistic security policy.  However, such non-

This first sentence makes no real sense to me or worse is confusing.  It
does not "coexist".  If it is preempted, it is at best subordinated.

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

-- 
        Viktor.