Re: [dane] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt

[Matt Miller <[e-mail]>]

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.

> 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.

> 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.

> 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.

> 
> 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.

> 
> 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".

> Note that it is very unlikely for the SRV to be insecure but the TLSA to
> be secure and therefore usable. Perhaps it would be simpler to specify
> that DANE can't be used if the SRV record is not secure.
> 

That would be easier.  I'll ponder on this more.

> 
> Section 5.3:
> 
> In this case the TLSA records should definitely be looked
> up using the port numbers specified in the SRV records.
> (That's what draft-ietf-dane-protocol section 3 says.)
> 

I can remove the text after "... then the TLS client SHOULD query for a TLSA resource record as described in [DANE]".


> The requirement to check the source domain if the TLSA records are
> missing conflicts with section 4.
> 

Good point; will remove in next revision.

> I wonder if there are situations where checking the source (as in 5.1)
> can conflict with checking the target (as in 5.3). We need to be sure
> that a service can easily change from one good configuration to
> another good configuration without accidentally passing through a bad
> configuration.
> 

I think the two can be treated as mutually exclusive without undo burden on implementations.

if   (source domain == derived domain) do 5.1
elif (source domain != derived domain) do 5.3

Not sure yet if it needs to explicitly stated anywhere, but I'll think more about it.

> 
> 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.

However, it's not something I'm willing to fight for.  I can remove it unless there's a better suggestion.


Thanks again for the feedback!

- m&m

Matt Miller - <[e-mail]>
Cisco Systems, Inc.