Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)

Dhruv Dhody <dhruv.dhody@huawei.com> Thu, 03 August 2017 13:33 UTC

Return-Path: <dhruv.dhody@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B48131F5A; Thu, 3 Aug 2017 06:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 RuvHt1W_zqj7; Thu, 3 Aug 2017 06:33:19 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C35131F5C; Thu, 3 Aug 2017 06:33:17 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLW52463; Thu, 03 Aug 2017 13:33:15 +0000 (GMT)
Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 3 Aug 2017 14:33:13 +0100
Received: from BLREML501-MBB.china.huawei.com ([10.20.5.200]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Thu, 3 Aug 2017 19:03:01 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: 'Eric Rescorla' <ekr@rtfm.com>, The IESG <iesg@ietf.org>
CC: "cmargaria@juniper.net" <cmargaria@juniper.net>, "draft-ietf-pce-pceps@ietf.org" <draft-ietf-pce-pceps@ietf.org>, "pce@ietf.org" <pce@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Thread-Topic: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)
Thread-Index: AQHTCuS9a5lteACDJUiXLjY6vwnXVqJx/TVw
Date: Thu, 03 Aug 2017 13:33:00 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8CB98604@blreml501-mbb>
References: <150160552743.9608.12510518895697614960.idtracker@ietfa.amsl.com>
In-Reply-To: <150160552743.9608.12510518895697614960.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.79.10]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5983261B.022B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: f92bca682966fed498036fb9b9e0d297
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/ZOEe4iGyv100JWTYLm0Cte4Tf4k>
Subject: Re: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Aug 2017 13:33:22 -0000

Hi Eric, 

Thanks for your review, please see inline...

> -----Original Message-----
> From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Eric Rescorla
> Sent: 01 August 2017 22:09
> To: The IESG <iesg@ietf.org>
> Cc: cmargaria@juniper.net; draft-ietf-pce-pceps@ietf.org; pce@ietf.org;
> pce-chairs@ietf.org
> Subject: [Pce] Eric Rescorla's Discuss on draft-ietf-pce-pceps-15: (with
> DISCUSS and COMMENT)
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-pce-pceps-15: Discuss
> 
> 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-pce-pceps/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 1. This needs a cite to RFC 6125 to define how to do name validation.
> 
[[Dhruv Dhody]] Updated. 

              +  Implementations MUST follow the rules and guidelines for
                 peer validation as defined in [RFC6125].

> 2. You require TLS_RSA_WITH_AES_128_GCM_SHA256, but this is not consistent
> with modern recommendations, which are for algorithms that provide forward
> secrecy. You should be recommending
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 with P-256, which is consistent
> with the recommendations for TLS 1.3 (and UTA, IIRC).
> 
[[Dhruv Dhody]] The reason for the misalignment has been just a matter of time, for a document in the review queue for a while. We are happy to align with TLS 1.3 and UTA recommendations. Text updated to - 

       *  PCEPS implementations MUST, at a minimum, support negotiation
          of the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 [RFC6460], and
          SHOULD support TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as
          well.  Implementations SHOULD support the NIST P-256
          (secp256r1) curve [RFC4492].  In addition, PCEPS
          implementations MUST support negotiation of the mandatory-to-
          implement ciphersuites required by the versions of TLS that
          they support.

> 3, It's clear to me how authentication of the PCE works in that the PCC
> connects to it using a domain name or IP address and therefore can check
> the PCC's certificate against that, but it's not clear to me what the PCE
> does when the client connects?
> Is it supposed to have a list of valid peers?
> 
[[Dhruv Dhody]] Any of the usual techniques applicable in TLS to verify client authorization can be applied here: from a list of trusted CAs, to a list of fingerprints and identities associated to them.

> 4. The error reporting mechanism you describe in S 3.2 is unusual:
> 
>    After the exchange of StartTLS messages, if a PCEP speaker cannot
>    establish a TLS connection for some reason (e.g. the required
>    mechanisms for certificate revocation checking are not available), it
>    MUST return a PCErr message (in clear) with Error-Type set to [TBA2
>    by IANA] (PCEP StartTLS failure) and Error-value set to:
> 
> I am not aware of any other protocol that does this, and it's a bit
> problematic because you either need to (a) require that you always send a
> TLS alert so that the receiver knows that the next byte is a PCE message
> or (b) specify some mechanism for demuxing PCE and TLS. Even in the former
> category, many TLS stacks are greedy about their IO, so they will read the
> alert + the PCE message and then discard the message. Instead you should
> either:
> 
> (a) specify that you always send TLS alerts and don't send PCE errors (TLS
> alerts are pretty rich)
> (b) send any post-handshake alerts over the TLS connection.
> 
> Failing that, you need to provide detailed instructions about how to make
> this work.
> 
[[Dhruv Dhody]] I have added this text - 

   Note that, the PCEP implementation MUST send the PCErr message once
   the TLS connection has been closed i.e. the TLS close_notify
   [RFC5246] has been received from the peer.  As per [RFC5246], if the
   data may be carried over the underlying transport after the TLS
   connection is closed, the TLS implementation must receive the
   responding close_notify alert before indicating to the application
   layer that the TLS connection has ended.

Would this resolve the discuss? 

> 
> 5. It seems like it would be a good idea to specify a pinning mechanism so
> you could say "always do TLS in future". Is that something that was
> discussed?
> 
[[Dhruv Dhody]] The document uses a SHOULD right now. Do you have some suggested text or a reference for this?

> 6.        *  TLS with X.509 certificates using certificate fingerprints:
>           Implementations MUST allow the configuration of a list of
>           trusted certificates, identified via fingerprint of the
>           Distinguished Encoding Rules (DER) encoded certificate octets.
>           Implementations MUST support SHA-256 as defined by [SHS] as
>           the hash algorithm for the fingerprint.
> 
> What does "trusted" mean here? I think it means "one I would accept as a
> counterparty" rather than "can sign other certs". In any case, this must
> be clear.
[[Dhruv Dhody]] Updated to - 

       *  TLS with X.509 certificates using certificate fingerprints:
          Implementations MUST allow the configuration of a list of
          certificates that are trusted to identify peers, identified
          via fingerprint of the Distinguished Encoding Rules (DER)
          encoded certificate octets.  Implementations MUST support
          SHA-256 as defined by [SHS] as the hash algorithm for the
          fingerprint.

> 
> A bunch of other stuff is underspecified (see below).
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This document needs a significant editorial pass. I found a number of
> writing errors, e.g., "Securing via TLS of an existing PCEP session is not
> permitted,"
> 
[[Dhruv Dhody]] Some updates are done, other authors will redo an editorial pass. 

> S 1.
>    defining their application in depth.  Moreover, [RFC6952] remarks the
>    importance of ensuring PCEP communication privacy, especially when
> 
> The term here is "confidentiality"
> 
[[Dhruv Dhody]] Ack, updated but RFC6952 used that word :)

> S 3.2.
> The whole description of how you can race StartTLS iff you know you are
> TLS only is really hard to understand until you get to the diagrams. I
> would write something like:
> 
>    The PCC initiates the use of TLS by sending a StartTLS message
>    The PCE agrees to the use of TLS by responding with its own
>    StartTLS message. If the PCE is configured to only do TLS, it
>    may send the StartTLS message immediately upon TCP connection
>    establishment; otherwise it MUST wait for the PCC's first
>    message to see whether it is an Open or StartTLS message.
> 
> 
[[Dhruv Dhody]] Ack. I have added this at the start.
> 
> S 3.4.
>           +  Implementations SHOULD indicate their trusted CAs.  For TLS
>              1.2, this is done using [RFC5246], Section 7.4.4,
>              "certificate_authorities" (server side) and [RFC6066],
>              Section 6 "Trusted CA Indication" (client side).
> 
> Do common stacks do this? I know NSS does not.
> 
> 
[[Dhruv Dhody]] Should be a part of platform setup, BTW this text is same as RFC6614. If you have recommendations in other RFCs, please let us known. 

>    To support TLS re-negotiation both peers MUST support the mechanism
>    described in [RFC5746].  Any attempt to initiate a TLS handshake to
>    establish new cryptographic parameters not aligned with [RFC5746]
>    SHALL be considered a TLS negotiation failure.
> 
> Is there a reason to allow renegotiation at all?
> 
[[Dhruv Dhody]] The only reason for mentioning renegotiation was historical (as it was discussed in some prior RFCs we have used as reference). As per the current recommendations we have removed the text. 

> 
> S 3.5
>    [I-D.ietf-pce-stateful-sync-optimizations] specify a Speaker Entity
>    Identifier TLV (SPEAKER-ENTITY-ID), as an optional TLV that MAY be
>    included in the OPEN Object.  It contains a unique identifier for the
>    node that does not change during the lifetime of the PCEP speaker.
>    An implementation would thus expose the speaker entity identifier as
>    part of the X509v3 certificate, so that an implementation could use
>    this identifier for the peer identification trust model.
> 
> This seems underspecified. Is there an OID assigned?
> 
> 
[[Dhruv Dhody]] Updated, added subjectAltName:otherName

> S 4.1.
>    DANE [RFC6698] defines a secure method to associate the certificate
>    that is obtained from a TLS server with a domain name using DNS,
>    i.e., using the TLSA DNS resource record (RR) to associate a TLS
>    server certificate or public key with the domain name where the
>    record is found, thus forming a "TLSA certificate association".  The
>    DNS information needs to be protected by DNS Security (DNSSEC).  A
>    PCC willing to apply DANE to verify server identity MUST conform to
>    the rules defined in section 4 of [RFC6698].  The server's domain
>    name must be authorized separately, as TLSA does not provide any
>    useful authorization guarantees.
> 
> This is also underspecified. Which DANE types are you suggesting you use?
> 
> 
[[Dhruv Dhody]] Added text  - 

   The implementation MUST
   support Service certificate constraint (TLSA Certificate Usages type
   1) with Matching type 2 (SHA2-256) as described in
   [RFC6698][RFC7671].

> S  7.
>    Some TLS ciphersuites only provide integrity validation of their
>    payload, and provide no encryption.  This specification does not
>    forbid the use of such ciphersuites, but administrators must weight
>    carefully the risk of relevant internal data leakage that can occur
>    in such a case, as explicitly stated by [RFC6952].
> 
> Why don't you forbid it?
> 
[[Dhruv Dhody]] The main reason for not completely forbidding them is that many PCE connections are considered to be "internal", within the provider dedicated management network. In discussions with operational units, they expressed concerns about traceability and error detection in case of full encryption. I'd suggest to avoid the forbidding, but leaving a strong requirement (with a "RECOMMENDED" or a "SHOULD"). I have updated the text to - 

   Some TLS ciphersuites only provide integrity validation of their
   payload, and provide no encryption, such ciphersuites SHOULD NOT be
   used by default.  Administrators MAY allow the usage of these
   ciphersuites after careful weighting of the risk of relevant internal
   data leakage, that can occur in such a case, as explicitly stated by
   [RFC6952].


Working version: https://github.com/dhruvdhody-huawei/ietf/blob/master/draft-ietf-pce-pceps-16.txt
Diff: https://tools.ietf.org/rfcdiff?url1=draft-ietf-pce-pceps-15&url2=https://raw.githubusercontent.com/dhruvdhody-huawei/ietf/master/draft-ietf-pce-pceps-16.txt

Regards,
Dhruv

> 
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce