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

[Alexey Melnikov <[e-mail]>]

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.

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.

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.


----------------------------------------------------------------------
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?

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)?

   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.