ietf
[Top] [All Lists]

Re: Adept Encryption: Was: [saag] DANE should be more prominent (Re: Review of: Opportunistic Security -03 preview for comment)

2014-08-21 07:25:07
On Thu, Aug 21, 2014 at 7:07 AM, Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:

Dave,

I expect we are not going to agree on this, but that's fine.

On 21/08/14 02:45, Dave Crocker wrote:
On 8/20/2014 6:18 PM, Stephen Farrell wrote:
Personally, I think the probability that we suddenly discover any
significantly better term is negligible. Not because OS is
super-good, but rather because nothing is super-good. And
good-enough should be good-enough here.

While there has been repeated, quick dismissal of alternative terms, I
don't recall seeing a careful consideration of candidates, with a clear
explanation for the choice(s) made, making clear why it is better (or
why its deficiencies are less onerous than those of the alternatives.)

That happened on the saag list before the start of IETF LC.
There are quite a few substantive threads on it, I think
the first goes back on March 6th this year started by PHB. [1]

   [1] https://www.ietf.org/mail-archive/web/saag/current/msg04604.html

And in that message PHB presciently wrote:

"There are arguments for all of these but I am just watching a
presentation on 'opportunistic encryption' in DANE and I think the
term is selling DANE short.

DNS is an authoritative path for statements about DNS labels. Ergo
authenticated DNS RRs are authenticated statements about them. DANE
provides authenticated statements about security policy and keys. Ergo
DANE cannot support opportunistic encryption because it is policy
directed encryption (i.e. better)."


With all due respect [1], I don't think this effort is helping the
goal of getting encryption deployed and used.

'Pragmatic Security' is a much better term for what we should do which
is to act on the best available information.


We have a collection of policy inputs:

* The https URI prefix means 'use http over TLS'
* Presence of a DANE record means 'use TLS with key matching these criteria'
* Protocol headers can be defined to mean 'use TLS'
* Manual user config


We have a variety of key publication mechanisms

* Self signed cert
...
* Extended Validation Web PKI certificate


So pragmatic security means 'act on the best available intel'.

Using the terms 'opportunistic security' does not help because I am
not interested in opportunistic security except as a last resort. I
don't expect an RFC titled 'last resort kinda rubbish security' to be
giving me advice relevant to anything other than last resort
situations.

<Prev in Thread] Current Thread [Next in Thread>