On Thu, Mar 19, 2015 at 12:06:13PM +0100, Leif Johansson wrote:
> We need to get this document out the door! Getting a few reviews would
> help a great deal!
Overall the document is in good shape.
In section 3 a sentence is truncated:
3. URI-ID identifier type (subjectAltName of
uniformResourceIdentifier type [RFC5280]) MUST NOT be used by
clients for server verification, as
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).
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
