Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT)
Mick Seaman <mickseaman@sbcglobal.net> Tue, 27 October 2015 16:45 UTC
Return-Path: <mickseaman@sbcglobal.net>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C901AC3FC for <pals@ietfa.amsl.com>; Tue, 27 Oct 2015 09:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
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 tgQu8LD1VedE for <pals@ietfa.amsl.com>; Tue, 27 Oct 2015 09:45:45 -0700 (PDT)
Received: from nm18-vm3.access.bullet.mail.gq1.yahoo.com (nm18-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.76]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F3491AC3FE for <pals@ietf.org>; Tue, 27 Oct 2015 09:45:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s2048; t=1445964342; bh=yjKiMJGHKMYqzZV0oSqxvhef/aIjX7NzvkjcdLwv+jg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=qZa0vrM8x0EuMYgvaM2pId+DJrjoj6VR0b5diDD0fIa/IEOGTaAmKzfyuRLz/OVQTvQoYzJnaKEY+DY/pLQcKb6T86qzUWNREvJxUJ/hoREJ4dydcgOVbas3myPMJM2tPcwfsMCw8jW63oQiCpJI2HDGi+BW66cwZYOKL0IoiXMqQQnmsiLxLNO+j1mzEP8V1TmI3K/1MC4pN16nTZgRZ3ZhX0URD730Z5xZqYPhh2eJ+AmqkIqicrS4FPFBj5VYy15TOp9TpgZFY8jyz4BLin77kDiqr7a8HgQVfaDNoMmEOH2ekLJ3H0mnzp1BScma6xKWFTD/MX9FKlPJlXmI9g==
Received: from [216.39.60.166] by nm18.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 16:45:42 -0000
Received: from [67.195.22.116] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 16:45:42 -0000
Received: from [127.0.0.1] by smtp111.sbc.mail.gq1.yahoo.com with NNFMP; 27 Oct 2015 16:45:42 -0000
X-Yahoo-Newman-Id: 311299.39427.bm@smtp111.sbc.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 7RRh2LkVM1kctYbAYrBikyT8uI6Iv8c3DR.Wgi_hzG6hTP6 YTsu9GEp74RtEW1akqf6I3SR50uxxExvnSScDjx2lUo4mvHhJ83ueoKhqzgg lJTyuHYCgBzgZRAvxjaI__k4b5s3HnDdhU3hlFGTKdc6IWdUXReoZXQjQjzV YQlr2SgblZTwDAwe1jdbtaQprJXY04mlryt0YEU_Vnh48LHRaBcsb5urJVss 9MZatcWDS1EaB6xLAe7UNKOBUKCLGlNE2SCQydHAv277Lt6ShlXRQMxumSgh s6MQq.tSZPFEQDnAcWj907eARc7oi9f68EmjNcpFH1XezOYACsAorFTgtn6T 3D.0P.Eo4hlERHKGodbVn23_2274NuY5PwYQxHUmH5DKOUtJ_A2C9CdnHMFl 1bqhYxzsRUBkEZKB3AoPCeQW89luZh1WxrCIJtxYq4xVLm2o8UaWL3xSBmDJ 4ioWasCdFrUEQtNQACMTvqjNl5JQFeoNyru.fcb0.X8DfyvyxffAzgANFXOk 6O29kTPbWZzdVQY0a6mK3opCHronNuuACdG386LSXoY9y5rf_ckYBlO8-
X-Yahoo-SMTP: AR5_vwuswBBBxttajAdmA6MrHv2fOmL0PL2m9ko1TKipiHmVNQ--
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Andrew G. Malis" <agmalis@gmail.com>
References: <20150930131025.18397.72483.idtracker@ietfa.amsl.com> <4552F0907735844E9204A62BBDD325E78720B6E3@nkgeml512-mbx.china.huawei.com> <56179249.6040108@cs.tcd.ie> <4552F0907735844E9204A62BBDD325E78720BCF6@nkgeml512-mbx.china.huawei.com> <4552F0907735844E9204A62BBDD325E78720FDC7@nkgeml512-mbx.china.huawei.com> <562F9204.5000303@cs.tcd.ie> <CAA=duU1e4hnr=D6ptCHNQHBmELYvodwXEL326hcYrXAmhKB-TQ@mail.gmail.com> <562FA4EC.3060501@sbcglobal.net> <562FA672.2060501@cs.tcd.ie>
From: Mick Seaman <mickseaman@sbcglobal.net>
Message-ID: <562FAA35.50705@sbcglobal.net>
Date: Tue, 27 Oct 2015 09:45:41 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <562FA672.2060501@cs.tcd.ie>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/pals/g7bLwkpD8BZadonAnsE23auJhBo>
Cc: Mingui Zhang <zhangmingui@huawei.com>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, The IESG <iesg@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT)
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2015 16:45:47 -0000
Stephen, Understood re your comment. I think the length change itself is a small probability, since the 16 octets currently used are not oversized with respect to the other fields that accompany it (so no pressure to make it smaller), while I see no push to lower collision probability-we are already in overkill territory - in 802.1Q this hash is protecting against configuration mistakes not against the chance of two random data sets being the same. Mick On 10/27/2015 9:29 AM, Stephen Farrell wrote: > Just to be clear, my (non blocking) comment wasn't about > security but just about use of a fixed width field when > the underlying IEEE spec could change to use of a different > sized value. > > S. > > On 27/10/15 16:23, Mick Seaman wrote: >> I (personal opinion) agree with Andy with regard to has function change >> probability. The use of HMAC-MD5 in 802.1Q is as a hash/digest of data >> to confirm (to an acceptable level of probability that the input data >> that two parties hold is the same, without any view as to the presence >> of malicious parties - security is handled quite separately from this). >> To be honest in retrospect we might just as well have used a CRC: >> security functions aren't magic dust. It's a common misconception that a >> hashing function that has desirable security properties (an attacker >> don't know how to change hash if data is changed, doesn't know how to >> change data to match a different hash value) necessarily has better >> hash properties in the sense it distributes the results of input data >> more evenly over the set of output hash data values. I have no reason to >> suppose that SHA-256 would be 'better'/significantly different in terms >> of the use of HMAC-MD5 in 802.1Q-2014. >> >> Mick Seaman >> >> On 10/27/2015 8:41 AM, Andrew G. Malis wrote: >>> Stephen, >>> >>> As WG co-chair, I view this as a low-probability event that can be >>> fixed by a revision to the RFC if it becomes necessary. >>> >>> Thanks, >>> Andy >>> >>> On Tue, Oct 27, 2015 at 11:02 AM, Stephen Farrell >>> <stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>> wrote: >>> >>> >>> Hi, >>> >>> Sorry for the very slow response. >>> >>> On 16/10/15 02:26, Mingui Zhang wrote: >>> > Hi Stephen, >>> > >>> > We haven't heard from you. Could you confirm whether the >>> explanation is acceptable? >>> >>> I guess its acceptable, but maybe brittle, if the IEEE folks >>> revise their stuff to use a different hash function. From their >>> point of view that's a much smaller change than changing the >>> size of MAC addresses. I'd say best would be if we did not >>> have a fixed length, but rather said the length depends on >>> the hash function being used. (I forget if that means you'd >>> need a length field or algorithm identifier in your protocol.) >>> >>> S. >>> >>> >>> >>> > >>> > Thanks, >>> > Mingui >>> > >>> >> -----Original Message----- >>> >> From: Pals [mailto:pals-bounces@ietf.org >>> <mailto:pals-bounces@ietf.org>] On Behalf Of Mingui Zhang >>> >> Sent: Saturday, October 10, 2015 9:32 AM >>> >> To: Stephen Farrell; The IESG >>> >> Cc: pals-chairs@ietf.org <mailto:pals-chairs@ietf.org>; >>> agmalis@gmail.com <mailto:agmalis@gmail.com>; pals@ietf.org >>> <mailto:pals@ietf.org> >>> >> Subject: Re: [Pals] Stephen Farrell's No Objection on >>> draft-ietf-pwe3-iccp-stp-04: >>> >> (with COMMENT) >>> >> >>> >> Hi Stephen, >>> >> >>> >> Yes, it assumes a certainly length. >>> >> I think this issue is similar as the EUI-64 issue: currently, >>> the document >>> >> assumes a traditional 48-bit MAC addresses are used, which is >>> in consistence >>> >> with RFC 7275. >>> >> >>> >> When I compared 802.1q-2005 and 802.1q-2014. I found all >>> references related >>> >> to 802.1q in the document are not changed. If such kind of >>> changes do happen >>> >> in the future, they could be and should be handled in the next >>> protocol version >>> >> of the STP-ICCP application, I think. >>> >> >>> >> Does it make sense? >>> >> >>> >> Thanks, >>> >> Mingui >>> >> >>> >>> -----Original Message----- >>> >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie >>> <mailto:stephen.farrell@cs.tcd.ie>] >>> >>> Sent: Friday, October 09, 2015 6:09 PM >>> >>> To: Mingui Zhang; The IESG >>> >>> Cc: pals-chairs@ietf.org <mailto:pals-chairs@ietf.org>; >>> agmalis@gmail.com <mailto:agmalis@gmail.com>; pals@ietf.org >>> <mailto:pals@ietf.org> >>> >>> Subject: Re: [Pals] Stephen Farrell's No Objection on >>> >> draft-ietf-pwe3-iccp-stp-04: >>> >>> (with COMMENT) >>> >>> >>> >>> >>> >>> >>> >>> On 09/10/15 03:54, Mingui Zhang wrote: >>> >>>> Hi Stephen, >>> >>>> >>> >>>> 802.1q uses hmac-md5. This still holds in the latest version of >>> >>>> 802.1q. >>> >>>> >>> >>>> I agree that sha256 could be used to enhance the security. >>> However, >>> >>>> I think that kind of enhancement is out the scope of this >>> document >>> >>>> and should be discussed in 802.1q. >>> >>> >>> >>> Of course. But if they do that, and make a change what is the >>> impact >>> >>> here is my question. (I didn't re-read the doc, but was this >>> one where >>> >>> it assumes a certainly length or something?) >>> >>> >>> >>> S >>> >>> >>> >>>> >>> >>>> Thanks, Mingui >>> >>>> >>> >>>>> -----Original Message----- From: Pals >>> >>>>> [mailto:pals-bounces@ietf.org >>> <mailto:pals-bounces@ietf.org>] On Behalf Of Stephen Farrell Sent: >>> >>>>> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc: >>> >>>>> pals-chairs@ietf.org <mailto:pals-chairs@ietf.org>; >>> agmalis@gmail.com <mailto:agmalis@gmail.com>; pals@ietf.org >>> <mailto:pals@ietf.org> Subject: >>> >>>>> [Pals] Stephen Farrell's No Objection on >>> >>>>> draft-ietf-pwe3-iccp-stp-04: (with COMMENT) >>> >>>>> >>> >>>>> Stephen Farrell has entered the following ballot position for >>> >>>>> draft-ietf-pwe3-iccp-stp-04: No Objection >>> >>>>> >>> >>>>> 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-pwe3-iccp-stp/ >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> ------------------------------------------------------------------- >>> >>>>> -- >>> >>>>> - >>> >>>>> >>> >>>>> >>> >>> COMMENT: >>> >>>>> >>> ------------------------------------------------------------------- >>> >>>>> -- >>> >>>>> - >>> >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> >>> - 3.3.5: is that a hard-coded sha1 or md5? if so, why is that >>> ok? what >>> >>> if 802.1q >>> >>>>> is fixed/improved e.g. to use sha256? >>> >>>>> >>> >>>>> >>> >>>>> _______________________________________________ Pals mailing >>> list >>> >>>>> Pals@ietf.org <mailto:Pals@ietf.org> >>> https://www.ietf.org/mailman/listinfo/pals >>> >> _______________________________________________ >>> >> Pals mailing list >>> >> Pals@ietf.org <mailto:Pals@ietf.org> >>> >> https://www.ietf.org/mailman/listinfo/pals >>> > >>> >>> >>> >>> >>> _______________________________________________ >>> Pals mailing list >>> Pals@ietf.org >>> https://www.ietf.org/mailman/listinfo/pals >>
- [Pals] Stephen Farrell's No Objection on draft-ie… Stephen Farrell
- Re: [Pals] Stephen Farrell's No Objection on draf… Mingui Zhang
- Re: [Pals] Stephen Farrell's No Objection on draf… Stephen Farrell
- Re: [Pals] Stephen Farrell's No Objection on draf… Mingui Zhang
- Re: [Pals] Stephen Farrell's No Objection on draf… Mingui Zhang
- Re: [Pals] Stephen Farrell's No Objection on draf… Stephen Farrell
- Re: [Pals] Stephen Farrell's No Objection on draf… Andrew G. Malis
- Re: [Pals] Stephen Farrell's No Objection on draf… Mick Seaman
- Re: [Pals] Stephen Farrell's No Objection on draf… Stephen Farrell
- Re: [Pals] Stephen Farrell's No Objection on draf… Mick Seaman