On Thu, Aug 21, 2014 at 7:07 AM, Stephen Farrell <stephen.farrell@xxxxxxxxx> 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.