Skip to main content

DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID
draft-ietf-drip-auth-49

Yes

Éric Vyncke

No Objection

Francesca Palombini
Jim Guichard
John Scudder
(Andrew Alston)
(Robert Wilton)

Note: This ballot was opened for revision 44 and is now closed.

Éric Vyncke
Yes
Erik Kline
No Objection
Comment (2024-01-21 for -45) Not sent
# Internet AD comments for draft-ietf-drip-auth-45
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### general

* I think it's reasonable to remind the casual reader that DNSSEC is a
  recommended best practice, when it comes to an Observer querying DNS
  for various bits of information.  RFC9364#section-1.1 (other references
  are probably better)
Francesca Palombini
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Murray Kucherawy
(was Discuss) No Objection
Comment (2024-02-14 for -47) Sent
Thanks for clarifying what Section 8.1 is seeking to accomplish.  Just to verify: From the IETF perspective, this is essentially a Standards Action registry where ASTM's registrar acts as a Designated Expert, correct?

===

Forwarding some comments from Orie Steele, incoming ART AD:

There is no link available for "F3411-22a", but I found https://www.astm.org/f3411-22a.html

Not sure how paid specifications should like this or ISO should be referenced.

> An Observer SHOULD query DNS for the UA's HI.

Why not MUST ?

> An Observer SHOULD query DNS for the DIME's HI (e.g., Section 5 of [drip-registries]), when able.

Again, why not MUST? Seems to be reducing the utility of revocation.

> When correlation of these different data streams does not match in acceptable thresholds, the data SHOULD be rejected as if the signature failed to validate. Acceptable thresholds limits and what happens after such a rejection are out of scope for this document.

Why not MUST?

...
Its not clear exactly which FEC scheme is used here, a citation for the FEC would be nice.
Paul Wouters
No Objection
Comment (2024-02-14 for -47) Sent
I'm a little puzzled why this is an IETF document. It feels more like a [F3411] extension ?

       Therefore specification of particular DNS security options,
        transports, etc. is outside the scope of this document

I understand transports being out of scope but not DNS security options? If pulling key material from DNS, I think one should call out DNSSEC, or even mandate it.

Regarding 3.1.2.2. UA Signed Evidence

I don't understand why unpredictable means evidence? If I observe someone elses
unpredictable sends, can't I just retransmit those? Unless the signature contains
"live data", I can't tell it is a not a replay. I understand the two timestamps
and location/vector data are supposed to limit replays, but if those parts are
successful for that, I don't understand why an unpredictable component is still needed.
Also, what is unpredictable? I think a KDF with initial seed of "Paul is crazy" produces
a seemingly unpredictable stream, but to those knowing the seed, it is totally predictable.

        signing data that is guaranteed to be unique, unpredictable and easily cross checked

How does an IoT device do this? These famously do not have strong random sources? If they do,
would they need to use a construct similar to GCM where part is a counter and part is pseudorandom
to ensure the uniqueness without needing to store all previous "unpredictable" (aka random/unique) data?

        If an attacker (who is smart and spoofs more than just the UAS
        ID/data payloads) willingly replays a DRIP Link message, they
        have in principle actually helped by ensuring the DRIP Link is
        sent more frequently and be received by potential Observers.

But it would have spoofed its time and location of another device? I would
not all that "actually helping" ? This paragraph confuses me.

Why are there colour codes? Is that an aviation thing?
Roman Danyliw
(was Discuss) No Objection
Comment (2024-02-14 for -47) Sent
(This is a revised ballot initially entered on -46 in preparation for the Feb-01-2024 telechat)

Thank you to Rich Salz for the early SECDIR review.

I lacked access to [F3411] which is a critical normative reference for this document.  In particular, I am unable to evaluate Section 4.3.2.  

Thank you for addressing my DISCUSS feedback on -46 and most of my COMMENTs.

** Section 4.2.  
   A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement
   chain MUST be included in each DRIP Manifest Section 4.4.

[per -46] It would have been helpful to provide more prose on computing and using a “Broadcast Endorsement chain”.  

[per -47] Thanks for the explanation on endorsement chains being related to content in [drip-registries].  See below.

** [per -46] Section 11.1.  I believe that [drip-registries] needs to be a normative reference given the importance of this reference for Section 4.1 and 9.2
Warren Kumari
No Objection
Comment (2024-01-30 for -46) Sent
Firstly, thank you for this document.

Also, much thanks to Di Ma for the OpsDir review (https://datatracker.ietf.org/doc/review-ietf-drip-auth-43-dnsdir-lc-ma-2024-01-08/), and for the followup discussion.

I went and found the added text:
"Since DRIP depends on DNS for some	
 	   of its functions, DRIP usage of DNS needs to be protected in line	
 	   with best security practices.  Many participating nodes will have	
 	   limited local processing power and/or poor, low bandwidth QoS paths.	
 	   Appropriate and feasible security techniques will be highly UAS and	
 	   Observer situation dependent.  Therefore specification of particular	
 	   DNS security options, transports, etc. is outside the scope of this	
 	   document."

I think that this is reasonable for the in-line stuff, but (Like Erik), I think that it would also make sense to explicitly call out DNSSEC.
Zaheduzzaman Sarker
No Objection
Comment (2024-01-30 for -46) Sent
Thanks for working on this specification. Thanks to Gorry Fairhurst for the TSVART review which certainly has improved the document.
Andrew Alston Former IESG member
No Objection
No Objection (for -46) Not sent

                            
Martin Duke Former IESG member
(was Discuss) No Objection
No Objection (2024-01-31 for -46) Sent
Thanks to authors for quickly responding to my DISCUSS with a brief summary of the rate limitations of the protocol. These messages are sent at a set rate and are not recovered if lost, so there is no transport issue.

Thanks to Gorry for the TSVART review.
Robert Wilton Former IESG member
No Objection
No Objection (for -46) Not sent