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

[Peter Saint-Andre <[e-mail]>]

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

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

This might be related to two points in RFC 6120, Section 3.2.1:

   8.  If the initiating entity receives a response to its SRV query but
       it is not able to establish an XMPP connection using the data
       received in the response, it SHOULD NOT attempt the fallback
       process described in the next section (this helps to prevent a
       state mismatch between inbound and outbound connections).

   9.  If the initiating entity does not receive a response to its SRV
       query, it SHOULD attempt the fallback process described in the
       next section.

I'll think about this a bit more, too.

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

Does it? See above. It depends on what is meant by "assumed to exist"
in the following text:

   1.  The decimal representation of the port number on which a TLS-
       based service is assumed to exist is prepended with an underscore
       character ("_") to become the left-most label in the prepared
       domain name.

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

Let's see what the outcome of this port conversation is first. :)

>> The requirement to check the source domain if the TLSA records
>> are missing conflicts with section 4.
>> 
> 
> Good point; will remove in next revision.

Yep, thanks for noticing the mismatch.

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

Agreed.

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/RGVYACgkQNL8k5A2w/vxxXACdE1NrL7IiFJj0Mq0BTAANi2Qd
DLEAoOWiVJjS0mb61Ju1cJSQnpuvkmTe
=IZpz
-----END PGP SIGNATURE-----