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

[Tony Finch <[e-mail]>]

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 :-)

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.

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.

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.

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.


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


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

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.


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

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

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.


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.


Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Shannon, Rockall: North 6 to gale 8, backing northwest 5 to 7 later. Rough,
occasionally very rough in Shannon. Rain or showers. Moderate or good.