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

Dhruv Dhody <dhruv.dhody@huawei.com> Tue, 08 August 2017 11:48 UTC

Return-Path: <dhruv.dhody@huawei.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A341E1321E7; Tue, 8 Aug 2017 04:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5VrQ_FqLffX; Tue, 8 Aug 2017 04:48:30 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42EF61321D8; Tue, 8 Aug 2017 04:48:29 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSY70090; Tue, 08 Aug 2017 11:48:27 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 8 Aug 2017 12:48:25 +0100
Received: from BLREML501-MBB.china.huawei.com ([10.20.5.200]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0301.000; Tue, 8 Aug 2017 17:18:16 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: Ben Campbell <ben@nostrum.com>
CC: "cmargaria@juniper.net" <cmargaria@juniper.net>, "draft-ietf-pce-pceps@ietf.org" <draft-ietf-pce-pceps@ietf.org>, "pce@ietf.org" <pce@ietf.org>, The IESG <iesg@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
Thread-Topic: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)
Thread-Index: AQHTC+GeKMusC97gUUWSIE/gjuf8xaJyV6tggAAOMQCAAVcKwIAFWgkAgAFDX+A=
Date: Tue, 08 Aug 2017 11:48:16 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8CB99C90@blreml501-mbb>
References: <150171415228.5759.6042228213633458080.idtracker@ietfa.amsl.com> <23CE718903A838468A8B325B80962F9B8CB98665@blreml501-mbb> <E0C89DDB-F358-427F-92FC-F33C35012A0B@nostrum.com> <23CE718903A838468A8B325B80962F9B8CB98DB2@blreml501-mbb> <47928D93-5F37-40A0-A502-F55DC3A2F92A@nostrum.com>
In-Reply-To: <47928D93-5F37-40A0-A502-F55DC3A2F92A@nostrum.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.149.39]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0206.5989A50B.0101, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 8e93995a2716fdc84cdb4652f3e38ce5
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/66Rc1gZj1n3G1YnQ-nVmY5PKBSw>
Subject: Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15: (with DISCUSS and COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Aug 2017 11:48:32 -0000

Hi Ben, 

> -----Original Message-----
> From: Ben Campbell [mailto:ben@nostrum.com]
> Sent: 08 August 2017 03:08
> To: Dhruv Dhody <dhruv.dhody@huawei.com>
> Cc: cmargaria@juniper.net; draft-ietf-pce-pceps@ietf.org; pce@ietf.org;
> The IESG <iesg@ietf.org>; pce-chairs@ietf.org
> Subject: Re: [Pce] Ben Campbell's Discuss on draft-ietf-pce-pceps-15:
> (with DISCUSS and COMMENT)
> 
(snip)
> >>
> >>>
> >>>> - 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.
> 
[[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. 

> >
> > (snip)
> >

Regards,
Dhruv