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

From: Matt Miller <[email-masked]>
Date: Wed, 6 Jun 2012 09:40:01 -0600

FYI

Begin forwarded message:

> From: [email-masked]
> Date: June 6, 2012 09:37:12 MDT
> To: [email-masked]
> Subject: I-D Action: draft-miller-xmpp-dnssec-prooftype-00.txt
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Using DNSSEC and DANE as a Prooftype for XMPP Delegation
> 	Author(s)       : Matthew Miller
>                          Peter Saint-Andre
> 	Filename        : draft-miller-xmpp-dnssec-prooftype-00.txt
> 	Pages           : 6
> 	Date            : 2012-06-06
> 
>   This document defines a model for securely delegating an XMPP service
>   for a domain to a host associated with a different domain.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-miller-xmpp-dnssec-prooftype-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-miller-xmpp-dnssec-prooftype-00.txt
> 
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-miller-xmpp-dnssec-prooftype/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Jun 2012 20:13:17 +0100

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  <[email-masked]>  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.

---

From: Matt Miller <[email-masked]>
Date: Thu, 7 Jun 2012 14:53:48 -0600

> model, provided the entire indirection chain is secure.

Noted.

> if DNSSEC were not present. At the moment the draft treats these the same.

Good point; will fix in next revision.

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

> you don't want DNSSEC deployment to change a working configuration

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.

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

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

> that DANE can't be used if the SRV record is not secure.

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

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

> missing conflicts with section 4.

Good point; will remove in next revision.

> another good configuration without accidentally passing through a bad

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.

> additional verification code paths rather than completely distinct

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Jun 2012 15:12:54 -0600

Hi Matt and Tony, a few notes from my perspective.

On 6/7/12 2:53 PM, Matt Miller 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 :-)
>> 
> 
>> 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.
>> 
>> 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.
>> 
> 

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.

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

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

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

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.
>> 
> 
> if   (source domain == derived domain) do 5.1 elif (source domain
> != derived domain) do 5.3
> 
>> 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/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Jun 2012 16:36:29 -0600

On 6/7/12 3:12 PM, Peter Saint-Andre wrote:
>>> 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.
>>> 
>> 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 
>> 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.
> 
> 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.
> 
>>>  query? Should the setup be like this? (using a non-standard
>>> port for clarity)
>>> 
> 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/

---

From: Matt Miller <[email-masked]>
Date: Thu, 7 Jun 2012 16:48:16 -0600

On Jun 7, 2012, at 15:12, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

< snip >

> 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 >
> wouldn't be delegation to another entity, even if the port were

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

See note about IRL conversation (-:

< snip >

>> simply added a technicality to fail on.

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

---

From: Tony Finch <[email-masked]>
Date: Fri, 8 Jun 2012 11:43:35 +0100

> > simply added a technicality to fail on.

Yes this is a valid argument and I agree. However I also think consistency
is important. Why would some TLSA usages require name matches and others
not? Why disable a check done by existing code rather than just adding
checks?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames, Dover, Wight, Portland: Southwest 7 to severe gale 9, decreasing 6
later in Wight and Portland. Rough or very rough. Squally showers. Moderate or
good.

---

From: Tony Finch <[email-masked]>
Date: Fri, 8 Jun 2012 11:54:01 +0100

Glad we're all pretty much agreeing :-) One further question:

> If this specification is about DNSSEC with DANE goodness, then I do
> think the A/AAAA verification is necessary, or at least recommended.

What advantage does the verification have, if the client is going to check
the server certificate? (I'm assuming that bogus == DNS lookup failure, so
the question is about secure vs. insecure.) The client is knows the SRV
record is secure so the link from source domain to derived domain is
secure. If the address records are insecure, the client needs to check a
certificate to be sure the server is the right one; the client gets the
same level of assurance whether it matches the source or derived domain.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher: Southeast 5 to 7. Moderate or rough. Occasional rain. Good,
occasionally poor.

---

From: Matt Miller <[email-masked]>
Date: Fri, 8 Jun 2012 11:02:03 -0600

> same level of assurance whether it matches the source or derived domain.

I was thinking of a case where a hosting provider ("hosting.example.net" in our text) has their DNS entries hijacked, and the hijacker finds a CA that will issue them certs for the hijacked name.  My thinking was this can be mitigated by verifying the A/AAAA records.

That was my thinking, but I'm less convinced it's worth covering now, and will probably remove in the next revision.

- m&m

---

From: Matt Miller <[email-masked]>
Date: Fri, 8 Jun 2012 11:02:34 -0600

> not? Why disable a check done by existing code rather than just adding

For Usage 3, the TLS client was effectively told what to match in totality.  I see this check as overly burdensome on deployments, and not very burdensome on implementers.

- m&m