On Wed, Aug 06, 2014 at 09:23:02PM -0400, Paul Wouters wrote:
On Tue, 5 Aug 2014, Nico Williams wrote:
To be more specific OS must not preclude things like DANE that can be
opportunistic and provide strong authentication.
Do no forget that during the saag discussion that preceded this
draft, this was one of the main differences between our views, and
that I do not subscribe to the view that opportunistic security is
a narrow response to PM or that it should be limited to promoting
just unauthenticated encryption.
More than that: why should OS stop there?
Aren't these two comments of contradicting? First you say authenticated
encryption is not opportunistic security, then you say that OS should
be more then just unauthenticated encryption and should not stop there?
Are we reading the same quotes? I don't understand your response.
Where did I say that "authenticated encryption is not opportunistic
security"? Remember, I was really responding to Stephen K., not Viktor.
As for the second quote, I meant that OS shouldn't mean only
"unauthenticated security", which with DANE in context makes sense:
- if you can securely discover that a service can do strong
authentication, do _that_
(Securely discover: there's a DNSSEC path from . to the service's
RRSets' names, AND there are TLSA-like RRSets for it that bootstrap
authentication from DNSSEC. Remember: DNSSEC provices secure
NXDOMAIN results.)
- otherwise attempt unauthenticated encryption
(The service had no TLSA-like RRSets or one of the zones from .
to it doesn't support DNSSEC.)
The ability to securely bootstrap authentication via DNSSEC is
"opportunistic": we do it when it (DNSSEC, TLSA RRs) is there, we don't
when it isn't. Teh key here is that DNSSEC allows us to securely detect
that this path isn't available.
The ability to use unauthenticated encryption when we would otherwise do
cleartext is also "opportunistic": we do it if we can negotiate it.
Nico
--