On Tue, May 06, 2014 at 11:42:55AM -0400, Olafur Gudmundsson wrote:
> The SMTP draft is proposing that it is ok to use TLSA records that are
> stored with Address records even if the Service (MX) records are not
> signed.
Note, this is predicated on the assumption that the client's security
policy is "opportunistic", and that it is OK to send email in the
clear or with unauthenticated TLS, when DANE is not employed.
The draft also briefly touches on "mandatory DANE TLS", in which
the sender demands strong transport protection for some destination
domains. In that case, only "Full" below is acceptable.
> Attempts to answer the question as what kind of security models can we
> have with DANE?
>
> Full: All records used to find service, address and authentication
> are DNSSEC protected
>
> Server only: Address and Authentication records are DNSSEC protected
>
> Service only: Service and Authentication records are protected
> but not Address records
>
> Questions that need answers:
> - What are the security implications of each model?
> - What types of security does each model provide ?
> - What is not possible with each model?
> - What threats does each model handle?
> - any others?
So for me, the context in which this questions is set is whether
the application security policy is mandatory (security expected)
or opportunistic (no security expected, but opportunities for
security on a peer-by-peer basis are not missed).
Thus, I would suggest that the above 3-way choice is not at the
right layer of the problem. The model is mandatory protection or
opportunistic security, or ... which then leads one to make the
appropriate choices.
There are variations on the models:
- Mandatory protection with DANE when available and PKIX as a fallback.
(Works poorly with protocols that employ DNS SSRs, but is viable for
protocols ala HTTPS).
- Opportunistic DANE, with key-continuity protocols (authenticated
pinning e.g. TACK, this also runs into difficulties with SSRs).
- ...
That said, the key dichotomy is I believe "mandatory" vs.
"opportunistic" security. The discussion about "discovery" in
London was in disguise a discussion about the admissibility of
"opportunistic" uses of DANE, which need to "discover" peers that
support DANE. We seem to have crossed that bridge without falling
off, so now we can pay attention to each relevant model as
further specifications are developed.
> Do we (as a WG) want to document these models formally and the
> implications of each model operationally ?
I believe that opportunistic security models are going to be more
important in IETF protocols (some of you may be keeping track of
the lively discussion on the saag list). And thus it is not
unreasonable to define "opportunistic DANE TLS" more broadly, with
the SMTP draft a first step in that direction (a test case if you
like).
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
