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

[Mahesh Jethanandani <[e-mail]>]

Hi Peter,

The text looks good to me.

Thanks.

> On Aug 10, 2015, at 7:17 PM, Peter Saint-Andre - &yet <[e-mail]> 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).
> 
> ###
> 
> 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 <[e-mail]> wrote:
>>> 
>>> 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
>>> 
>>> On 8/6/15 4:33 AM, Benoit Claise wrote:
>>>> 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.
>>>> 
>>>> 

Mahesh Jethanandani
[e-mail]