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

From: Mingui Zhang <[email-masked]>
Date: Fri, 9 Oct 2015 02:54:48 +0000

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.

Thanks,
Mingui

> -----Original Message-----
> From: Pals [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Wednesday, September 30, 2015 9:10 PM
> To: The IESG
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pals

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 9 Oct 2015 11:09:13 +0100

On 09/10/15 03:54, Mingui Zhang wrote:
> 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:[email-masked]] On Behalf Of Stephen Farrell Sent:
>> Wednesday, September 30, 2015 9:10 PM To: The IESG Cc:
>> [email-masked]; [email-masked]; [email-masked] Subject:
>> [Pals] Stephen Farrell's No Objection on
>> draft-ietf-pwe3-iccp-stp-04: (with COMMENT)
>> 
>> 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/
>> 
>> 
>> 
- 3.3.5: is that a hard-coded sha1 or md5? if so, why is that ok? what
if 802.1q
>> _______________________________________________ Pals mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/pals

---

From: Mingui Zhang <[email-masked]>
Date: Sat, 10 Oct 2015 01:32:00 +0000

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

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Friday, October 09, 2015 6:09 PM
> To: Mingui Zhang; The IESG
> Subject: Re: [Pals] Stephen Farrell's No Objection on draft-ietf-pwe3-iccp-stp-04:
> (with COMMENT)
> 
> 
> 
> 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:[email-masked]]
> >> On Behalf Of Stephen Farrell Sent:
> >> 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

---

From: Mingui Zhang <[email-masked]>
Date: Fri, 16 Oct 2015 01:26:39 +0000

Hi Stephen,

We haven't heard from you. Could you confirm whether the explanation is acceptable?

Thanks,
Mingui

> From: Pals [mailto:[email-masked]] On Behalf Of Mingui Zhang
> Sent: Saturday, October 10, 2015 9:32 AM
> To: Stephen Farrell; The IESG
> 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
> 
> > > 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.
> >
> > >> -------------------------------------------------------------------
> > >> --
> > >> -
> > >>
> > >>
> > COMMENT:
> > >> -------------------------------------------------------------------
> > >> --
> > >> -
> > >>
> > >>
> > >>
> > >>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Oct 2015 15:02:28 +0000

Hi,

Sorry for the very slow response.

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Oct 2015 11:41:56 -0400

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 <[email-masked]
> wrote:

---

From: Mick Seaman <[email-masked]>
Date: Tue, 27 Oct 2015 09:23:08 -0700

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 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     Hi,
>
>     >> From: Pals [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Mingui Zhang
>     >> Cc: [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     >>> From: Stephen Farrell [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     >>> Cc: [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     >>>>> [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Stephen Farrell Sent:
>     >>>>> [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]> Subject:
>     >>>>> [email-masked] <mailto:[email-masked]>
>     >> [email-masked] <mailto:[email-masked]>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 27 Oct 2015 16:29:38 +0000

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

---

From: Mick Seaman <[email-masked]>
Date: Tue, 27 Oct 2015 09:45:41 -0700

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