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

[Dhruv Dhody <[e-mail]>]

Hi Ben, 

Please see inline...

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

 (snip)

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


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

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

> […]
> Thanks!
> 
> Ben.