-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/7/12 3:12 PM, Peter Saint-Andre wrote: > Hi Matt and Tony, a few notes from my perspective. > > On 6/7/12 2:53 PM, Matt Miller wrote: > >> On Jun 7, 2012, at 13:13, Tony Finch wrote: > >>> >>> This looks mostly good to me - it's going in pretty much the >>> right direction. By which I mean I am specifying basically the >>> same semantics for the MUA protocols :-) >>> > >> Thanks for the feedback. It's good to know we're not completely >> off (-: > >>> The pragmatics of deployment are somewhat different between >>> XMPP and email, I think, since email deployments usually use >>> certificates for the server host names whereas XMPP >>> deployments use certificates for the JID domain. This might >>> mean we have to specify different fallback behaviour. I haven't >>> pinned down the precise details yet. >>> >>> Detailed comments and questions: >>> >>> >>> Section 4 (XMPP SRV + DNSSEC): >>> >>> There is no mention of CNAME or DNAME indirections. They do not >>> break the model, provided the entire indirection chain is >>> secure. >>> > >> Noted. > > Personally I'd prefer to not mention those indirections for now > because they muddy the waters a bit for typical XMPP deployments. > >>> Bogus answers should be treated as security failures and cause >>> the client to abort. Insecure/indeterminate answers should be >>> treated as if DNSSEC were not present. At the moment the draft >>> treats these the same. >>> > >> Good point; will fix in next revision. > > Agreed. > >>> Points 4,5,6: There is no need to check the security status of >>> the SRV target addresses, since the client is going to verify >>> that the server's certificate matches the SRV target host >>> name. >>> > >> I think I agree if there are TLSA records to be found. However, >> if there are no TLSA records, I do think the checks mean there >> are additional names verify against. > >> However, you're not the first to suggest remove them! I'll >> ponder on improvements here, and remove them if I can't think of >> any. > > We definitely need (and already do) step 4 in Section 4. The > question is whether we need to validate the A/AAAA lookups as > secure. I see Tony's point here and perhaps we don't need the > latter validation. > >>> Point 7: The client SHOULD check the source domain if the >>> derived domain doesn't match. Making the source check a MAY is >>> too weak: you don't want DNSSEC deployment to change a working >>> configuration into a broken one. >>> > >> I think my current phrasing is bad. Basically, we want to >> expand the possible identities allowed in the certificate to >> include the derived domain in addition to RFC6120's requirements. >> I'll change the text to reflect that. > > Right, sloppy wording on our part. > >>> Section 5.1: What if the SRV records specify non-standard port >>> numbers? Or does "not been delegated" mean the same thing as >>> "missing SRV records"? >>> > >> For this section, "not been delegated" means "no SRV records". >> I'll clarify that. > > Can't an SRV lookup for foo.example.com point to foo.example.com? > That wouldn't be delegation to another entity, even if the port > were non-standard. > >>> Section 5.2: What port number should the client use in the TLSA >>> query? Should the setup be like this? (using a non-standard >>> port for clarity) >>> >>> _xmpp-client._tcp.im.example.com SRV 1 1 5555 im.example.com >>> _5555._tcp.im.example.com TLSA ... >>> > >> In this particular case, I think we really do want the standard >> port 5222, e.g. "_5222._tcp.im.example.com". > > We had some discussion about this on the XMPP WG list, see for > example: > > http://www.ietf.org/mail-archive/web/xmpp/current/msg02765.html > > My reading of the DANE spec is that the port in the prepared > domain name would be the port that is assumed to be correct for > the application protocol in question. Since the IANA-registered > port for XMPP client-to-server communication is 5222, you'd use > 5222 instead of any non-standard port that you might have > discovered via SRV. But I admit that I might be reading too much > into the DANE spec on this point.
Matt and I talked about in person and he convinced me that the port wouldn't be the IANA-registered port but whatever port you happen to be using for your XMPP service. So despite the fact that port 80 is typically an HTTP port, jabber80.com (yes, there is such a thing!) would have: _xmpp-client._tcp.jabber80.com SRV 1 1 80 im.example.com _80._tcp.im.example.com TLSA ... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/RLO0ACgkQNL8k5A2w/vztsQCfbtWmpta6IeaRXh9urPYIboBy Z50AoLz0z5F4OXDAjclmIjbOtrFhBwF9 =kE80 -----END PGP SIGNATURE----- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
