Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
draft-ietf-xmpp-dna-11

[Ballot comment]
The conversation started between Mahesh (OPS-DIR reviewer) and the authors on the following points:

Summary:

This document defines new “prooftype” used to establish a strong association between a domain name and an XML stream. There are two companion documents draft-ietf-xmpp-posh-04 and draft-ietf-dane-srv-12 that should be viewed as part of reviewing this document.

If there are any management requirements to configure the new “prooftype”, they have not been discussed as part of this document. I did not review the companion documents to see if management of the feature has been addressed in them. This document should talk about how the feature will be managed, even if it means referring to relevant sections of the other documents. If there is a need to define a YANG model to configure the feature, it should be identified, even if it is not defined in this document.

From an operational perspective, it would be helpful to know how this would be deployed in the field. Are there any issues beyond certificate configuration that operators should be aware of? Some of the services are replacements for existing services, e.g. DNS with secure DNS. How would the operators role out the service in the field with existing service(s)?

Section 3:

The document talks about establishing a client to server Domain Name Association (DNA) in this section. This is a simpler case of the server to server DNA. However, it is not clear what happens if the certificate verification fails. Is the behavior the same as when a self-signed certificate is presented? Is there a fallback process or does the session just terminate?

In addition, the following nits should be addressed in the document.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the
    document.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-14) exists of
    draft-ietf-dane-srv-12

  ** Downref: Normative reference to an Informational RFC: RFC 4949

  -- Possible downref: Non-RFC (?) normative reference: ref. 'XEP-0220'

  == Outdated reference: draft-ietf-uta-xmpp has been published as RFC 7590

  -- Obsolete informational reference (is this intentional?): RFC 3920
    (Obsoleted by RFC 6120)


    Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (—).


Thanks.

[Ballot comment]

- section 3: does nobody ever use mutually authenticated
TLS for this with XMPP? (Just wondering.)

- 3.2: I didn't know that XMPP clients send a user ID in
cleartext before turning on TLS. Pity that.  Is it ok
for a client to fake that and then later authenticate as
a different entity such as "usertwo@a.example"?

- 3.2, step 5: "proving" isn't quite right but is good
enough here.

- 4.1: Please separate the seperable pictures by at
least some whitespace but ideally with captions.  Right
now it looks initially as if it's just one big figure.
At present, I find that figure makes things less clear
rather than more.

- 4.2, bullets: the 2nd last one here is really similar
to the 1st two (as I read 'em). Maybe consider merging.
And the use of "is trusted by" in the 1st two is a bit
inaccurate, but could be lived with;-)

- 4.4.1: should the refs for dialback (and the "first
specified..." comment) be earlier?

- 5.1: Is there going to be another "XMPP with DANE
prooftype" document? I'm not sure that 5.1 alone is
enough, and there is one for POSH, so I wondered.

- 5.2: does this repeat text from the POSH I-D?  If so,
is that a good idea?

- 8.1: Huh? Why aren't these in the POSH I-d?

- 8.1/8.2: Is it a good/bad idea to have structure in
the .well-known URIs and where that structure is not a
pathname? Personally, I think it's not a great idea but
that's just a personal preference. I also don't think
"_tcp.json" is good to include in the URI.

[Ballot comment]
Apart from the ".well-known" issue brought up in my comments to xmpp-posh, I have only one, tiny comment here:

-- Section 1 --

  If such delegation is not done in
  a secure manner, then the domain name association cannot be verified.

Really small point: many people find these sorts of negative-negative constructions to be confusing, so I suggest this:

NEW
  The domain name association can only be verified when the delegation
  is done in a secure manner.
END

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-xmpp-dna-10.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Well-Known URIs registrty located at:

https://www.iana.org/assignments/well-known-uris/

two, new well-known URIs will be regtistered as follows:

URI Suffix: posh._xmpp-client._tcp.json
Change Controller: IETF
Reference: [ RFC-to-be ]
Related information:
Date registered: [ TBD-at-registration ]

URI Suffix: posh._xmpp-server._tcp.json
Change Controller: IETF
Reference: [ RFC-to-be ]
Related information:
Date registered: [ TBD-at-registration ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we initiated the required Expert Review via a separate request. The reviewer has approved these registrations.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)) to Proposed Standard


The IESG has received a request from the Extensible Messaging and
Presence Protocol WG (xmpp) to consider the following document:
- 'Domain Name Associations (DNA) in the Extensible Messaging and
  Presence Protocol (XMPP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-07-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Please note that this draft has a normative reference to the XMPP Standards Foundation XEP 0220.

Abstract


  This document improves the security of the Extensible Messaging and
  Presence Protocol (XMPP) in two ways.  First, it specifies how to
  establish a strong association between a domain name and an XML
  stream, using the concept of "prooftypes".  Second, it describes how
  to securely delegate a service domain name (e.g., example.com) to a
  target server host name (e.g., hosting.example.net), which is
  especially important in multi-tenanted environments where the same
  target server hosts a large number of domains.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO Shepherd Writeup for draft-ietf-xmpp-dna

Shepherd writeup for draft-ietf-xmpp-dna-10

1. Summary

The document shepherd is Dave Cridland.

The responsible Area Director is Ben Campbell.

This document defines the XMPP Domain Name Association (DNA) framework. The
abstract states the document does two things to improve security in XMPP:

    "First, it specifies how to
  establish a strong association between a domain name and an XML
  stream, using the concept of "prooftypes".  Second, it describes how
  to securely delegate a service domain name (e.g., example.com) to a
  target server host name (e.g., hosting.example.net) [...]"

Overall, the document establishes a framework for server authentication
mechanisms, known as "prooftypes", by which servers can provide multiple
forms of proof of their identity to both clients and other peer servers.

The Working Group believes the document is ready to be used as the base
framework, and indeed is already so used by draft-ietf-xmpp-posh. On that
basis it is requested to be published as a Standards Track document at
"Proposed Standard".

2. Review and Consensus

The XMPP working group is chartered to provide a solution to allow a
hosting service to share an XMPP server among multiple hosted domains.
That effort produced the Domain Name Assertion (DNA) framework, and the
"PKIX over Secure HTTP", or "POSH", prooftype, which is still a
work-in-progress at the time of this writing.

In IETF 86, the working group had a draft-ietf-xmpp-dna document edited
by Richard Barnes and Jonas Lindborg, however Richard suggested replacing that working group draft with the individual draft written by
Peter Saint-Andre and Matthew Miller. After IETF 86, the working group
then adopted Peter's draft over Richard's.

After version 8 of the document, Philipp Hancke (also an author of
XEP-0220, XEP-0288, and XEP-0344) joined as co-author.

The majority of reviews concentrated on two areas:

a) Avoiding the considerable overlap between this document and several
others, including RFC 6120, RFC 6125, XEP-0220, XEP-0288 and XEP-0344.

b) Correcting errors within the (highly complex) area of server to server
authentication.

It should be noted that much of the document is simply describing the
state of the art with respect to server to server authentication, which
is spread over several documents, and noting the points where
authentication and authorization decisions are required.

The chairs believe that consensus has been reached for the document to be
published. As this document essentially distils the somewhat scattered
specification and knowledge of S2S auth, it would be fair to say it has
high implementation already, however multiple implementations have
adopted the model described in this document as the basis for work
underway for DANE, POSH and other prooftypes.

3) Intellectual Property

No IPR has been disclosed with respect to this specification.

Matthew Miller is unaware of any IPR, and is aware of his obligations under BCP 78 and BCP 79.
Philipp Hancke is unaware of any IPR, and is aware of his obligations under BCP 78 and BCP 79.
Peter Saint-Andre is unaware of any IPR, and is aware of his obligations under BCP 78 and BCP 79.

4) Other Points

None.