|
Hi Dan,
Thank you for your comments on the resolution. I’m working on the MDR report as Co-Editor and I’m open to any resolution agreed by the group. The email was also sent to 11ai reflector encouraging
the feedback from others.
Up to now, we received more than X thousand comments. I believe this clause is not the only one that received comments in more than one ballot.
More than X thousand comments? Wow, how exhausting. I feel like I have resolved N thousand myself!
You're right that this clause is not "the only one that received comments in more than one ballot" but
the thing is, I never said it was. You will notice that what I said was, "the current fragile specification that
seems to generate comments every single ballot cycle." Note how I am saying that it receives comments
every ballot cycle but no where do I say that it is "the only one that received comments" every ballot
cycle.
There are many sections that receive comments, and some of them receive comments every
ballot. The AEAD section is one of those. What we need to do is modify the text such that it does
not receive any more comments. I have text that will resolve that but when I last presented it, I
was shot down by your co-workers.
As you and George proposed the framework for security, I thought the AEAD counter was also proposed by you two. Now it seems this came from others.
I'm not sure what George contributed but there are large sections of 11ai text that are mine, yes
that is true. While the text I contributed to the 11ai draft may have been substantial, it did not
include the current AEAD mode. Since I did not generate the current AEAD text and I have
actively worked to replace it, I don't feel any ownership of that text.
For the specific motion you mentioned, I don't quite remember exactly. But if you check the 11ai contribution list on mentor, several others (at least four) of my coworkers
contributed actively on draft and comment resolutions. Since 11ai letter ballot, as Co-Editor, I spend almost all of my time in IEEE802.11 meeting, and even more time after each meeting on improving 11ai draft, not on proposing new concepts, or just show of
hands. Of course, our Editor Lee spent much more time than me.
Gee, that's too bad that you don't remember. If I was you I would want to forget that too.
I'm pretty sure that the half dozen people that arrived in the 11ai session that voted down my
proposal and promptly left the room have never resolved any of our comments and I'm very
confident that their entire contribution to 11ai is nil. But if you know "several others (at least four)
of [your] coworkers [who] contributed actively on [the] draft" then you should have several others,
at least four, that you can get to resolve this comment. Ask them. I can't wait to see their proposals
on how to address this comment.
Dan.
Best Regards,
Ping
More problems associated with the AEAD counters…. My solution is to get rid of the
need to have counters. We should replace the current fragile specification that seems
to generate comments every single ballot cycle with one that has provable security, is
robust, and does not lose all security if counters happen to repeat.
If you remember, the last time I tried to fix this problem and wanted to make a motion
you asked to wait until the next session so you could read the submission more thoroughly.
I agreed and at the next session there were a half dozen of your co-workers (who I had
never seen in a TGai meeting before) in the back of the room and they all voted down
my proposal (and as soon as the vote was over they left the room).
Perhaps you could ask some of your coworkers to fix it since they feel so strongly
about it the way it is done now.
Hi Dan, George,
Could you help to provide the resolution text for the comment below in MDR?
P128L28 the little-endianness of 802.11 disagrees with ‘first bit is 1’
The discussion from Editor’s meeting is that “Dangerous as specified – should be described as an integer field of 13 octets width. The special value should be 2**((13*8)-1).”
The related text in D4.0 is cited below:
FILS requires an additional element: a 13 octet AEAD counter to be part of the newly created PTKSA. The STA shall set the
AEAD counter to 13 octets of zero and the AP shall set the first octet to the value 128 and the remaining octets to zero (i.e. the first bit of the AEAD counter is 1 and the rest of the bits in the counter are 0). To allow for proper processing, each side
shall include the AEAD counter of the other as a peer’s AEAD counter (see 11.11.2.6 (AEAD cipher mode for FILS)).
Best Regards,
Ping Fang
_______________________________________________________________________________
IF YOU WISH to be Removed from this reflector, PLEASE DO NOT send your request to this
CLOSED reflector. We use this valuable tool to communicate on the issues at hand.
SELF SERVICE OPTION:
Point your Browser to - http://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGAI and
then amend your subscription on the form provided. If you require removal from the reflector
press the LEAVE button.
Further information can be found at: http://www.ieee802.org/11/Email_Subscribe.html
_______________________________________________________________________________
|