Subject: [Drip] Comments on DRIP Authentication Formats

From: "Friis, Soren" <[email-masked]>
Date: Thu, 10 Dec 2020 12:36:04 +0000

Hi

Please find below some comments on the document DRIP Authentication Formats (draft-wiethuechter-drip-auth-05). And I support adopting this document.

First a somewhat unrelated question: I have understood that there is also work ongoing by the IEEE and also by the ICAO related to UAS security. Are you aware/involved in these separate activities? It would maybe make sense to align with them as early as possible, in order to avoid inventing conflicting standards and to ensure easier adoptation by getting input from as many relevant parties as possible during the specification work?

3.2.  ASTM Authentication Message:
•       Auth Header. I assume that the value 0xD mentioned, refers to the ASTM Auth Type? Chapter 4 seems to indicate so.
      Instead of picking a value from the private use range, I suggest that e.g. the value 0x5 is used and you then agree with ASTM that the next version of the standard will reserve that value for DRIP authentication.

4.  DRIP Authentication Framing Formats:
•       About the max page count. I personally don’t see any problem in increasing that in the next version of the ASTM standard. However, the maximum number of messages that can fit for Bluetooth Extended Advertising is 9. With 9 messages, the total size is 1 + 5 + 3 + 9* ODID_MESSAGE_SIZE = 234 bytes. Adding a 10th message would bring that to 259 bytes.
      (See Figure 9 in the ASTM spec: Length + type + 16-bit UUID + code + counter + ProtoVersion:MessageType + SingleMessageSize + MsgPackSize + 9*ODID_Messages_encoded).
•       As a side-note, the two Bluetooth chipsets I have worked with, impose some additional size limits for the extended advertising data in their Bluetooth SW stack. The TI CC2640 seems to have a limit somewhere around 241 bytes and the nRF52840 a limit somewhere around 245 bytes. When I increase the buffer size larger than those values, the extended advertising messages on the S8 Coded PHY are never visible on the receiver phone. The transmitter SW stacks must be filling some of the fields in the extended header (Bluetooth Core spec 5.1, vol 6, B, 2.3.4 fig 2.14), which reduces the possible size of the advertising data. This still allows 9 messages, fortunately.
•       I tried to read through the WiFi-NaN spec to see if there are similar restrictions in there but didn’t find any. However, I don’t have any practical experience with implementing a WiFi-NaN transmitter. It is possible that some restriction applies.

4.1 and 4.1.2 DRIP Authentication Data:
•       This is listed as 223 bytes but even assuming 10 authentication messages, wouldn’t this be only 200 bytes since the last page is reserved for FEC data? Or is it implicitly assumed that if FEC is not used, then that last page is calculated also as DRIP Authentication Data? Maybe that could then be stated explicitly?
•       The value should be updated to reflect that only max 9 authentication messages can be sent for BT Extended Advertising (i.e. either 177 or 200 bytes depending on FEC usage).
Side-note: For Legacy Advertising, this could be larger, since the individual authentication messages are anyway split up into separate transmission pings and the full 10 authentication messages (or more even) could be transmitted.
•       My experience with Legacy Advertisement seems to indicate that the loss rate of those will in many situations be too high to reliably transmit many authentication messages belonging to the same set. You might have to add an additional indicator/counter/setID that would allow repeated transmission of the whole set and allow the receiver to piece the entire set together from parts of those repeated transmissions (maybe some of the reserved bits in the DRIP AuthType?). This is something that won’t really become clear until you implement it and try it in different real-life situations.
•       DRIP AuthType: “5 Wrapped ASTM Messages” will not be possible. See comment below for 5.1.2.

4.1.3 FEC:
•       If it is mandated (instead of recommended) that FEC is used for Legacy Advertising and not for Extended Advertising/WiFi NaN, then the max size of DRIP authentication data could always be 200 bytes. 10 pages for Legacy (with FEC) and 9 pages for EA (without FEC).
•       I didn’t really understand this “(other than the ASTM Header and Auth Header which is known)”. This first page is the only one that cannot be reconstructed, since you need to know the total amount of data pages, in order to check that you have received all the other ones and to do the recovery calculation (?).
•       Why does the XOR operation need to exclude the first two bytes? Shouldn’t that be only the first byte (to ignore the Auth Header)?

4.2. DRIP Wrapper Frame:
•       Is this used only with DRIP AuthType 0x00 – 0x0F? Should that be mentioned explicitly?

4.3. DRIP Attestation Frame:
•       The description text and the figure are mixing the word Attestation and Assertion. Please use only one term.
•       The max length would be 132 bytes (and not 155 bytes).
•       Which DRIP AuthType specifies this Attestation Frame? 0x10 – 0x1F? Could it be mentioned explicitly?

5.1.2. 5 Wrapped ASTM Messages:
•       This will not be possible since the wrapper frame only has 116 bytes payload. I.e. max 4 messages will fit.

5.2.1. Hash Algorithm:
•       What is MAC? The MAC address of the transmitter? When receiving WiFi NaN messages on Android, the Android API does not give you the MAC address of the originating transmitter (for Bluetooth you get it though). You only get a PeerHandle<https://developer.android.com/reference/android/net/wifi/aware/DiscoverySessionCallback>, which has some kind of pseudo integer hashCode<https://developer.android.com/reference/android/net/wifi/aware/PeerHandle> number, and that might even change over time.
      Is it possible for the receiver to verify the HASH code without knowing the transmitter MAC?

5.2.2. Pseudo-Blockchain Hashes:
•       What DRIP AuthType specify the use of this?

5.2.3. 8 Byte:
•       Chapter 4.1 specify the DRIP AuthType to be 0x86 or 0x06 (not 0x87 or 0x07).

5.2.4. 4 Byte:
•       Chapter 4.1 specify the DRIP AuthType to be 0x87 or 0x07 (not 0x86 or 0x06).

5.3.1 Assertion:
•       I didn’t look in details through [identity-claims] but it looked like there were things in there a lot longer than the max 132 bytes allowed? Maybe I misunderstood.

6.1. 0 Wrapped ASTM Messages:
•       Should this be between Chapter 5.1 and 5.1.1, just to have a logical order when reading the document?
•       Maybe some more description is needed to explain how exactly this is done?

6.2. DRIP Certificate:
•       Couldn’t this be deleted if the “w/FEC” part from the Figure 10 description is also deleted? Is there a need to have separate chapters for BT4 and BT5?

   Søren Friis

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

---

From: Robert Moskowitz <[email-masked]>
Date: Thu, 10 Dec 2020 08:32:21 -0500

Quick note on "MAC".

Here we have a well known acronym collision that in IEEE 802 has been 
'addressed'.

In cryptography, "MAC" is Message Authentication Check.
In most ISO layer 2 standards (like IEEE 802 and derivatives like 
Bluetooth) "MAC" is Media Access Control (address).

Thus in 802.1AE we use "MIC" Message Integrity Check which has been 
adopted throughout IEE 802 standards.  But IETF has not adopted that 
acronym, thus the collision.

Therefore:

In IETF documentation ASSuME "MAC" = Message Authentication Check
In IEEE documentation ASSuME "MAC" = Media Access Control
and "MIC" = Message Integrity Check (i.e. equiv to Message 
Authentication Check)

Obviously, here in DRIP, we really need to follow the IEEE collision 
resolution and use MIC for the cryptographic function and MAC for the 
Layer 2 addressing.

Stu can you add these definitions into the Req doc?  Adam, do you agree 
that we should follow this convention in our drafts?

On 12/10/20 7:36 AM, Friis, Soren wrote:
> Hi
> Please find below some comments on the document DRIP Authentication 
> Formats (draft-wiethuechter-drip-auth-05). And I support adopting this 
> document.
> First a somewhat unrelated question: I have understood that there is 
> also work ongoing by the IEEE and also by the ICAO related to UAS 
> security. Are you aware/involved in these separate activities? It 
> would maybe make sense to align with them as early as possible, in 
> order to avoid inventing conflicting standards and to ensure easier 
> adoptation by getting input from as many relevant parties as possible 
> during the specification work?
>   * Auth Header. I assume that the value 0xD mentioned, refers to the
>     ASTM Auth Type? Chapter 4 seems to indicate so.
>     Instead of picking a value from the private use range, I suggest
>     that e.g. the value 0x5 is used and you then agree with ASTM that
>     the next version of the standard will reserve that value for DRIP
>     authentication.
>
>   * About the max page count. I personally don’t see any problem in
>     increasing that in the next version of the ASTM standard. However,
>     the maximum number of messages that can fit for Bluetooth Extended
>     Advertising is 9. With 9 messages, the total size is 1 + 5 + 3 +
>     9* ODID_MESSAGE_SIZE = 234 bytes. Adding a 10^th message would
>     bring that to 259 bytes.
>     (See Figure 9 in the ASTM spec: Length + type + 16-bit UUID + code
>     + counter + ProtoVersion:MessageType + SingleMessageSize +
>     MsgPackSize + 9*ODID_Messages_encoded).
>   * As a side-note, the two Bluetooth chipsets I have worked with,
>     impose some additional size limits for the extended advertising
>     data in their Bluetooth SW stack. The TI CC2640 seems to have a
>     limit somewhere around 241 bytes and the nRF52840 a limit
>     somewhere around 245 bytes. When I increase the buffer size larger
>     than those values, the extended advertising messages on the S8
>     Coded PHY are never visible on the receiver phone. The transmitter
>     SW stacks must be filling some of the fields in the extended
>     header (Bluetooth Core spec 5.1, vol 6, B, 2.3.4 fig 2.14), which
>     reduces the possible size of the advertising data. This still
>     allows 9 messages, fortunately.
>   * I tried to read through the WiFi-NaN spec to see if there are
>     similar restrictions in there but didn’t find any. However, I
>     don’t have any practical experience with implementing a WiFi-NaN
>     transmitter. It is possible that some restriction applies.
>
>   * This is listed as 223 bytes but even assuming 10 authentication
>     messages, wouldn’t this be only 200 bytes since the last page is
>     reserved for FEC data? Or is it implicitly assumed that if FEC is
>     not used, then that last page is calculated also as DRIP
>     Authentication Data? Maybe that could then be stated explicitly?
>   * The value should be updated to reflect that only max 9
>     authentication messages can be sent for BT Extended Advertising
>     (i.e. either 177 or 200 bytes depending on FEC usage).
>     Side-note: For Legacy Advertising, this could be larger, since the
>     individual authentication messages are anyway split up into
>     separate transmission pings and the full 10 authentication
>     messages (or more even) could be transmitted.
>   * My experience with Legacy Advertisement seems to indicate that the
>     loss rate of those will in many situations be too high to reliably
>     transmit many authentication messages belonging to the same set.
>     You might have to add an additional indicator/counter/setID that
>     would allow repeated transmission of the whole set and allow the
>     receiver to piece the entire set together from parts of those
>     repeated transmissions (maybe some of the reserved bits in the
>     DRIP AuthType?). This is something that won’t really become clear
>     until you implement it and try it in different real-life situations.
>   * DRIP AuthType: “5 Wrapped ASTM Messages” will not be possible. See
>     comment below for 5.1.2.
>
> 4.1.3 FEC:
>
>   * If it is mandated (instead of recommended) that FEC is used for
>     Legacy Advertising and not for Extended Advertising/WiFi NaN, then
>     the max size of DRIP authentication data could always be 200
>     bytes. 10 pages for Legacy (with FEC) and 9 pages for EA (without
>     FEC).
>   * I didn’t really understand this “(other than the ASTM Header and
>     Auth Header which is known)”. This first page is the only one that
>     cannot be reconstructed, since you need to know the total amount
>     of data pages, in order to check that you have received all the
>     other ones and to do the recovery calculation (?).
>   * Why does the XOR operation need to exclude the first two bytes?
>     Shouldn’t that be only the first byte (to ignore the Auth Header)?
>
> 4.2. DRIP Wrapper Frame:
>
>   * Is this used only with DRIP AuthType 0x00 – 0x0F? Should that be
>     mentioned explicitly?
>
>   * The description text and the figure are mixing the word
>     Attestation and Assertion. Please use only one term.
>   * The max length would be 132 bytes (and not 155 bytes).
>   * Which DRIP AuthType specifies this Attestation Frame? 0x10 – 0x1F?
>     Could it be mentioned explicitly?
>
>   * This will not be possible since the wrapper frame only has 116
>     bytes payload. I.e. max 4 messages will fit.
>
> 5.2.1. Hash Algorithm:
>
>   * What is MAC? The MAC address of the transmitter? When receiving
>     WiFi NaN messages on Android, the Android API does not give you
>     the MAC address of the originating transmitter (for Bluetooth you
>     get it though). _You only get a PeerHandle_
>     <https://developer.android.com/reference/android/net/wifi/aware/DiscoverySessionCallback>,
>     which has some kind of pseudo integer _hashCode_
>     <https://developer.android.com/reference/android/net/wifi/aware/PeerHandle>
>     number, and that might even change over time.
>   * What DRIP AuthType specify the use of this?
>
> 5.2.3. 8 Byte:
>
>   * Chapter 4.1 specify the DRIP AuthType to be 0x86 or 0x06 (not 0x87
>     or 0x07).
>
> 5.2.4. 4 Byte:
>
>   * Chapter 4.1 specify the DRIP AuthType to be 0x87 or 0x07 (not 0x86
>     or 0x06).
>
> 5.3.1 Assertion:
>
>   * I didn’t look in details through [identity-claims] but it looked
>     like there were things in there a lot longer than the max 132
>     bytes allowed? Maybe I misunderstood.
>
>   * Should this be between Chapter 5.1 and 5.1.1, just to have a
>     logical order when reading the document?
>   * Maybe some more description is needed to explain how exactly this
>     is done?
>
> 6.2. DRIP Certificate:
>
>   * Couldn’t this be deleted if the “w/FEC” part from the Figure 10
>     description is also deleted? Is there a need to have separate
>     chapters for BT4 and BT5?
>
> Søren Friis
>

---

From: Adam Wiethuechter <[email-masked]>
Date: Thu, 10 Dec 2020 21:54:41 +0000

Soren,

I think you are the first to fully read the document and give such detailed comments - so thanks very much!

My comments are inline below.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC

________________________________
From: Tm-rid <[email-masked]> on behalf of Friis, Soren <[email-masked]>
Sent: Thursday, December 10, 2020 7:36 AM
To: Drone Remote ID Protocol Discussion List <[email-masked]>
Subject: [Drip] Comments on DRIP Authentication Formats

Hi

<atw>
I am aware of the ICAO work (as both Stu and Bob are present there as well). We have been working together to try to keep things in alignment with them.
</atw>

  *   Auth Header. I assume that the value 0xD mentioned, refers to the ASTM Auth Type? Chapter 4 seems to indicate so.
Instead of picking a value from the private use range, I suggest that e.g. the value 0x5 is used and you then agree with ASTM that the next version of the standard will reserve that value for DRIP authentication.

<atw>
I choose 0xD first because DRIP and D (weak but amusing I know), second because I felt being in the private range at least before adopting would avoid any collisions. The intention is to move to 0x5 or whatever ASTM mandates. This was covered in Section 7 ASTM Considerations, but not giving an explicit number.
</atw>

  *   About the max page count. I personally don’t see any problem in increasing that in the next version of the ASTM standard. However, the maximum number of messages that can fit for Bluetooth Extended Advertising is 9. With 9 messages, the total size is 1 + 5 + 3 + 9* ODID_MESSAGE_SIZE = 234 bytes. Adding a 10th message would bring that to 259 bytes.
(See Figure 9 in the ASTM spec: Length + type + 16-bit UUID + code + counter + ProtoVersion:MessageType + SingleMessageSize + MsgPackSize + 9*ODID_Messages_encoded).
  *   As a side-note, the two Bluetooth chipsets I have worked with, impose some additional size limits for the extended advertising data in their Bluetooth SW stack. The TI CC2640 seems to have a limit somewhere around 241 bytes and the nRF52840 a limit somewhere around 245 bytes. When I increase the buffer size larger than those values, the extended advertising messages on the S8 Coded PHY are never visible on the receiver phone. The transmitter SW stacks must be filling some of the fields in the extended header (Bluetooth Core spec 5.1, vol 6, B, 2.3.4 fig 2.14), which reduces the possible size of the advertising data. This still allows 9 messages, fortunately.
  *   I tried to read through the WiFi-NaN spec to see if there are similar restrictions in there but didn’t find any. However, I don’t have any practical experience with implementing a WiFi-NaN transmitter. It is possible that some restriction applies.

<atw>
This lines up a bit with what I have experiences working with some Laird modules (they use the nRF52840). I couldn't fit the 10 pages and dropped to 9 for the extended payload. I figured it was an implementation restriction...very insightful and changes a lot of text/sizes in the document going forward.
</atw>

  *   This is listed as 223 bytes but even assuming 10 authentication messages, wouldn’t this be only 200 bytes since the last page is reserved for FEC data? Or is it implicitly assumed that if FEC is not used, then that last page is calculated also as DRIP Authentication Data? Maybe that could then be stated explicitly?

<atw>
You are correct that it was implicit. This is 223 bytes when FEC is not used. 200 when FEC is used. I will add explicit text here for clarity.
</atw>

  *   The value should be updated to reflect that only max 9 authentication messages can be sent for BT Extended Advertising (i.e. either 177 or 200 bytes depending on FEC usage).
Side-note: For Legacy Advertising, this could be larger, since the individual authentication messages are anyway split up into separate transmission pings and the full 10 authentication messages (or more even) could be transmitted.

<atw>
First, I agree the text should change to have the upper be 9 pages for now. However, you bring up an interesting point for Legacy Adverts that really there is no limit to the page number. This would require a text change in ASTM as the way I read the spec was that 5 was the max regardless of Legacy or Extended Advertisements. Perhaps this was the intention of the ASTM specification to begin with?
</atw>

  *   My experience with Legacy Advertisement seems to indicate that the loss rate of those will in many situations be too high to reliably transmit many authentication messages belonging to the same set. You might have to add an additional indicator/counter/setID that would allow repeated transmission of the whole set and allow the receiver to piece the entire set together from parts of those repeated transmissions (maybe some of the reserved bits in the DRIP AuthType?). This is something that won’t really become clear until you implement it and try it in different real-life situations.

<atw>
This is something we have not considered and it an interesting idea. If the above comment on unlimited page numbers for Legacy holds true then more pages could be allocated to FEC data (perhaps a Reed Solomon code instead of XOR?), thus allowing more pages to be lost and be reconstructed - addressing your loss rate comment.

We do have a lot of extra bits in the DRIP Header to play with - so your idea is intriguing, and I may play with it to see what we experience and come up with.
</atw>

  *   DRIP AuthType: “5 Wrapped ASTM Messages” will not be possible. See comment below for 5.1.2.

4.1.3 FEC:

  *   If it is mandated (instead of recommended) that FEC is used for Legacy Advertising and not for Extended Advertising/WiFi NaN, then the max size of DRIP authentication data could always be 200 bytes. 10 pages for Legacy (with FEC) and 9 pages for EA (without FEC).
  *   I didn’t really understand this “(other than the ASTM Header and Auth Header which is known)”. This first page is the only one that cannot be reconstructed, since you need to know the total amount of data pages, in order to check that you have received all the other ones and to do the recovery calculation (?).

  *   Why does the XOR operation need to exclude the first two bytes? Shouldn’t that be only the first byte (to ignore the Auth Header)?

<atw>
First good catch on your 3rd point. You are correct only the Auth Header byte (which is the Auth Type:Page Number) needs to be excluded. Technically there is another byte that is excluded (the one before it which is Protocol Version:Message Type) but that is not in the figures.

Regarding your 2nd point if you did miss Page 0 you could attempt a reconstruction with XOR on the subsequent pages you received - it does involve some detective work, however. A simple implementation could very easily just ignore any Auths without a Page 0. The way to know if you are in a new set of Auth pages is using the AD Counter - which is incremented with each new Auth Message. So, if I received a subset of pages 1 through n all with AD Counter set to 4 then I received a Page 0 with AD Counter of 5 then I know that I am in a new Auth set so I received what I got with the previous. I can perform an XOR using the received pages and check if the Page Count field of Page 0 lines up with what I received. If not, I throw it all away and move on - otherwise I can attempt to decode as chances are high that the reconstruction was a success.

This all works as in Android I noticed that the Bluetooth stack when asked for the payload gives me something like this: 1E16FAFF0D0640022ECEB2198E2AF2D201000AC008E4070000000000000000 (AD Counter = 06 in this example). Does this apply to Wifi NaN too, I do not know.

As of writing this email, last night I finally got my implementation working with FEC - both a transmitter and receiver over Bluetooth 4. Soon I will begin some bench testing to see how well it helps with page loss.
</atw>

4.2. DRIP Wrapper Frame:

  *   Is this used only with DRIP AuthType 0x00 – 0x0F? Should that be mentioned explicitly?

<atw>
Now yes. However, it is just a framing format that would be reused elsewhere - such as in the Reserved or Experimental sections of the DRIP AuthType. This also applies to the Attestation Frame.
</atw>

  *   The description text and the figure are mixing the word Attestation and Assertion. Please use only one term.

<atw>
It should be Attestation. I am terrible when I copy and paste. You should see my code 😜
</atw>

  *   The max length would be 132 bytes (and not 155 bytes).
  *   Which DRIP AuthType specifies this Attestation Frame? 0x10 – 0x1F? Could it be mentioned explicitly?

<atw>
Just like the Wrapper Frame comment above yes.
</atw>

  *   This will not be possible since the wrapper frame only has 116 bytes payload. I.e. max 4 messages will fit.

<atw>
Yes, for Bluetooth 5, but for Bluetooth 4 as you stated before we may not be limited by page numbers....
</atw>

5.2.1. Hash Algorithm:

  *   What is MAC? The MAC address of the transmitter? When receiving WiFi NaN messages on Android, the Android API does not give you the MAC address of the originating transmitter (for Bluetooth you get it though). You only get a PeerHandle<https://developer.android.com/reference/android/net/wifi/aware/DiscoverySessionCallback>, which has some kind of pseudo integer hashCode<https://developer.android.com/reference/android/net/wifi/aware/PeerHandle> number, and that might even change over time.
Is it possible for the receiver to verify the HASH code without knowing the transmitter MAC?

<atw>
Bob has answered this question in his own reply email. It is supposed to be MAC Address and I noticed this error earlier last week. I will reconfirm with Bob and change the text.
</atw>

<atw>
This is something that only appears in the Manifest formats that Section 5.2 discuss. This whole section needs a bit better formatting and organization.
</atw>

5.2.3. 8 Byte:

  *   Chapter 4.1 specify the DRIP AuthType to be 0x86 or 0x06 (not 0x87 or 0x07).

5.2.4. 4 Byte:

  *   Chapter 4.1 specify the DRIP AuthType to be 0x87 or 0x07 (not 0x86 or 0x06).

<atw>
Simple fixes if the 5 Wrapped Message format is indeed impossible - but again I argue for its use in Bluetooth 4 to emulate a Message Pack that is fully signed.
</atw>

5.3.1 Assertion:

  *   I didn’t look in details through [identity-claims] but it looked like there were things in there a lot longer than the max 132 bytes allowed? Maybe I misunderstood.

<atw>
This is a section that needs to be fixed and clarified. The only identity-claims format to be used here is from Section 3.2.2 Attestation: X on Y (Offline Form).
The rest of that draft is supporting certificates and attestations for the UAS RID ecosystem.
</atw>

  *   Should this be between Chapter 5.1 and 5.1.1, just to have a logical order when reading the document?
  *   Maybe some more description is needed to explain how exactly this is done?

<atw>
Fair assessment and totally doable.

The reason this is in the Bluetooth 5.X Formats section is as it should only be used in the Message Pack. It is effectively the DRIP version if the ASTM Message Pack Signature.
</atw>

6.2. DRIP Certificate:

  *   Couldn’t this be deleted if the “w/FEC” part from the Figure 10 description is also deleted? Is there a need to have separate chapters for BT4 and BT5?

<atw>
I toyed with removing redundant sections like this but was unsure so left it.

As for seperate chapters on BT4 and BT5 it seemed logical to separate them. However, I did do a disclaimer of sorts near the beginning of a section stating that under Bluetooth 5 FEC is not recommended - that was enough, and all these could just be their own chapter sections.
</atw>

Søren Friis

---

From: "Friis, Soren" <[email-masked]>
Date: Mon, 14 Dec 2020 08:40:11 +0000

Hi

You are welcome. A few more comments added below, marked with <sf>.

               Søren

From: Adam Wiethuechter <[email-masked]>
Sent: Thursday, December 10, 2020 11:55 PM
To: Friis, Soren <[email-masked]>; Drone Remote ID Protocol Discussion List <[email-masked]>
Subject: Re: Comments on DRIP Authentication Formats

Soren,

--------
73,
Adam T. Wiethuechter

________________________________
From: Tm-rid <[email-masked]<mailto:[email-masked]>> on behalf of Friis, Soren <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, December 10, 2020 7:36 AM
To: Drone Remote ID Protocol Discussion List <[email-masked]<mailto:[email-masked]>>
Subject: [Drip] Comments on DRIP Authentication Formats

Hi

Please find below some comments on the document DRIP Authentication Formats (draft-wiethuechter-drip-auth-05<https://datatracker.ietf.org/doc/draft-wiethuechter-drip-auth/?include_text=1>). And I support adopting this document.

<atw>

3.2.  ASTM Authentication Message:
·        Auth Header. I assume that the value 0xD mentioned, refers to the ASTM Auth Type? Chapter 4 seems to indicate so.
Instead of picking a value from the private use range, I suggest that e.g. the value 0x5 is used and you then agree with ASTM that the next version of the standard will reserve that value for DRIP authentication.
<atw>
I choose 0xD first because DRIP and D (weak but amusing I know), second because I felt being in the private range at least before adopting would avoid any collisions. The intention is to move to 0x5 or whatever ASTM mandates. This was covered in Section 7 ASTM Considerations, but not giving an explicit number.
</atw>

4.  DRIP Authentication Framing Formats:
·        About the max page count. I personally don’t see any problem in increasing that in the next version of the ASTM standard. However, the maximum number of messages that can fit for Bluetooth Extended Advertising is 9. With 9 messages, the total size is 1 + 5 + 3 + 9* ODID_MESSAGE_SIZE = 234 bytes. Adding a 10th message would bring that to 259 bytes.
(See Figure 9 in the ASTM spec: Length + type + 16-bit UUID + code + counter + ProtoVersion:MessageType + SingleMessageSize + MsgPackSize + 9*ODID_Messages_encoded).
·        As a side-note, the two Bluetooth chipsets I have worked with, impose some additional size limits for the extended advertising data in their Bluetooth SW stack. The TI CC2640 seems to have a limit somewhere around 241 bytes and the nRF52840 a limit somewhere around 245 bytes. When I increase the buffer size larger than those values, the extended advertising messages on the S8 Coded PHY are never visible on the receiver phone. The transmitter SW stacks must be filling some of the fields in the extended header (Bluetooth Core spec 5.1, vol 6, B, 2.3.4 fig 2.14), which reduces the possible size of the advertising data. This still allows 9 messages, fortunately.
·        I tried to read through the WiFi-NaN spec to see if there are similar restrictions in there but didn’t find any. However, I don’t have any practical experience with implementing a WiFi-NaN transmitter. It is possible that some restriction applies.
<atw>
This lines up a bit with what I have experiences working with some Laird modules (they use the nRF52840). I couldn't fit the 10 pages and dropped to 9 for the extended payload. I figured it was an implementation restriction...very insightful and changes a lot of text/sizes in the document going forward.
</atw>
<sf>
It wasn’t until last week that I realized that it will never be possible to fit more than 9 messages for BT5. Some text in the ASTM standard should probably be added to clarify this. I have a personal list of things to look at when the discussion starts up again (next year?). I will add it there.
</sf>

4.1 and 4.1.2 DRIP Authentication Data:
·        This is listed as 223 bytes but even assuming 10 authentication messages, wouldn’t this be only 200 bytes since the last page is reserved for FEC data? Or is it implicitly assumed that if FEC is not used, then that last page is calculated also as DRIP Authentication Data? Maybe that could then be stated explicitly?
<atw>
You are correct that it was implicit. This is 223 bytes when FEC is not used. 200 when FEC is used. I will add explicit text here for clarity.
</atw>
·        The value should be updated to reflect that only max 9 authentication messages can be sent for BT Extended Advertising (i.e. either 177 or 200 bytes depending on FEC usage).
Side-note: For Legacy Advertising, this could be larger, since the individual authentication messages are anyway split up into separate transmission pings and the full 10 authentication messages (or more even) could be transmitted.
<atw>
First, I agree the text should change to have the upper be 9 pages for now. However, you bring up an interesting point for Legacy Adverts that really there is no limit to the page number. This would require a text change in ASTM as the way I read the spec was that 5 was the max regardless of Legacy or Extended Advertisements. Perhaps this was the intention of the ASTM specification to begin with?
</atw>
<sf>
The max of 5 was put in just because of the assumption that the other 5 messages would be the mandatory messages. Clearly that should change. However, it might be best to keep the ASTM standard limited to max 10, with the additional explanation that BT5 can only carry 9 and the 10th is only for FEC when using BT4. WiFi NaN could carry more than 9/10 but by limiting it, the same amount of data is possible on all three broadcast methods. This clearly needs discussion.
</sf>
·        My experience with Legacy Advertisement seems to indicate that the loss rate of those will in many situations be too high to reliably transmit many authentication messages belonging to the same set. You might have to add an additional indicator/counter/setID that would allow repeated transmission of the whole set and allow the receiver to piece the entire set together from parts of those repeated transmissions (maybe some of the reserved bits in the DRIP AuthType?). This is something that won’t really become clear until you implement it and try it in different real-life situations.
<atw>
This is something we have not considered and it an interesting idea. If the above comment on unlimited page numbers for Legacy holds true then more pages could be allocated to FEC data (perhaps a Reed Solomon code instead of XOR?), thus allowing more pages to be lost and be reconstructed - addressing your loss rate comment.

We do have a lot of extra bits in the DRIP Header to play with - so your idea is intriguing, and I may play with it to see what we experience and come up with.
</atw>
<sf>
See below regarding the AD Counter.
</sf>
·        DRIP AuthType: “5 Wrapped ASTM Messages” will not be possible. See comment below for 5.1.2.
4.1.3 FEC:
·        If it is mandated (instead of recommended) that FEC is used for Legacy Advertising and not for Extended Advertising/WiFi NaN, then the max size of DRIP authentication data could always be 200 bytes. 10 pages for Legacy (with FEC) and 9 pages for EA (without FEC).
·        I didn’t really understand this “(other than the ASTM Header and Auth Header which is known)”. This first page is the only one that cannot be reconstructed, since you need to know the total amount of data pages, in order to check that you have received all the other ones and to do the recovery calculation (?).
·        Why does the XOR operation need to exclude the first two bytes? Shouldn’t that be only the first byte (to ignore the Auth Header)?
<atw>
First good catch on your 3rd point. You are correct only the Auth Header byte (which is the Auth Type:Page Number) needs to be excluded. Technically there is another byte that is excluded (the one before it which is Protocol Version:Message Type) but that is not in the figures.

As of writing this email, last night I finally got my implementation working with FEC - both a transmitter and receiver over Bluetooth 4. Soon I will begin some bench testing to see how well it helps with page loss.
</atw>
<sf>
The Android WiFi NaN receiver does pick up the AD Counter.

However, it is somewhat unclear how to use that in the current ASTM spec. For BT4 and BT5, it is said to increase for each message type, for WiFi NaN it is said to increase for each message. Increasing it for each message type doesn’t quite work though, since for BT5 and WiFi NaN, the message pack is used, and the counter is associated with that. I.e. when sending a message pack, the same counter value is associated with all the messages of various types that are in the pack. Also, the spec doesn’t say what the receiver is supposed to do with this counter. The usage of the AD Counter would need to be clarified in the next version of the ASTM spec.

Now when thinking more carefully about all this, I realize that putting the set indicator in the DRIP Auth header won’t work, since it is only transmitted for page 0, and that page can get lost. Ideally, each single authentication message should have information about the total page numbers, the current page number and the set number (is there a better word for the set number?). This clearly needs some more thinking.
</sf>

4.2. DRIP Wrapper Frame:
·        Is this used only with DRIP AuthType 0x00 – 0x0F? Should that be mentioned explicitly?
<atw>
Now yes. However, it is just a framing format that would be reused elsewhere - such as in the Reserved or Experimental sections of the DRIP AuthType. This also applies to the Attestation Frame.
</atw>

4.3. DRIP Attestation Frame:
·        The description text and the figure are mixing the word Attestation and Assertion. Please use only one term.
<atw>
It should be Attestation. I am terrible when I copy and paste. You should see my code 😜
</atw>
·        The max length would be 132 bytes (and not 155 bytes).
·        Which DRIP AuthType specifies this Attestation Frame? 0x10 – 0x1F? Could it be mentioned explicitly?
<atw>
Just like the Wrapper Frame comment above yes.
</atw>

5.1.2. 5 Wrapped ASTM Messages:
·        This will not be possible since the wrapper frame only has 116 bytes payload. I.e. max 4 messages will fit.
<atw>
Yes, for Bluetooth 5, but for Bluetooth 4 as you stated before we may not be limited by page numbers....
</atw>

5.2.1. Hash Algorithm:
·        What is MAC? The MAC address of the transmitter? When receiving WiFi NaN messages on Android, the Android API does not give you the MAC address of the originating transmitter (for Bluetooth you get it though). You only get a PeerHandle<https://developer.android.com/reference/android/net/wifi/aware/DiscoverySessionCallback>, which has some kind of pseudo integer hashCode<https://developer.android.com/reference/android/net/wifi/aware/PeerHandle> number, and that might even change over time.
Is it possible for the receiver to verify the HASH code without knowing the transmitter MAC?
<atw>
Bob has answered this question in his own reply email. It is supposed to be MAC Address and I noticed this error earlier last week. I will reconfirm with Bob and change the text.
</atw>
<sf>
If MAC here really means Media Access Control address, then this is a problem, since it is not available to a WiFi NaN receiver. It will only be okay if the receiver can calculate whatever it needs to calculate without knowing the MAC address. (My knowledge of security and related algorithms is very limited).
</sf>

5.2.2. Pseudo-Blockchain Hashes:
·        What DRIP AuthType specify the use of this?
<atw>
This is something that only appears in the Manifest formats that Section 5.2 discuss. This whole section needs a bit better formatting and organization.
</atw>

5.2.3. 8 Byte:
·        Chapter 4.1 specify the DRIP AuthType to be 0x86 or 0x06 (not 0x87 or 0x07).
 5.2.4. 4 Byte:
·        Chapter 4.1 specify the DRIP AuthType to be 0x87 or 0x07 (not 0x86 or 0x06).
<atw>
Simple fixes if the 5 Wrapped Message format is indeed impossible - but again I argue for its use in Bluetooth 4 to emulate a Message Pack that is fully signed.
</atw>

5.3.1 Assertion:
·        I didn’t look in details through [identity-claims] but it looked like there were things in there a lot longer than the max 132 bytes allowed? Maybe I misunderstood.
<atw>
This is a section that needs to be fixed and clarified. The only identity-claims format to be used here is from Section 3.2.2 Attestation: X on Y (Offline Form).
The rest of that draft is supporting certificates and attestations for the UAS RID ecosystem.
</atw>

6.1. 0 Wrapped ASTM Messages:
·        Should this be between Chapter 5.1 and 5.1.1, just to have a logical order when reading the document?
·        Maybe some more description is needed to explain how exactly this is done?
<atw>
Fair assessment and totally doable.

6.2. DRIP Certificate:
·        Couldn’t this be deleted if the “w/FEC” part from the Figure 10 description is also deleted? Is there a need to have separate chapters for BT4 and BT5?
<atw>
I toyed with removing redundant sections like this but was unsure so left it.

As for seperate chapters on BT4 and BT5 it seemed logical to separate them. However, I did do a disclaimer of sorts near the beginning of a section stating that under Bluetooth 5 FEC is not recommended - that was enough, and all these could just be their own chapter sections. Either the DRIP Auth header is added to all pages or the recovery of page 0 is specified so it can be handled with the AD Counter?
</atw>

Søren Friis

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 14 Dec 2020 08:31:08 -0500

See below in the MAC discussion

On 12/14/20 3:40 AM, Friis, Soren wrote:
> *From:*Adam Wiethuechter <[email-masked]>
> *Sent:* Thursday, December 10, 2020 11:55 PM
> *To:* Friis, Soren <[email-masked]>; Drone Remote ID Protocol 
> Discussion List <[email-masked]>
> *Subject:* Re: Comments on DRIP Authentication Formats
>
> Soren,
>
> ------------------------------------------------------------------------
>
> *From:*Tm-rid <[email-masked] 
> <mailto:[email-masked]>> on behalf of Friis, Soren 
> <[email-masked] <mailto:[email-masked]>>
> *Sent:* Thursday, December 10, 2020 7:36 AM
> *To:* Drone Remote ID Protocol Discussion List <[email-masked] 
> <mailto:[email-masked]>>
> *Subject:* [Drip] Comments on DRIP Authentication Formats
>
> Hi
>
> Formats (draft-wiethuechter-drip-auth-05 
> <https://datatracker.ietf.org/doc/draft-wiethuechter-drip-auth/?include_text=1>). 
> And I support adopting this document.
>
> I am aware of the ICAO work (as both Stu and Bob are present there as 
> well). We have been working together to try to keep things in 
> alignment with them.
>
> </atw>
>
> ·Auth Header. I assume that the value 0xD mentioned, refers to the 
> Instead of picking a value from the private use range, I suggest that 
> e.g. the value 0x5 is used and you then agree with ASTM that the next 
> version of the standard will reserve that value for DRIP authentication.
>
> <atw>
>
> I choose 0xD first because DRIP and D (weak but amusing I know), 
> second because I felt being in the private range at least before 
> adopting would avoid any collisions. The intention is to move to 0x5 
> or whatever ASTM mandates. This was covered in Section 7 ASTM 
> Considerations, but not giving an explicit number.
>
> </atw>
>
> ·About the max page count. I personally don’t see any problem in 
> increasing that in the next version of the ASTM standard. However, the 
> maximum number of messages that can fit for Bluetooth Extended 
> Advertising is 9. With 9 messages, the total size is 1 + 5 + 3 + 9* 
> ODID_MESSAGE_SIZE = 234 bytes. Adding a 10^th message would bring that 
> to 259 bytes.
> (See Figure 9 in the ASTM spec: Length + type + 16-bit UUID + code + 
> counter + ProtoVersion:MessageType + SingleMessageSize + MsgPackSize + 
> 9*ODID_Messages_encoded).
>
> ·As a side-note, the two Bluetooth chipsets I have worked with, impose 
> some additional size limits for the extended advertising data in their 
> Bluetooth SW stack. The TI CC2640 seems to have a limit somewhere 
> around 241 bytes and the nRF52840 a limit somewhere around 245 bytes. 
> When I increase the buffer size larger than those values, the extended 
> advertising messages on the S8 Coded PHY are never visible on the 
> receiver phone. The transmitter SW stacks must be filling some of the 
> fields in the extended header (Bluetooth Core spec 5.1, vol 6, B, 
> 2.3.4 fig 2.14), which reduces the possible size of the advertising 
> data. This still allows 9 messages, fortunately.
>
> ·I tried to read through the WiFi-NaN spec to see if there are similar 
> restrictions in there but didn’t find any. However, I don’t have any 
> practical experience with implementing a WiFi-NaN transmitter. It is 
> possible that some restriction applies.
>
> <atw>
>
> This lines up a bit with what I have experiences working with some 
> Laird modules (they use the nRF52840). I couldn't fit the 10 pages and 
> dropped to 9 for the extended payload. I figured it was an 
> implementation restriction...very insightful and changes a lot of 
> text/sizes in the document going forward.
>
> </atw>
>
> <sf>
>
> It wasn’t until last week that I realized that it will never be 
> possible to fit more than 9 messages for BT5. Some text in the ASTM 
> standard should probably be added to clarify this. I have a personal 
> list of things to look at when the discussion starts up again (next 
> year?). I will add it there.
>
> </sf>
>
> ·This is listed as 223 bytes but even assuming 10 authentication 
> reserved for FEC data? Or is it implicitly assumed that if FEC is not 
> used, then that last page is calculated also as DRIP Authentication 
> Data? Maybe that could then be stated explicitly?
>
> <atw>
>
> You are correct that it was implicit. This is 223 bytes when FEC is 
> not used. 200 when FEC is used. I will add explicit text here for clarity.
>
> </atw>
>
> ·The value should be updated to reflect that only max 9 authentication 
> messages can be sent for BT Extended Advertising (i.e. either 177 or 
> 200 bytes depending on FEC usage).
> individual authentication messages are anyway split up into separate 
> transmission pings and the full 10 authentication messages (or more 
> even) could be transmitted.
>
> <atw>
>
> First, I agree the text should change to have the upper be 9 pages for 
> now. However, you bring up an interesting point for Legacy Adverts 
> that really there is no limit to the page number. This would require a 
> text change in ASTM as the way I read the spec was that 5 was the max 
> regardless of Legacy or Extended Advertisements. Perhaps this was the 
> intention of the ASTM specification to begin with?
>
> </atw>
>
> <sf>
>
> The max of 5 was put in just because of the assumption that the other 
> 5 messages would be the mandatory messages. Clearly that should 
> change. However, it might be best to keep the ASTM standard limited to 
> max 10, with the additional explanation that BT5 can only carry 9 and 
> the 10^th is only for FEC when using BT4. WiFi NaN could carry more 
> than 9/10 but by limiting it, the same amount of data is possible on 
> all three broadcast methods. This clearly needs discussion.
>
> </sf>
>
> ·My experience with Legacy Advertisement seems to indicate that the 
> transmit many authentication messages belonging to the same set. You 
> might have to add an additional indicator/counter/setID that would 
> allow repeated transmission of the whole set and allow the receiver to 
> piece the entire set together from parts of those repeated 
> transmissions (maybe some of the reserved bits in the DRIP AuthType?). 
> This is something that won’t really become clear until you implement 
> it and try it in different real-life situations.
>
> <atw>
>
> This is something we have not considered and it an interesting idea. 
> If the above comment on unlimited page numbers for Legacy holds true 
> then more pages could be allocated to FEC data (perhaps a Reed Solomon 
> code instead of XOR?), thus allowing more pages to be lost and be 
> reconstructed - addressing your loss rate comment.
>
> We do have a lot of extra bits in the DRIP Header to play with - so 
> your idea is intriguing, and I may play with it to see what we 
> experience and come up with.
>
> </atw>
>
> <sf>
>
> ·DRIP AuthType: “5 Wrapped ASTM Messages” will not be possible. See 
> comment below for 5.1.2.
>
> 4.1.3 FEC:
>
> ·If it is mandated (instead of recommended) that FEC is used for 
> Legacy Advertising and not for Extended Advertising/WiFi NaN, then the 
> max size of DRIP authentication data could always be 200 bytes. 10 
> pages for Legacy (with FEC) and 9 pages for EA (without FEC).
>
> ·I didn’t really understand this “(other than the ASTM Header and Auth 
> Header which is known)”. This first page is the only one that cannot 
> be reconstructed, since you need to know the total amount of data 
> pages, in order to check that you have received all the other ones and 
> to do the recovery calculation (?).
>
> ·Why does the XOR operation need to exclude the first two bytes? 
> First good catch on your 3rd point. You are correct only the Auth 
> Header byte (which is the Auth Type:Page Number) needs to be excluded. 
> Technically there is another byte that is excluded (the one before it 
> which is Protocol Version:Message Type) but that is not in the figures.
>
> Regarding your 2nd point if you did miss Page 0 you could attempt a 
> reconstruction with XOR on the subsequent pages you received - it does 
> involve some detective work, however. A simple implementation could 
> very easily just ignore any Auths without a Page 0. The way to know if 
> you are in a new set of Auth pages is using the AD Counter - which is 
> incremented with each new Auth Message. So, if I received a subset of 
> pages 1 through n all with AD Counter set to 4 then I received a Page 
> 0 with AD Counter of 5 then I know that I am in a new Auth set so I 
> received what I got with the previous. I can perform an XOR using the 
> received pages and check if the Page Count field of Page 0 lines up 
> with what I received. If not, I throw it all away and move on - 
> otherwise I can attempt to decode as chances are high that the 
> reconstruction was a success.
>
> This all works as in Android I noticed that the Bluetooth stack when 
> asked for the payload gives me something like this: 
> 1E16FAFF0D0640022ECEB2198E2AF2D201000AC008E4070000000000000000 (AD 
> Counter = 06 in this example). Does this apply to Wifi NaN too, I do 
> not know.
>
> As of writing this email, last night I finally got my implementation 
> working with FEC - both a transmitter and receiver over Bluetooth 4. 
> Soon I will begin some bench testing to see how well it helps with 
> page loss.
>
> </atw>
>
> <sf>
>
> However, it is somewhat unclear how to use that in the current ASTM 
> spec. For BT4 and BT5, it is said to increase for each message type, 
> for WiFi NaN it is said to increase for each message. Increasing it 
> for each message type doesn’t quite work though, since for BT5 and 
> WiFi NaN, the message pack is used, and the counter is associated with 
> that. I.e. when sending a message pack, the same counter value is 
> associated with all the messages of various types that are in the 
> pack. Also, the spec doesn’t say what the receiver is supposed to do 
> with this counter. The usage of the AD Counter would need to be 
> clarified in the next version of the ASTM spec.
>
> Now when thinking more carefully about all this, I realize that 
> putting the set indicator in the DRIP Auth header won’t work, since it 
> is only transmitted for page 0, and that page can get lost. Ideally, 
> each single authentication message should have information about the 
> total page numbers, the current page number and the set number (is 
> there a better word for the set number?). This clearly needs some more 
> thinking.
>
> </sf>
>
> 4.2. DRIP Wrapper Frame:
>
> ·Is this used only with DRIP AuthType 0x00 – 0x0F? Should that be 
> mentioned explicitly?
>
> <atw>
>
> Now yes. However, it is just a framing format that would be reused 
> elsewhere - such as in the Reserved or Experimental sections of the 
> DRIP AuthType. This also applies to the Attestation Frame.
>
> </atw>
>
> ·The description text and the figure are mixing the word Attestation 
> and Assertion. Please use only one term.
>
> <atw>
>
> ·The max length would be 132 bytes (and not 155 bytes).
>
> ·Which DRIP AuthType specifies this Attestation Frame? 0x10 – 0x1F? 
> ·This will not be possible since the wrapper frame only has 116 bytes 
> payload. I.e. max 4 messages will fit.
>
> <atw>
>
> ·What is MAC? The MAC address of the transmitter? When receiving WiFi 
> NaN messages on Android, the Android API does not give you the MAC 
> address of the originating transmitter (for Bluetooth you get it 
> though). You only get a PeerHandle 
> which has some kind of pseudo integer hashCode 
> Bob has answered this question in his own reply email. It is supposed 
> to be MAC Address and I noticed this error earlier last week. I will 
> reconfirm with Bob and change the text.
>
> </atw>
>
> <sf>
>
> If MAC here really means Media Access Control address, then this is a 
> problem, since it is not available to a WiFi NaN receiver. It will 
> only be okay if the receiver can calculate whatever it needs to 
> calculate without knowing the MAC address. (My knowledge of security 
> and related algorithms is very limited).
>
> </sf>
>

How is it that the WiFi NaN receiver does not get the sender's Media 
Access Control address?  this is counter to the 802.11 standards, and is 
probably a driver limitation?  Now NaN is not really owned by 802.11, 
but rather the WiFi Alliance.  I can ask some of my colleagues there for 
clarification (I stopped participating in WiFi Alliance, and pretty much 
802, when I was RIFed at Verizon).

I recommend including the MAC address in the MIC generation to limit 
replay attacks.  The MAC address is the payload pointer to the RID in 
most ASTM messages.

In IPsec speak, this is Authenticated Headers in message protection.  
Now the IPsec AH payload has serious challenges with NAT boxes, but that 
does not apply here.  :)

> ·What DRIP AuthType specify the use of this?
>
> <atw>
>
> This is something that only appears in the Manifest formats that 
> Section 5.2 discuss. This whole section needs a bit better formatting 
> and organization.
>
> </atw>
>
> 5.2.3. 8 Byte:
>
> ·Chapter 4.1 specify the DRIP AuthType to be 0x86 or 0x06 (not 0x87 or 
> 0x07).
>
>  5.2.4. 4 Byte:
>
> ·Chapter 4.1 specify the DRIP AuthType to be 0x87 or 0x07 (not 0x86 or 
> 0x06).
>
> <atw>
>
> Simple fixes if the 5 Wrapped Message format is indeed impossible - 
> but again I argue for its use in Bluetooth 4 to emulate a Message Pack 
> that is fully signed.
>
> </atw>
>
> 5.3.1 Assertion:
>
> ·I didn’t look in details through [identity-claims] but it looked like 
> there were things in there a lot longer than the max 132 bytes 
> allowed? Maybe I misunderstood.
>
> <atw>
>
> This is a section that needs to be fixed and clarified. The only 
> identity-claims format to be used here is from Section 3.2.2 
> Attestation: X on Y (Offline Form).
>
> ·Should this be between Chapter 5.1 and 5.1.1, just to have a logical 
> order when reading the document?
>
> ·Maybe some more description is needed to explain how exactly this is 
> done?
>
> <atw>
>
> The reason this is in the Bluetooth 5.X Formats section is as it 
> should only be used in the Message Pack. It is effectively the DRIP 
> version if the ASTM Message Pack Signature.
>
> </atw>
>
> 6.2. DRIP Certificate:
>
> ·Couldn’t this be deleted if the “w/FEC” part from the Figure 10 
> description is also deleted? Is there a need to have separate chapters 
> for BT4 and BT5?
>
> <atw>
>
> As for seperate chapters on BT4 and BT5 it seemed logical to separate 
> them. However, I did do a disclaimer of sorts near the beginning of a 
> section stating that under Bluetooth 5 FEC is not recommended - that 
> was enough, and all these could just be their own chapter 
> sections.Either the DRIP Auth header is added to all pages or the 
> recovery of page 0 is specified so it can be handled with the AD Counter?
>
> </atw>
>
> Søren Friis
>

---

From: "Friis, Soren" <[email-masked]>
Date: Mon, 14 Dec 2020 13:43:04 +0000

Hi

You need to complain to Google about that. They don’t offer that information when using the Android API for WiFi Aware. You only get a PeerHandle<https://developer.android.com/reference/android/net/wifi/aware/DiscoverySessionCallback#onServiceDiscovered(android.net.wifi.aware.PeerHandle,%20byte[],%20java.util.List%3Cbyte[]%3E)>, which has some kind of pseudo integer hashCode<https://developer.android.com/reference/android/net/wifi/aware/PeerHandle> number, and that might even change over time.

Probably the low-level driver has that information, but it is not passed upwards in the SW stack to the application.

               Søren

From: Tm-rid <[email-masked]> On Behalf Of Robert Moskowitz
Sent: Monday, December 14, 2020 3:31 PM
To: Friis, Soren <[email-masked]>; Adam Wiethuechter <[email-masked]>; Drone Remote ID Protocol Discussion List <[email-masked]>
Cc: Cox, Gabriel C <[email-masked]>
Subject: Re: [Drip] Comments on DRIP Authentication Formats

< CUT >

How is it that the WiFi NaN receiver does not get the sender's Media Access Control address?  this is counter to the 802.11 standards, and is probably a driver limitation?  Now NaN is not really owned by 802.11, but rather the WiFi Alliance.  I can ask some of my colleagues there for clarification (I stopped participating in WiFi Alliance, and pretty much 802, when I was RIFed at Verizon).

I recommend including the MAC address in the MIC generation to limit replay attacks.  The MAC address is the payload pointer to the RID in most ASTM messages.

In IPsec speak, this is Authenticated Headers in message protection.  Now the IPsec AH payload has serious challenges with NAT boxes, but that does not apply here.  :)

< CUT >

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 14 Dec 2020 08:53:41 -0500

On 12/14/20 8:43 AM, Friis, Soren wrote:
>
> Hi
>
> You need to complain to Google about that. They don’t offer that 
> information when using the Android API for WiFi Aware. You only get a 
> PeerHandle 
> <https://developer.android.com/reference/android/net/wifi/aware/DiscoverySessionCallback#onServiceDiscovered(android.net.wifi.aware.PeerHandle,%20byte[],%20java.util.List%3Cbyte[]%3E)>, 

this is a WiFi Alliance and ASTM issue.  It could really be bad for use 
of WiFi NaN for linking a series of Broadcast messages.  How do you do 
it now?  Do you ASSuME that this hashcode does not change during an 
operation?

Gabriel, do we need to get ASTM to officially contact WiFi Alliance and 
then Google?  Subject for the next F38.02 call?

And what does Apple do?

Shudder...

>
> Probably the low-level driver has that information, but it is not 
> passed upwards in the SW stack to the application.
>
>                Søren
>
> *From:*Tm-rid <[email-masked]> *On Behalf Of *Robert Moskowitz
> *Sent:* Monday, December 14, 2020 3:31 PM
> *To:* Friis, Soren <[email-masked]>; Adam Wiethuechter 
> <[email-masked]>; Drone Remote ID Protocol 
> *Cc:* Cox, Gabriel C <[email-masked]>
> *Subject:* Re: [Drip] Comments on DRIP Authentication Formats
>
> Access Control address?  this is counter to the 802.11 standards, and 
> is probably a driver limitation?  Now NaN is not really owned by 
> 802.11, but rather the WiFi Alliance.  I can ask some of my colleagues 
> there for clarification (I stopped participating in WiFi Alliance, and 
> pretty much 802, when I was RIFed at Verizon).
>
> Now the IPsec AH payload has serious challenges with NAT boxes, but 
> that does not apply here.  :)
>
> < CUT >
>

-- 
Standard Robert Moskowitz
Owner
HTT Consulting
C:248-219-2059
F:248-968-2824
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Adam Wiethuechter <[email-masked]>
Date: Mon, 14 Dec 2020 16:45:53 +0000

Soren,

It seems clear that the following items need attention and further discussion in ASTM (as you have stated):

  *   How exactly does one use the AD Counter? I would argue it increments with each new message type. This does mean that with Message Pack it would apply to all messages in the pack but, that should be fine - you either got the full frame in BT5 or Wifi NaN or you didn't. The issue then lies in messages present in one pack, but absent in others thus skipping in the count.
  *   Our original request to ASTM with regards to Max Page Count is a bit more nuanced. For ASTM, 10 would be the max (as we requested) but only available for BT4. BT5 max would be only 9. Under DRIP the 10th page of BT4 is reserved for FEC when enabled. Limiting so that all mediums can carry the same amount is a good thing - less divergence in the specification between mediums the better.
  *   Some sort of set identifier for Authentication Messages. Clearly, it needs something. I was using the AD Counter for this - and we still could and just mandate it as such for F3411. If you wanted to put it in the Auth. framing itself it would be another byte used and would only allow a max of 236/214 bytes of payload data (16 +[22 * Max Page Count]). This would remove the byte DRIP uses as its header in Page 0 and make the certificate not fit when FEC is enabled. Must think on this one more as it directly affects DRIP in a substantial way.

I must now sort out why the messages Bob send do not contain his inline comments section. Probably its Microsoft Outlook being silly.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
________________________________
From: Tm-rid <[email-masked]> on behalf of Friis, Soren <[email-masked]>
Sent: Monday, December 14, 2020 3:40 AM
To: Adam Wiethuechter <[email-masked]>; Drone Remote ID Protocol Discussion List <[email-masked]>
Cc: Cox, Gabriel C <[email-masked]>
Subject: Re: [Drip] Comments on DRIP Authentication Formats

Hi

               Søren

Soren,

--------

73,

Adam T. Wiethuechter

Hi

<atw>

</atw>

<atw>

</atw>

<atw>

</atw>

<sf>

</sf>

<atw>

</atw>

<atw>

</atw>

<sf>

</sf>

<atw>

</atw>

<sf>

</sf>

4.1.3 FEC:

<atw>

</atw>

<sf>

</sf>

4.2. DRIP Wrapper Frame:

<atw>

</atw>

<atw>

It should be Attestation. I am terrible when I copy and paste. You should see my code ??

</atw>

<atw>

</atw>

<atw>

</atw>

5.2.1. Hash Algorithm:

<atw>

</atw>

<sf>

</sf>

<atw>

</atw>

5.2.3. 8 Byte:

 5.2.4. 4 Byte:

<atw>

</atw>

5.3.1 Assertion:

<atw>

</atw>

<atw>

</atw>

6.2. DRIP Certificate:

<atw>

</atw>

Søren Friis

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 14 Dec 2020 11:58:13 -0500

On 12/14/20 11:45 AM, Adam Wiethuechter wrote:
>   * How exactly does one use the AD Counter? I would argue it
>     increments with each new message type. This does mean that with
>     Message Pack it would apply to all messages in the pack but, that
>     should be fine - you either got the full frame in BT5 or Wifi NaN
>     or you didn't. The issue then lies in messages present in one
>     pack, but absent in others thus skipping in the count.
>   * Our original request to ASTM with regards to Max Page Count is a
>     bit more nuanced. For ASTM, 10 would be the max (as we requested)
>     but only available for BT4. BT5 max would be only 9. Under DRIP
>     the 10th page of BT4 is reserved for FEC when enabled. Limiting so
>     that all mediums can carry the same amount is a good thing - less
>     divergence in the specification between mediums the better.
>   * Some sort of set identifier for Authentication Messages. Clearly,
>     it needs something. I was using the AD Counter for this - and we
>     still could and just mandate it as such for F3411. If you wanted
>     to put it in the Auth. framing itself it would be another byte
>     used and would only allow a max of 236/214 bytes of payload data
>     (16 +[22 * Max Page Count]). This would remove the byte DRIP uses
>     as its header in Page 0 and make the certificate not fit when FEC
>     is enabled. Must think on this one more as it directly affects
>     DRIP in a substantial way.
>
> I must now sort out why the messages Bob send do not contain his 
> inline comments section. Probably its Microsoft Outlook being silly.

I use common inline quoted commenting method used in email pretty much 
since its inception.  Mickysoft SHOULD be able to format it properly.

I have been on lists where top posting could get you banned!  :)

> *From:* Tm-rid <[email-masked]> on behalf of Friis, Soren 
> <[email-masked]>
> *Sent:* Monday, December 14, 2020 3:40 AM
> *To:* Adam Wiethuechter <[email-masked]>; Drone 
> Remote ID Protocol Discussion List <[email-masked]>