On Wed, Jun 11, 2014 at 05:21:22PM +0200, Kim Alvefur wrote:
> On 2014-06-11 03:24, Peter Saint-Andre wrote:
> > Matt Miller and I submitted a new version of draft-ietf-dane-srv today.
>
> Why does the text it Section 3 say to do queries in parallel when
> section 3.2 says that one has to do A/AAAA lookups and validation (which
> depend on SRV) before deciding to do TLSA lookups?
It says "where possible". As I see it the only sensible opportunity
for parallel lookup is to find the A or AAAA records of the subset
of the SRV hosts with the highest (untried) priority, then among
those that actually have an IP address, one can choose a randomized
server based on the weight, at which point I would only retrieve
TLSA records for that host.
Generally, all the SRV hosts are up and it is sufficient to try
one connection, so there is no benefit in performing multiple TLSA
lookups for clients that make long-lived infrequent connections.
In summary I think that while some clients may decide to parallelize
some DNS lookups, this is an implementation decision that is perhaps
out of scope for the DANE SRV specification.
> And what does the security status of A/AAAA records matter if you have a
> secure reference to the certificate you see? Unless of course if you
> get bogus, then aborting the connection to that target is sane.
See Section 2.2.2 of the SMTP draft, which provides the rationale:
http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-10.html#rfc.section.2.2.2
> > SRV is secure: The reference identifiers SHALL include both the
> > service domain and the SRV target server host name (e.g., include
> > both "im.example.com" and "xmpp23.hosting.example.net"). The
> > target server host name is the preferred name for TLS SNI or its
> > equivalent.
>
> In XMPP, sending to='xmpp123.hosting.example.net' instead of
> to='example.com' does not seem sensible to me. The server should know
> which cert to present for each domain, or probably just shows the same
> for all if it is a multi-tenant hosting service.
This suggestion breaks cross-domain hosting:
_service.example.org. IN SRV 0 0 12345 server.example.net.
The server.example.net hosting provider can obtain certs for its
own name, managing certs from each hosted domain is a significant
burden.
> And I don't think one should look too hard at the name in a certificate
> if you have a matching TLSA record.
You're not thinking about TA certificate usages PKIX-TA(0) and
DANE-TA(2) which absolutely require name checks. Even PKIX-EE(1)
requires name checks as part of the PKIX validation.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
