Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04: (with COMMENT)

[Stephen Farrell <[e-mail]>]

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
>> <[e-mail] <mailto:[e-mail]>> 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:[e-mail]
>>     <mailto:[e-mail]>] On Behalf Of Mingui Zhang
>>     >> Sent: Saturday, October 10, 2015 9:32 AM
>>     >> To: Stephen Farrell; The IESG
>>     >> Cc: [e-mail] <mailto:[e-mail]>;
>>     [e-mail] <mailto:[e-mail]>; [e-mail]
>>     <mailto:[e-mail]>
>>     >> 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:[e-mail]
>>     <mailto:[e-mail]>]
>>     >>> Sent: Friday, October 09, 2015 6:09 PM
>>     >>> To: Mingui Zhang; The IESG
>>     >>> Cc: [e-mail] <mailto:[e-mail]>;
>>     [e-mail] <mailto:[e-mail]>; [e-mail]
>>     <mailto:[e-mail]>
>>     >>> 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:[e-mail]
>>     <mailto:[e-mail]>] On Behalf Of Stephen Farrell Sent:
>>     >>>>> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc:
>>     >>>>> [e-mail] <mailto:[e-mail]>;
>>     [e-mail] <mailto:[e-mail]>; [e-mail]
>>     <mailto:[e-mail]> 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
>>     >>>>> [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/pals
>>     >> _______________________________________________
>>     >> Pals mailing list
>>     >> [e-mail] <mailto:[e-mail]>
>>     >> https://www.ietf.org/mailman/listinfo/pals
>>     >
>>
>>
>>
>>
>> _______________________________________________
>> Pals mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pals
> 
>