On Tue, Aug 05, 2014 at 08:28:03PM -0700, Dave Crocker wrote:
> On 8/5/2014 8:14 PM, Scott Kitterman wrote:
> > It seems to me that all it means is that the MTA is taking the opportunity to
> > make the most secure connection it can on a peer basis. Sometime that's going
> > to be a full DANE negotiated session protected by DNSSEC. Other times it's
> > not. I think the major point of opportunistic isn't how good the resulting
> > security is, but the idea of taking advantage of the best option available on
> > a per peer basis rather than treating it as all or nothing.
>
> That looks like quite a good paragraph to me. I understand it, and it
> describes something meaningful... and distinctive from current
> approaches to use of encryption.
Fundamentally, Scott is paraphrasing what I said.
> Focusing on a "framework that permits decreasing levels of encryption
> protection" or similar language resonates with what I've been reading
> about this opportunistic thing. (My own view is that cleartext has no
> place within that hierarchy, so some sort of minimum encryption needs to
> be described.
That would rule out incremental upgrades of legacy infrastructure
in which cleartext is for now unavoidable (e.g. SMTP) to opportunistic
security. I hope the draft discourages cleartext sufficiently,
while allowing it when necessary.
> > On 8/5/2014 8:16 PM, Viktor Dukhovni wrote:
> > DANE with authentication can be either opportunistic (enabled via
> >> discovery on a peer by peer basis) or mandatory (required by local
> >> policy, URI scheme, ...). Postfix for example supports both
> >> opportunistic and mandatory DANE TLS:
>
> Sorry, but I don't understand how "enabled via discovery on a peer by
> peer basis" is any different from use of StartTLS. That sort of
> confusion should not be prompted by 'definition' of such a basic term.
>
> So while Scott's paragraph enjoys wonderfulness, what you are saying
> still doesn't make much sense to me. Worse, I fear that language of the
> sort you are using will prove not very useful to the community.
We don't need to worry too much about the clarity of wording in
what I say off the cuff in response to messages on the list.
However, if the draft's wording is still substantially in need of
improvement to make its core points more clear, please suggest
specific improvements. Ideally in the form of an XML diff that
lifts the veil of confusion without diverting the intent:
http://www.ietf.org/id/draft-dukhovni-opportunistic-security-02.xml
--
Viktor.