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

[Viktor Dukhovni <[e-mail]>]

On Thu, Aug 21, 2014 at 08:24:22AM -0400, Phillip Hallam-Baker wrote:

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

Yes, thanks for that message, it got the ball rolling.

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

The reasons why that's not the case were explained and we are now
defining what it means for DANE to be used opportunistically.  It
can also be used for mandatory authentication just for the key
management part.  TLS can likewise be used for sessions with
mandatory encryption and authentication, or as "opportunistic TLS"
with SMTP.  Neither DANE nor TLS are opportunistic or not, they
are just tools that can be used in multiple ways.

> DNS is an authoritative path for statements about DNS labels. Ergo
> authenticated DNS RRs are authenticated statements about them.

Correct, and this is precisely why DANE/DNSSEC can be used to
securely discover which peers have published TLSA RRs and can be
authenticated.  The existence of an authenticated out-of-band
(relative to the application protocol) mechanism for publishing
capabilities[*] is what makes it possible to employ opportunistic DANE
TLS.  What's opportunistic is still the use of TLS (with DANE
providing a downgrade resistant commitment to "STARTTLS" and key
material to enable authentication).

    * Yes OS protocols can overload TLSA RRs as a capability
      to employ TLS *with* authentication.

> DANE
> provides authenticated statements about security policy and keys. Ergo
> DANE cannot support opportunistic encryption because it is policy
> directed encryption (i.e. better)."

But the keys are not always there, in fact currently for SMTP, I
know of ~32 domains with published TLSA RRs for their MX hosts,
and that's probably accurate to within a factor of 10 or so.

So from the perspective of an MTA, TLS with DANE is very much
opportunistic.

    * Look up MX RRset.  If not DNSSEC "secure", back to
      plain opportunistic STARTTLS for all MX hosts.

    * For each MX host (sorted by priority in the usual way) 
      look up up A/AAAA RRset, if not DNSSEC "secure", back
      to plain opportunistic STARTTLS for that MX host.

    * Look up TLSA RRset, unless present and DNSSEC "secure",
      back to plain opportunistic STARTTLS for that host.

    * If all TLSA RRs are unusable, require STARTTLS encryption,
      without authentication (since no usable authentication
      keys available).

    * If some TLSA RRs are usable, require STARTTLS encryption,
      with authentication.

The above is done for each peer domain, and for each peer MX host.
What is opportunistic is the use of possibly authenticated TLS,
with out-of-band signally via DANE enabling downgrade-resistant
authentication.

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

On Sun, Aug 17, 2014 at 11:20:26 -0400, Phillip Hallam-Baker wrote off-list:

> On Sat, Aug 16, 2014 at 11:17 PM, Viktor Dukhovni <[e-mail]> wrote:
> > On Sat, Aug 16, 2014 at 11:13:23PM -0400, Phillip Hallam-Baker wrote:
> >
> >> DANE isn't opportunistic security. It is authenticated security policy
> >> and keys. Thats the opposite of opportunistic.
> >
> > Have you read the draft?  DANE can be "opportunistically employed",
> > when TLSA records are present, and not when they are absent.
> > While DANE is not opportunistic per-se, a protocol employing it,
> > for example:
> >
> >     http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-11
> >
> > sure is.  This statement suggests you've either not read the draft,
> > or just skimmed it.  It is also possible that my explanation of this
> > is too obtuse, in which case please help me polish it, or at least
> > chime in on the need for me or others to spell this out in more
> > detail, e.g. in the SMTP example at the end of the draft.
>
> Draft, schmaft.
> 
> Opportunistic encryption is a pre-existing term of art. If the draft
> is causing people to get confused about what opportunistic encryption
> is then it should not be published.

Have you read either draft yet?  We're not even defining "opportunistic
encryption".  We're defining "opportunistic security", which is
not surprisingly a broader term.

> We have a collection of policy inputs:
> 
> * The https URI prefix means 'use http over TLS'

That is mandatory local policy (based on HTTPS URI
semantics), and OS is out of scope.  OS is in scope
for SMTP, IMAP, XMPP, and HTTP where no explicit
security mandate is in force.

> * Presence of a DANE record means 'use TLS with key matching these criteria'

If this in the context of an "HTTPS" URI, then the use of DANE key
management for mandatory authentication is out of scope for the OS
draft.

> * Protocol headers can be defined to mean 'use TLS'
> * Manual user config

OS is about selecting a mutually supported set of security mechanisms,
even if that sometimes results in less than complete cryptographic
protection or even cleartext.

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

Well, at least we largely agree on the substance.  If your object
is just to the term, please send your thoughts off-list to Stephen
Farrell, he'll presumably let us how the rough consensus worked out.

> Using the terms 'opportunistic security' does not help because I am
> not interested in opportunistic security except as a last resort.

Whichever term we choose will mean exactly the same thing, with
different words.  So it makes no sense to presume that OS means
something other than your suggested term of "pragmatic security",
they are one and the same.  We're just choosing the term.

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

Good thing that's not the phrase we're proposing. :-)

-- 
	Viktor.