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

Benoit Claise <bclaise@cisco.com> Fri, 04 September 2015 10:00 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94961B4820; Fri, 4 Sep 2015 03:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aKAuDonlHJi; Fri, 4 Sep 2015 03:00:24 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218EF1B47F3; Fri, 4 Sep 2015 03:00:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12557; q=dns/txt; s=iport; t=1441360824; x=1442570424; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=oygWIWHPT763Wr2Hx6uPRIEzTobAXIcwgWoejqPWvDE=; b=Uj4s+nVqCfZ5PSTEu3eNzmvgsXP8oMGA2d6MmrmX83BI0H2rf6iLEkct l9TYNLzXFVwbBsyPPuCLybdsXYxEi/ca++QLrq29mPWWKPKRp2aJPW9/s A2Ul3H21I7JttBHxDI6CGCrmquRiVSl1opCV4bTGdZ3sIOqiKHirpGb0Q 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DLAwDIaulV/xbLJq1dg3VpvVUBCYF3hXsCgXIUAQEBAQEBAYEKQQWDXgEBBCMPAQVAARALGAICBRYLAgIJAwIBAgFFBgEMBgIBAQWIJQ22DZQ5AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EihVGDdoEFhCgRAQZLB4JpgUMBBIcxhUaFOoMghQeCbYUDgUqEMoJ8kXgmghAcgVY8MwGERoM+BxcHgSEBAQE
X-IronPort-AV: E=Sophos;i="5.17,468,1437436800"; d="scan'208";a="611383738"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 04 Sep 2015 10:00:20 +0000
Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t84A0J5v008774; Fri, 4 Sep 2015 10:00:19 GMT
To: Peter Saint-Andre - &yet <peter@andyet.net>, Mahesh Jethanandani <mjethanandani@gmail.com>
References: <20150806103342.2703.18148.idtracker@ietfa.amsl.com> <55C9344F.90201@andyet.net> <11AAE863-30CB-4B50-90FE-C83D68E434EA@gmail.com> <55C95B20.3050902@andyet.net> <8208F533-C48C-48DC-8756-7A3F99938F67@gmail.com> <55CA1B2C.3030406@andyet.net>
From: Benoit Claise <bclaise@cisco.com>
Message-ID: <55E96BB3.7010108@cisco.com>
Date: Fri, 4 Sep 2015 12:00:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55CA1B2C.3030406@andyet.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/-PgaawQPDCtdkDsDNErD5m6dw_A>
Cc: draft-ietf-xmpp-dna.ad@ietf.org, draft-ietf-xmpp-dna@ietf.org, xmpp-chairs@ietf.org, xmpp@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-xmpp-dna.shepherd@ietf.org
Subject: Re: [xmpp] Benoit Claise's No Objection on draft-ietf-xmpp-dna-10: (with COMMENT)
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2015 10:00:28 -0000

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 
>>> <peter@andyet.net> 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 
>>>>> <peter@andyet.net> 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.
>>>>>>
>>>>>>
>
>