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

[Dhruv Dhody <[e-mail]>]

Hi Alexey, 

Thanks for your comments, see inline...

> -----Original Message-----
> From: Pce [mailto:[e-mail]] On Behalf Of Alexey Melnikov
> Sent: 03 August 2017 15:35
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with
> DISCUSS and COMMENT)
> 
> Alexey Melnikov 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:
> ----------------------------------------------------------------------
> 
> I am very glad to see this document and I will be switching to "Yes" once
> we discuss the following issues:
> 
> 1)
>                   +-+-+                 +-+-+
>                   |PCC|                 |PCE|
>                   +-+-+                 +-+-+
>                     |                     |
>                     | StartTLS            |
>                     | msg                 |
>                     |-------              |
>                     |       \   StartTLS  |
>                     |        \  msg       |
>                     |         \  ---------|
>                     |          \/         |
>                     |          /\         |
>                     |         /  -------->|
>                     |        /            |
>                     |<------              |
>                     |:::::::::TLS:::::::::| TLS Establishment
>                     |:::::Establishment:::| Failure
>                     |                     |
>                     |<--------------------| Send Error-Type TBA2
>                     |      PCErr          | Error-Value 3/4
>                     |                     |
> 
>       Figure 2: Both PCEP Speaker supports PCEPS (strict), but cannot
>                                establish TLS
> 
> Firstly, I think you also need to demonstrate a case when the server end
> of TLS is refusing to startTLS before trying TLS negotiation (e.g. if it
> doesn't have certificate configured). In this case you need to send PCErr
> in the clear. I think earlier text suggest that this case is possible.
> 
[[Dhruv Dhody]] No, the only error to StartTLS is by an implementation that does not understand the message. 
In case certificate is not configured we would start TLS negotiation, which would fail.  

> Secondly, does the case depicted on this picture mean that TLS was
> negotiated successfully, but TLS identities were not successfully verified?
> (I.e. the PCErr is sent over the TLS layer). If TLS failed to negotiate,
> you don't have a channel to send data on, as the other end will get
> confused. I think you just have to close connection in such case.
> 
[[Dhruv Dhody]] No, the PCErr is sent in clear over the TCP connection (underlying transport). 
EKR also made a similar point. I updated the text to include this - 

   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.

> So maybe you need 3 figures describing the above 3 cases.
> 
> 2) In Section 3.4:
> 
>         +  Implementations MAY allow the configuration of a set of
>              additional properties of the certificate to check for a
>              peer's authorization to communicate (e.g., a set of allowed
>              values in subjectAltName:URI or a set of allowed X509v3
>              Certificate Policies)
> 
> Can you give an example of what you expect to see in the
> subjectAltName:URI?
> Your current text doesn't seem sufficient for interoperability.
> 
[[Dhruv Dhody]] The reference for the text was from RFC6614, with the aim to keep the door open to define application service type portion to be checked as part of URI. I have added text that the definition of these properties is out of scope of this document. 
 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I am agreeing with Ekr's DISCUSS points. Some of mine might be just a
> different phrasing of his.
> 
> In Section 3.4.  TLS Connection Establishment
> 
>        *  PCEPS implementations MUST, at a minimum, support negotiation
>           of the TLS_RSA_WITH_AES_128_GCM_SHA256, and SHOULD support
>           TLS_RSA_WITH_AES_256_GCM_SHA384 as well [RFC5288].  In
>           addition, PCEPS implementations MUST support negotiation of
>           the mandatory-to-implement ciphersuites required by the
>           versions of TLS that they support.
> 
> Should the last sentence apply starting from TLS 1.3 forward?
> 
[[Dhruv Dhody]] Ack. Updated. 

> In Section 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
> 
> Can you be a bit more specific, as this looks underspecified. Are you
> thinking about using subject name or subject alt name for this (or either)?
> 

[[Dhruv Dhody]]This has been updated to use subjectAltName:otherName.

>    this identifier for the peer identification trust model.
> 
> In the Security Considerations sections:
> 
> I think you should also talk about downgrade attacks here, e.g.
> man-in-the-middle injecting error response in response to StartTLS command
> or man-in-the-middle stripping StartTLS command.
> 
> 

[[Dhruv Dhody]] Updated to include - 

   PCEPS implementations that continue to accept connections without TLS
   are susceptible to downgrade attacks as described in [RFC7457].  An
   attacker could attempt to remove the use of StartTLS message that
   request the use of TLS as it pass on the wire in clear, and further
   inject a PCErr message that suggest to attempt PCEP connection
   without TLS.

Regards,
Dhruv

> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce