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