On Jun 7, 2012, at 15:12, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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:
< snip > >>> 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. > If this specification is all about DANE (which, to me, implies DNSSEC), then I agree it's not necessary. If this specification is about DNSSEC with DANE goodness, then I do think the A/AAAA verification is necessary, or at least recommended. Per an IRL conversation between Peter and I, I'll change this to be RECOMMENDED sans DANE, but MAY (at best) con DANE. >>> < snip > > >>> 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. > With the IRL conversation stpeter and I just had, I'm going to re-word this section to mean "no SRV records". I'll try to re-word the "Secure Delegation" section to include the case where the SRV record's target host is identical to the source domain (but might be to a different port). >>> 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. > See note about IRL conversation (-: >>> >> < snip > >>> >>> Section 5.4: >>> >>> What is the point of omitting the name check in this case? >>> Alternatively, what is the point of including the name check in >>> the other DANE cases? My drafts say that name checks should >>> still be performed in the usual way, the idea being that DANE >>> leads to additional verification code paths rather than >>> completely distinct code paths. >>> >> >> My thinking was, if we got to this point, then the name in the >> certificate was no longer material. The delegation by the source >> domain to the derived domain was already proved, and this check >> simply added a technicality to fail on. > > Agreed. > But like I said, it's not a hill for me to die on. I'm content with keeping it or removing it. - m&m Matt Miller - <[email protected]> Cisco Systems, Inc.
smime.p7s
Description: S/MIME cryptographic signature
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
