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

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