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

Peter Saint-Andre - &yet <> Mon, 10 August 2015 23:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6AC931A1B4E for <>; Mon, 10 Aug 2015 16:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fLR9xOQB8Yrc for <>; Mon, 10 Aug 2015 16:31:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD5311A1AB6 for <>; Mon, 10 Aug 2015 16:31:31 -0700 (PDT)
Received: by igbpg9 with SMTP id pg9so80169645igb.0 for <>; Mon, 10 Aug 2015 16:31:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=aAlLvzd1w66ozQ9gxsM0CNGAVejetD53gYyHWUFHpYM=; b=HGsOq5Igjf10ty69ZBdTJN72hZuxU94yZ/22U06h83l6A8GSJOfTumH9O44bA9z1YB Z38VGdK0U4Opg8Fet8UN8Ag90/BAYiDu0OVYyA7zvUlnUiT7tdmIR/yBx1fFG4uxHWju oIykkiPtoWyjluKUs4t/O8MUWKOCvoiuIaeSjVqKTNYlZs2d46bAZgGvs7KN/IM6ZYbs VmkNN1ojq7j/p5OIK31EJHzNbCeLa1pa2J3SqtXrAkvy1X4KRUdn9rSzvA6RqdexVi00 5supZtmuOjj7+T0eXx1inV1ZvsIxde7/X5Ffjk3OzMc5iv3oPH6yh56RkUTh8tZUyJgg wx1g==
X-Gm-Message-State: ALoCoQmUJrrz04HwYvIWBotU0jyombTe0R0eSRFbGibCBHJ1uKs21msVlt44/QYAFaNnJEyfBJuk
X-Received: by with SMTP id f20mr9812083igq.54.1439249491208; Mon, 10 Aug 2015 16:31:31 -0700 (PDT)
Received: from aither.local ( []) by with ESMTPSA id f126sm279062ioe.21.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Aug 2015 16:31:29 -0700 (PDT)
To: Benoit Claise <>, The IESG <>
References: <>
From: Peter Saint-Andre - &yet <>
Message-ID: <>
Date: Mon, 10 Aug 2015 17:31:27 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [xmpp] Benoit Claise's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Aug 2015 23:31:35 -0000

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

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.



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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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 :
> ----------------------------------------------------------------------------
>    == 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