On 2014-06-11 17:45, Viktor Dukhovni wrote: > 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.
That's what I was aiming for. > >> 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 Perhaps a reference to that then? >>> 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. Then how is server.example.net supposed to know that you want to talk to example.org? "its equivalent" is said to be the stream addressing earlier which makes this weird. >> 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. > Right, of course. -- Kim "Zash" Alvefur
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
