Subject: [xmpp] Benoit Claise's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 06 Aug 2015 03:33:42 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-xmpp-dna-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 10 Aug 2015 17:31:27 -0600

Hi Benoit, I posted a reply to the OPS-DIR review here:

https://mailarchive.ietf.org/arch/msg/xmpp/VymvhuVNfSFaNv8YEjpslzR_tw4

My feeling is that it would be best for this document to point to the 
companion documents (draft-ietf-xmpp-posh and draft-ietf-dane-srv) with 
regard to operations and management. Note that draft-ietf-dane-srv 
already includes the following text:

###

6.  Guidance for Server Operators

    To conform to this specification, the published SRV records and
    subsequent address (A and AAAA) records MUST be secured with DNSSEC.
    There SHOULD also be at least one TLSA record published that
    authenticates the server's certificate.

    When using TLSA records with Certificate Usage "DANE-EE", it is not
    necessary for the deployed certificate to contain an identifier for
    either the source domain or target server host name.  However,
    operators need to be aware that servers relying solely on validation
    using Certificate Usage "DANE-EE" TLSA records might prevent clients
    that do not support this specification from successfully connecting
    with TLS.

    For TLSA records with Certificate Usage types other than "DANE-EE",
    the certificate(s) MUST contain an identifier that matches:

    o  the service domain name (the "source domain" in [RFC6125] terms,
       which is the SRV query domain); and/or

    o  the target server host name (the "derived domain" in [RFC6125]
       terms, which is the SRV target host name).

    Servers that support multiple service domains (i.e., so-called
    "multi-tenanted environments") can implement the Transport Layer
    Security Server Name Indication (TLS SNI) [RFC6066] or its functional
    equivalent to determine which certificate to offer.  Clients that do
    not support this specification will indicate a preference for the
    service domain name, while clients that support this specification
    will indicate the target server host name.  However, the server
    determines what certificate to present in the TLS handshake; e.g.,
    the presented certificate might only authenticate the target server
    host name.

###

Is that text helpful and complete? (Note that draft-ietf-dane-srv has 
already been approved for publication, but if we need to make some 
slight adjustments during AUTH48 we could do so.)

Also, do you think it would be preferable for draft-ietf-xmpp-posh to 
include a similar section providing guidance for server operators in 
draft-ietf-xmpp-posh? If so, Matt and I can work to formulate some text.

Thanks!

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 10 Aug 2015 20:17:04 -0600

Hi Mahesh,

I suggest that we add a section something like the following to 
draft-ietf-xmpp-dna and then add a section to draft-ietf-xmpp-posh as 
well (I haven't written any text for the latter yet, thus the "FIXME" 
for a section number in what follows).

###

8.  Guidance for Server Operators

    This document introduces the concept of a prooftype in order to
    explain and generalize the approach to establishing a strong
    association between the DNS domain name of an XMPP service and the
    XML stream that a client or peer server initiates with that service.

    The operators of XMPP services will not directly deploy DNA
    prooftypes, and the operations and management implications will
    depend on the prooftypes that an operator supports.  For example:

    o  To support the PKIX prooftype [RFC6120], an operator needs to
       interact with a certification authority but does not need to
       deploy DNS security.

    o  To support the DANE prooftype [I-D.ietf-dane-srv], an operator can
       generate its own certificates or obtain them from a certification
       authority but needs to deploy DNS security.

    o  To support the POSH prooftype [I-D.ietf-xmpp-posh], an operator
       can generate its own certificates or obtain them from a
       certification authority but does not need to deploy DNS security.

    Considerations for use of the foregoing prooftypes are explained in
    the relevant specifications.  See in particular Section 13.7 of
    [RFC6120], Section 6 of [I-D.ietf-dane-srv], and Section FIXME of
    [I-D.ietf-xmpp-posh].

    Naturally, these operations and management considerations are
    additive: if an operator wishes to use multiple prooftypes, the
    complexity of deployment increases (e.g., the operator might want to
    obtain a PKIX certificate from a certification authority for use in
    the PKIX prooftype and generate its own certificate for use in the
    DANE prooftype).  This is an unavoidable aspect of supporting as many
    prooftypes as needed in order to ensure that domain name associations
    can be established in the largest possible percentage of cases.

###

What do you think?

(I haven't shared this text yet with my co-authors, since I've been 
working on it just now.)

Peter

On 8/10/15 8:09 PM, Mahesh Jethanandani wrote:
> Peter,
>
> I agree. As I suggested in the review, a reference to the section you reproduce below from draft-ietf-dane-srv (and a similar reference to a section in draft-ietf-xmpp-posh) is what you need in draft-ietf-xmpp-dna.
>
> Cheers.
>
>> On Aug 10, 2015, at 4:31 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:
>>
>> My feeling is that it would be best for this document to point to the companion documents (draft-ietf-xmpp-posh and draft-ietf-dane-srv) with regard to operations and management. Note that draft-ietf-dane-srv already includes the following text:
>>
>> ###
>>
>> Is that text helpful and complete? (Note that draft-ietf-dane-srv has already been approved for publication, but if we need to make some slight adjustments during AUTH48 we could do so.)
>>
>> Also, do you think it would be preferable for draft-ietf-xmpp-posh to include a similar section providing guidance for server operators in draft-ietf-xmpp-posh? If so, Matt and I can work to formulate some text.
>>
>> Thanks!
>>
>> Peter
>>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 10 Aug 2015 19:09:04 -0700

Peter,

Cheers.

>> https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

Mahesh Jethanandani
[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 10 Aug 2015 19:27:27 -0700

Hi Peter,

The text looks good to me.

Thanks.

> On Aug 10, 2015, at 7:17 PM, Peter Saint-Andre - &yet <[email-masked]> wrote:
> 
> Hi Mahesh,
> 
> I suggest that we add a section something like the following to draft-ietf-xmpp-dna and then add a section to draft-ietf-xmpp-posh as well (I haven't written any text for the latter yet, thus the "FIXME" for a section number in what follows).
> 
> ###
> 
> (I haven't shared this text yet with my co-authors, since I've been working on it just now.)
> 
> Peter
> 

Mahesh Jethanandani
[email-masked]

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 11 Aug 2015 09:56:28 -0600

Great, thanks for checking it.

BTW, here is initial proposed text for the section we would reference in 
draft-ietf-xmpp-posh (I know you weren't tasked with reviewing that 
spec, so I'm including it here only for completeness):

###

    POSH is intended to ease the operational burden of securing
    application services, especially in multi-tenanted environments.  It
    does so by obviating the need to obtain certificates for hosted
    domains, so that an operator can obtain a certificate only for its
    hosting service (naturally, this certificate needs to be valid
    according to [RFC5280] and contain the proper identifier(s) in
    accordance with [RFC6125] and the relevant application protocol
    specification).

    However, in order to use POSH, an operator does need to coordinate
    with its customers so that the appropriate POSH files are provided
    via HTTPS at a well-known URI at each customer's domain (i.e., at the
    Source Domain), thus ensuring delegation to the operator's hosting
    service (i.e., the Delegated Domain).  Because correct hosting of the
    POSH file at the Source Domain is essential for successful
    functioning of the POSH "chain", errors at the Source Domain will
    result in authentication problems, certificate warnings, and other
    operational issues.

    Furthermore, if the POSH file performs reference rather than
    possession as described in this document, the operational burden is
    further decreased since the operator does not need to provision its
    customers with updated POSH files when the certificate for the
    Delegated Domain expires or is replaced.

###

Matt Miller and I will work on that text further this week.

Peter

-- 
Peter Saint-Andre
https://andyet.com/