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

[Mick Seaman <[e-mail]>]

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