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

[Benoit Claise <[e-mail]>]

Thanks Peter and Mahesh.

Regards, Benoit
> 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):
>
> ###
>
>
> 8.  Guidance for Server Operators
>
>    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
>
> On 8/10/15 8:27 PM, Mahesh Jethanandani wrote:
>> 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.
>>>>>>
>>>>>>
>
>