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

From: Ben Campbell <[email-masked]>
Date: Wed, 02 Aug 2017 15:49:12 -0700

Ben Campbell 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:
----------------------------------------------------------------------

-3.4, step 2: "Peer validation always SHOULD include a check on whether
   the locally configured expected DNS name or IP address of
   the peer that is contacted matches its presented
   certificate."

Why is that not a MUST? As it is, this need to at least discuss the risks
involved if you don't check the identity of the peer cert (here or in the
security considerations.)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive:

- I share Warren's question about why you chose STARTTLS over a dedicated port,
especially since the 2nd to last paragraph in 3.2 goes out of its way to
mention that. What were the tradeoffs involved that made adding the additional
protocol machinery more attractive than allocating a port number?

- 3.2: "Implementations MUST support SHA-256 as defined by [SHS] as
          the hash algorithm for the fingerprint."
Do you really intend "MUST support" (meaning you have to be able to handle
sha-256, but could allow other hashes) vs "MUST use"?

- 3.5: "Implementations
   that want to support a wide variety of trust models SHOULD expose as
   many details of the presented certificate to the administrator as possible
   so that the trust model can be implemented by the administrator."
"as much as possible" is pretty vague for the a 2119 SHOULD. Since the
following sentences also include a SHOULD along with considerably more detail,
I suggest dropping the SHOULD in this sentence, and leaving the one in the
following sentence.

- 3.6: Is the exponential backoff requirement part of the procedures in 5440?
The wording suggests that it is not. If so, it needs elaboration here.

Editorial:

- 3.2, paragraph 8: s/"... PCE MUST responds with..."/ "...PCE MUST respond
with..."

- 3.4 : "Negotiation of mutual authentication is REQUIRED."
Does that mean that the peers must elect to use mutual authentication, or that
if they want to use it, they must agree to do so? (The pattern persists
throughout the section, but the meaning seems more obvious for some of the
others.)

-3.5, 2nd to last paragraph: Please don't use 2119 keywords to describe
pre-existing or external requirements. They should be reserved for the
authoritative specification of a given requirement.

-5, 2nd paragraph: The first sentence does not make sense.

---

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

Hi Ben, 

Thanks for your review. See inline..

> -----Original Message-----
> From: Pce [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: 03 August 2017 04:19
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15: (with
> DISCUSS and COMMENT)
> 
[[Dhruv Dhody]] Reworded to say - 

          +  Implementations MUST follow the rules and guidelines for
             peer validation as defined in [RFC6125].  If an expected
             DNS name or IP address for the peer is configured, then the
             implementations MUST check them against the values in the
             presented certificate.
> - I share Warren's question about why you chose STARTTLS over a dedicated
> port, especially since the 2nd to last paragraph in 3.2 goes out of its
> way to mention that. What were the tradeoffs involved that made adding the
> additional protocol machinery more attractive than allocating a port
> number?
> 
[[Dhruv Dhody]] I have added this text - 

   This document uses the standard StartTLS procedure in PCEP, instead
   of using a different port for the secured session.  This is done to
   avoid requesting allocation of another port number for the PCEPS.
   The StartTLS procedure makes more efficient use of scarce port
   numbers and allow simpler configuration of PCEP.

> sha-256, but could allow other hashes) vs "MUST use"?
[[Dhruv Dhody]] Yes, additional hash algorithm MAY also be supported/used.

> following sentences also include a SHOULD along with considerably more
> detail, I suggest dropping the SHOULD in this sentence, and leaving the
> one in the following sentence.
> 
[[Dhruv Dhody]] Ack. 

> The wording suggests that it is not. If so, it needs elaboration here.
[[Dhruv Dhody]] It is part of RFC5440, text updated to - 

   The initiator SHOULD follow the procedure listed in [RFC5440] to
   retry session setup as per the exponential back-off session
   establishment retry procedure.

> Editorial:
> 
> - 3.2, paragraph 8: s/"... PCE MUST responds with..."/ "...PCE MUST
> respond with..."
> 
[[Dhruv Dhody]] Ack

> Does that mean that the peers must elect to use mutual authentication, or
> that if they want to use it, they must agree to do so? (The pattern
> persists throughout the section, but the meaning seems more obvious for
> some of the
> others.)
> 
[[Dhruv Dhody]] I am also not sure, this was added keeping RFC6614 as our reference. 
Since TLS supports multiple authentication mode, this might be a say mutual as well as server-only authentication should be supported. But not sure about the word negotiation here. I think we can remove this statement, will do so once you confirm. 

> authoritative specification of a given requirement.
[[Dhruv Dhody]] Ack. Updated. 

> -5, 2nd paragraph: The first sentence does not make sense.
[[Dhruv Dhody]] Ack. Updated.

Regards,
Dhruv

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

---

From: Ben Campbell <[email-masked]>
Date: Thu, 3 Aug 2017 10:26:44 -0500

Thanks, please also see inline. I will remove sections that do not seem to need further comment.

> On Aug 3, 2017, at 8:35 AM, Dhruv Dhody <[email-masked]> wrote:
> 
> Hi Ben, 
> 

[…]

>             implementations MUST check them against the values in the

Thanks, that would resolve my DISCUSS position.

>   numbers and allow simpler configuration of PCEP.

That’s helpful, but it only shows the benefits side of the tradeoff. I assume people thought the additional protocol complexity was a reasonable cost to bear?

> [[Dhruv Dhody]] Yes, additional hash algorithm MAY also be supported/used.

Is there an expectation people will use multiple hash algorithms side-by-side? Or is this for purposes of hash agility?

> Since TLS supports multiple authentication mode, this might be a say mutual as well as server-only authentication should be supported. But not sure about the word negotiation here. I think we can remove this statement, will do so once you confirm. he 

The important thing is that the intent of the WG is clear. Do you mean to say that the working group intended to allow both server-only and mutual authentication, or do you mean to say the working group did not think about it?

[…]
Thanks!

Ben.

---

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

Hi Ben, 

Please see inline...

> From: Ben Campbell [mailto:[email-masked]]
> Sent: 03 August 2017 20:57
> To: Dhruv Dhody <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; draft-ietf-pce-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15:
> (with DISCUSS and COMMENT)

 (snip)

> >> - I share Warren's question about why you chose STARTTLS over a
> >> dedicated port, especially since the 2nd to last paragraph in 3.2
> >> goes out of its way to mention that. What were the tradeoffs involved
> >> that made adding the additional protocol machinery more attractive
> >> than allocating a port number?
> >>
> That’s helpful, but it only shows the benefits side of the tradeoff. I
> assume people thought the additional protocol complexity was a reasonable
> cost to bear?
> 
[[Dhruv Dhody]] There was substantive discussion on the mailing list regarding this, as our original proposal requested a new port and we were advised to use StartTLS instead after discussion with transport/security folks. See https://www.ietf.org/mail-archive/web/pce/current/msg03540.html. 

> >> Do you really intend "MUST support" (meaning you have to be able to
> >> handle sha-256, but could allow other hashes) vs "MUST use"?
> >>
> Is there an expectation people will use multiple hash algorithms side-by-
> side? Or is this for purposes of hash agility?
> 
[[Dhruv Dhody]] SHA-256 is the current mandatory hash, others might become usable and useful as the technology evolves. Do you have any suggested change in mind? 
I see RFC6614 use similar language "Implementations MUST support SHA-1 as the hash algorithm for the fingerprint...."

(snip)

> >> Does that mean that the peers must elect to use mutual
> >> authentication, or that if they want to use it, they must agree to do
> >> so? (The pattern persists throughout the section, but the meaning
> >> seems more obvious for some of the
> >> others.)
> >>
> > Since TLS supports multiple authentication mode, this might be a say
> > mutual as well as server-only authentication should be supported. But
> > not sure about the word negotiation here. I think we can remove this
> > statement, will do so once you confirm. he
> 
> The important thing is that the intent of the WG is clear. Do you mean to
> say that the working group intended to allow both server-only and mutual
> authentication, or do you mean to say the working group did not think
> about it?
> 
[[Dhruv Dhody]] On further discussion with my co-authors, we feel we should remove the statement. The previous statement in the draft about mutual authentication is enough and mutual authentication should be the standard. 

Regards,
Dhruv

---

From: Ben Campbell <[email-masked]>
Date: Mon, 7 Aug 2017 16:38:04 -0500

Hi, also inline:

Thanks!

Ben.

> On Aug 4, 2017, at 1:40 PM, Dhruv Dhody <[email-masked]> wrote:
> 
> Hi Ben, 
> 
> Please see inline...
> 

Okay, good enough.

> I see RFC6614 use similar language "Implementations MUST support SHA-1 as the hash algorithm for the fingerprint…."

I guess my question is whether the intent is for implementations to be able to pick any hash they want, as long as SHA-256 is an option, or do you expect everyone to use SHA-256 unless that is replaced at some point due to security concerns. If the former, “MUST support…” makes sense. If the latter, something like “MUST  (or SHOULD) use…” with a caveat that future specs might update this if SHA-256 is proven unsafe at some point in the future.

My real concern here is interoperability—if an implementation chooses a hash other than SHA-256, how does the peer know what hash to use?

> [[Dhruv Dhody]] On further discussion with my co-authors, we feel we should remove the statement. The previous statement in the draft about mutual authentication is enough and mutual authentication…

Okay.

---

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

Hi Ben, 

> Sent: 08 August 2017 03:08
> The IESG <[email-masked]>; [email-masked]
(snip)
> >> Is there an expectation people will use multiple hash algorithms
> >> side-by- side? Or is this for purposes of hash agility?
> >>
> > [[Dhruv Dhody]] SHA-256 is the current mandatory hash, others might
> become usable and useful as the technology evolves. Do you have any
> suggested change in mind?
> > I see RFC6614 use similar language "Implementations MUST support SHA-1
> as the hash algorithm for the fingerprint…."
> 
> I guess my question is whether the intent is for implementations to be
> able to pick any hash they want, as long as SHA-256 is an option, or do
> you expect everyone to use SHA-256 unless that is replaced at some point
> due to security concerns. If the former, “MUST support…” makes sense. If
> the latter, something like “MUST  (or SHOULD) use…” with a caveat that
> future specs might update this if SHA-256 is proven unsafe at some point
> in the future.
> 
[[Dhruv Dhody]] I was incorrect in my reply before, it is the latter, as we also have this text in the security considerations that explains this - 

   When using certificate fingerprints to identify PCEPS peers, any two
   certificates that produce the same hash value will be considered the
   same peer.  Therefore, it is important to make sure that the hash
   function used is cryptographically uncompromised, so that attackers
   are very unlikely to be able to produce a hash collision with a
   certificate of their choice.  This document mandates support for
   SHA-256 as defined by [SHS], but a later revision may demand support
   for stronger functions if suitable attacks on it are known.

So a future revision would update the Hash function to be used. I will update the text as you suggest. 

> My real concern here is interoperability—if an implementation chooses a
> hash other than SHA-256, how does the peer know what hash to use?
> 
[[Dhruv Dhody]] This is a local property and does not need to be exchanged. The peer provides the certificate, based on local hash function in use, the hash of DER encoded certificate octets is created and compared to a local fingerprint configured. 

Regards,
Dhruv

---

From: Ben Campbell <[email-masked]>
Date: Tue, 8 Aug 2017 09:56:27 -0500

> On Aug 8, 2017, at 6:48 AM, Dhruv Dhody <[email-masked]> wrote:
> 
> Hi Ben, 
> 

Ah, that makes sense, thanks!  (And in any case, the question is moot based on the rest of your response.)

I can’t remember if I mentioned it, but I have cleared my DISCUSS position and entered a YES.

Thanks!

Ben.