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

[Mahesh Jethanandani <[e-mail]>]

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.
>> 
>> 
> 
> 
> -- 
> Peter Saint-Andre
> https://andyet.com/

Mahesh Jethanandani
[e-mail]