On 21/03/2015 07:38, Viktor Dukhovni wrote:
[...]
Below is a proposal to expand the scope to cover use of email
certificates (still other than MTA-to-MTA) with DANE.
Since the DANE SRV draft is almost ready for IETF LC, I think it is
reasonable to also discuss the use-case for DNSSEC/DANE validated
indirection:
_imaps._tcp.example.com. IN SRV 0 0 993 mail.example.com.
_993._tcp.mail.example.com. IN TLSA 3 1 1 <ee-digest>
_993._tcp.mail.example.com. IN TLSA 2 0 1 <ta-digest>
https://tools.ietf.org/html/draft-ietf-dane-srv-11
When an IMAP or submission client locates the service endpoint via
SRV records (as described in RFC 6186), and said clients supports
DNSSEC and DANE, an alternative to the use of SRV-ID reference
identifiers at the service domain is to use DNSSEC to authenticate
the redirection and DANE to authenticate the certificate of the
target host.
When the DANE usage is not DANE-EE(3) (which ignores any names in
the certificate) the domain part of the reference identifier in
that case would be as described in the DANE SRV draft. This could
be with or without the corresponding service prefix.
Such servers would then be authenticated via any of:
* Standard PKIX CA validation with name checks per this
draft.
* A DANE-EE(3) match of the certificate or key blob with
TLSA base domains per the SRV draft.
* Any other DANE usage with the same name checks as in
the draft.
* Any other DANE usage with the TLSA base domain rather
than the service domain as the domain part of the reference
identifier, with or without an _service prefix.
There is also a use-case for DANE without SRV indirection. In
which case, the service domain is typically the TLSA base domain,
except as modified by DNSSEC-validated CNAME chasing with TLSA
records located at the end of the CNAME chain.
https://tools.ietf.org/html/draft-ietf-dane-ops-07
See also
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-7
http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-3.1.3
that may relevant for clients that use DNS for service discovery
and potentially employ TLS "opportunistically" based on whether
TLS-capable services are located. Such clients should probably
limit their DANE usages to DANE-TA(2) and DANE-EE(3).
I would like to be able to use DANE for verifying DNS SRVs, but the
scope of this document is to try use existing primitives and not trying
to tie this to DANE/DNSSEC deployments.
I would be happy to work later on an updated document that includes this
though.
I would again ask other people to weight in on this.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
