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

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Aug 2017 03:05:27 -0700

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.

---

From: Dhruv Dhody <[email-masked]>
Date: Thu, 3 Aug 2017 13:36:19 +0000

Hi Alexey, 

Thanks for your comments, see inline...

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Alexey Melnikov
> Sent: 03 August 2017 15:35
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with
> DISCUSS and COMMENT)
> 
> 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       |
>                     |         \  ---------|
>                     |          \/         |
>                     |          /\         |
>                     |         /  -------->|
>                     |        /            |
>                     |<------              |
> 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.

> 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. 
 
> I am agreeing with Ekr's DISCUSS points. Some of mine might be just a
> different phrasing of his.
> 
[[Dhruv Dhody]] Ack. Updated. 

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

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 03 Aug 2017 14:53:50 +0100

Hi,

> In case certificate is not configured we would start TLS negotiation,

I think you should clarify this.

I have implemented StartTLS in both IMAP and LDAP and this is not
necessarily how it works there: before TLS negotiation starts it is
possible for the server end to reject negotiation in cleartext.

>    layer that the TLS connection has ended.

Hmm, I am not sure this will ever work. I know that implementations of
TLS in other protocols I worked on can't read any cleartext TCP data
after TLS has failed.

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 4 Aug 2017 18:41:27 +0000

Hi Alexey, 

> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: 03 August 2017 19:24
> To: Dhruv Dhody <[email-masked]>; The IESG <[email-masked]>
> Subject: Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15:
> (with DISCUSS and COMMENT)
> 
> Hi,
> 
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15:
> > > (with DISCUSS and COMMENT)
> > >
> > > 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       |
> > >                     |         \  ---------|
> > >                     |          \/         |
> > >                     |          /\         |
> > >                     |         /  -------->|
> > >                     |        /            |
> > >                     |<------              |
> > > 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]] Error can be added here, More on this, see reply below.  

> > > (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.
> > >
> Hmm, I am not sure this will ever work. I know that implementations of TLS
> in other protocols I worked on can't read any cleartext TCP data after TLS
> has failed.
> 
[[Dhruv Dhody]] One way to resolve this issue would be we move these errors from after TLS negotiation to before it, so that they become the response to StartTLS as suggested by your previous comment. 
We would not be sending error in clear text in case of TLS negotiation failure. 

So basically the change would look something like -  

OLD: 
   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:

   o  3 (not without TLS) if it is not willing to exchange PCEP messages
      without the solicited TLS connection, and it MUST close the TCP
      session.

   o  4 (ok without TLS) if it is willing to exchange PCEP messages
      without the solicited TLS connection, and it MUST close the TCP
      session.  The receiver MAY choose to attempt to re-establish the
      PCEP session without TLS next.  The attempt to re-establish the
      PCEP session without TLS SHOULD be limited to only once.

NEW:
   If a PCEP speaker that is unwilling or unable to negotiate TLS
   receives a StartTLS messages, it MUST return a PCErr message (in
   clear) with Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure)
   and Error-value set to:

   o  3 (not without TLS) if it is not willing to exchange PCEP messages
      without the solicited TLS connection, and it MUST close the TCP
      session.

   o  4 (ok without TLS) if it is willing to exchange PCEP messages
      without the solicited TLS connection, and it MUST close the TCP
      session.  The receiver MAY choose to attempt to re-establish the
      PCEP session without TLS next.  The attempt to re-establish the
      PCEP session without TLS SHOULD be limited to only once.

   After the exchange of StartTLS messages, if the TLS negotiation fails
   for some reason (e.g. the required mechanisms for certificate
   revocation checking are not available), both peers SHOULD immediately
   close the connection.  Since the initiator has no way to know if the
   peer is willing to accept PCEP connection without TLS, based on the
   local policy, it MAY attempt to re-establish the PCEP session without
   TLS.  The attempt to re-establish the PCEP session without TLS SHOULD
   be limited to only once.
END

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 5 Aug 2017 10:28:10 -0700

On Fri, Aug 4, 2017 at 11:41 AM, Dhruv Dhody <[email-masked]> wrote:

> TLS
> [[Dhruv Dhody]] One way to resolve this issue would be we move these
> errors from after TLS negotiation to before it, so that they become the
> response to StartTLS as suggested by your previous comment.

This will technically work, but is there a reason you don't specify a
parameter to
STARTTLS which expresses your policy?

-Ekr

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

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 7 Aug 2017 14:41:30 +0000

Hi Eric,

From: Eric Rescorla [mailto:[email-masked]]
Sent: 05 August 2017 22:58
To: Dhruv Dhody <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)

On Fri, Aug 4, 2017 at 11:41 AM, Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alexey,

> From: Alexey Melnikov [mailto:[email-masked]<mailto:[email-masked]>]
> To: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> > > From: Pce [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alexey Melnikov
> > > To: The IESG <[email-masked]<mailto:[email-masked]>>
> > > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> > > [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

OLD:

NEW:

This will technically work, but is there a reason you don't specify a parameter to
STARTTLS which expresses your policy?

-Ekr
[[[Dhruv Dhody]]] It could be done that way as well, but at this late stage we should avoid making a change that would require adding a new PCEP object.
As there is no way to add this in current StartTLS message encoding.

Regards,
Dhruv

Regards,
Dhruv

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 7 Aug 2017 08:24:18 -0700

On Mon, Aug 7, 2017 at 7:41 AM, Dhruv Dhody <[email-masked]> wrote:

> Hi Eric,
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* 05 August 2017 22:58
> *To:* Dhruv Dhody <[email-masked]>
> *Cc:* Alexey Melnikov <[email-masked]>; The IESG <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
>
> *Subject:* Re: [Pce] Alexey Melnikov's Discuss on
> draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)
>
>
>
>
>
>
>
> *[[[Dhruv Dhody]]] It could be done that way as well, but at this late
> stage we should avoid making a change that would require adding a new PCEP
> object. *
>
> *As there is no way to add this in current StartTLS message encoding. *
>
>
>

This is still an I-D, right? Are there any fielded implementations?

-Ekr

> *Regards,*
> *Dhruv*
> 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
>
>

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 8 Aug 2017 11:01:33 +0000

Hi Eric,

From: Eric Rescorla [mailto:[email-masked]]
Sent: 07 August 2017 20:54
To: Dhruv Dhody <[email-masked]>
Cc: Alexey Melnikov <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Pce] Alexey Melnikov's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)

On Mon, Aug 7, 2017 at 7:41 AM, Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 05 August 2017 22:58
To: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Cc: Alexey Melnikov <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

OLD:

NEW:

-Ekr

-Ekr

[[Dhruv Dhody]] There are implementations, not sure if they qualify as “fielded”.

Do you feel strongly about making the change?

Regards,
Dhruv

Regards,
Dhruv

Regards,
Dhruv

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Aug 2017 05:48:19 -0700

On Tue, Aug 8, 2017 at 4:01 AM, Dhruv Dhody <[email-masked]> wrote:

> *Sent:* 07 August 2017 20:54
> *Cc:* Alexey Melnikov <[email-masked]>;
> [email-masked]; [email-masked]; The IESG <[email-masked]>;
> [email-masked]; [email-masked]
>
> *[[Dhruv Dhody]] There are implementations, not sure if they qualify as
> “fielded”. *
>
>
>
> *Do you feel strongly about making the change?      *
>
>
It seems like it would clean up a number of confusing issues in your draft,
so I'd like to understand why the WG didn't do it.

-Ekr

*Regards,*

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 8 Aug 2017 13:40:33 +0000

Hi Eric,

Sent: 08 August 2017 18:18

On Tue, Aug 8, 2017 at 4:01 AM, Dhruv Dhody <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 07 August 2017 20:54
To: Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Cc: Alexey Melnikov <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

OLD:

NEW:

-Ekr

-Ekr

It seems like it would clean up a number of confusing issues in your draft, so I'd like to understand why the WG didn't do it.

-Ekr

[[[Dhruv Dhody]]] Well to be frank, since it was not proposed, WG did not consider it :)

As an author, while referencing StartTLS work in other protocols we did not see such a consideration either, and we ended up with the PCEP error mechanism to convey the information.

While the requested change may simplify a few things, but it would also require adding a new section for a new PCEP object - StartTLS object (as unfortunately there is no way to carry the information in the current message/objects).  As an editor I am shying away from making a change if the benefit is not big (maybe my biased view) but as an AD if you feel this is required, we would make the change.

Thanks for your continued discussion.

Regards,
Dhruv

Regards,
Dhruv

Regards,
Dhruv

Regards,
Dhruv