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

[Ben Campbell <[e-mail]>]

Hi, also inline:

Thanks!

Ben.


> On Aug 4, 2017, at 1:40 PM, Dhruv Dhody <[e-mail]> wrote:
> 
> 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. 

Okay, good enough.


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

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?

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

Okay.

> 
> Regards,
> Dhruv
> 
>> […]
>> Thanks!
>> 
>> Ben.