Drone Remote ID Protocol (drip) - Thursday, July 30, 2020 14:10-15:50 UTC
Meetecho: http://www.meetecho.com/ietf108/drip/
Jabber: xmpp:drip@jabber.ietf.org?join (this is part of the MeetEcho interface)
Notes: https://codimd.ietf.org/notes-ietf-108-drip (This is where you are)
The Chair (Med) reminded at the opening of the session thaht the objectives of the meeting is to make sure all the reviews received from previous interim meetings has been implemented and to assess whether teh requirements and the architecture drafts are ready for the WGLC.
General update: more focus on requriements, architecture
news:
from ASTM: WK 59317
FAA: RID can not depend upon the ground observers
IATF:
others: CS-RID
ATT foundary: 10 bold prjections on the future of drones
Status report:
green color are in are shape
black: WIP
Red: areas where still have concerns, more use case and help to track what is going on in EU
Summary of activity such Jun 24:
ICAO: ASTM UAS RID
ANSI: UASSC V2.0 includes IETF’s work
Summary of changes: editorial update from Eric, Daniel, Med, Amelia, Sue, Shuai, Ryan.
Addtion of explanatory prose: explained what is “immediately actionable”:
Privay and Transprency:
New section -03: input has been implemented, based on input from Amelia.
Still need improvement: 7.2 user participant esp. Preference expression.
Missing: default from -02
Rerequest reviewers on -03 vs RFC 6972 and RFC 8280
Request Amlia from more input.
PRIV-2 encrypted Transport:
Bos’s suggestion 1: should we drop e2e encryption approach?
stu: can we use word “safty” instead.
Jonathan Hoyland: definng the end is fine?
Alexandre Perescu: “ends” in fine but in broadcast who is the 2nd end? it is a bad Reason to drop the E2E?
Alexandre: In general a good requirement for IETF protocols. it has entire security behind it. Also a good e2e communication it is good to have encryption. now broadcast, it is difficult to define a good encryption.
bob: this is best handled on the list. I will have to put together my list of reasons for dropping it, not just what are the ends in broadcast
Cullen: Some other places we end up admitting what the ends are is nearly impossible to fully define but in some common cases X,Y, Z are considered ends.
Bob: I have a draft for Network RID security which is separate for the issues around broadcast
Stu: BRID does not use IP.
Alex: another question. what kinda things IETF can do below IP?
Stu: systems as whole do use IP, but that particular mode of oding remote athuentication ndoes not use IP
Bob: The “encryption not allowed” is only for broadcast. Network is encrypted in everyones view.
Jonathan: But at the application layer it can be.When it comes to broadcast, is there someone who shouldn’t be able to read the data?
Bob Moskowitz: yes.
Jothanan: How are the sets of people who may and may not read the data defined?
Bob: General public should not be able to find the pilot to beat him up. They should contact authorities that can do that.
Jonthan: Assuming we trust the government ;p.
suggestion 2: public and safty personnel might need those information. more improvement regarding what and how can we do it
PRIV-3: Encryption storage
DRIP should facilitate selective strong encryptoin of private data
request: is this acceptable text?
Med: ask for more comments from the WG.
Open issues: Refer to the slides.
Stu: the logic of Stu for this draft: from operational requrirement, to funcational requirement, technical requirment
however this does not work IETF. We did not define this arch design. it is defined by other SDOs or regulators. IETF would like to describe the overall architecture, but there is no need to go through all the dtails since it has been addressed by others. Confusions from Solutions in this draft.
Reviews from previous dission which has not been addressed yet:
Med,
Bob:
Amelia -02 review: saftly vs Security,
Carsten:
Alexandre:
Bob:
Saulo:
Daniel-03:
Stu’s own questoin/conerns:
draft scope: no need to redesign the archtecture. merge all of the three drafts?
Bod’s CS-RID could help with Malicious operator.
Jothan Holyland: use of PUF might help, physical chips might be very hard to crowd.
Stu: good idea but might be more push back.
Jonathan: PUF is used for IoT.
Jaganbabu:
STU: TPM bootloader. not sure if any other small uas use TMP so far.
Cullen Jennings: @Jonathan - what CPU are think of on cheap drones that could not do this?
Jonathan Hoyland: TPM’s seem much heavier than necessary.
Alexandre Petrescu: TPM… in cars there are HSMs - High Security Modules.
Stu: Maybe there are some edge things we can do mitigate we can do in the future.
Cullen: I think one of things TPM does not fully solve the problem. Even you can not generate keys from TPM, you still have the private keys to do things. It is not about to access of those private key… curiously insertaion of type of fly controller can not generate those keys.
Cullen: Dig a little deeper if the compressor can use it.
Stu: More concerned about things around it. It is a close-source app, which require more manufacutre cooperation.
cullen: Yes, this is a good point.
Daniel: Are you asking private key to reflect the id. The UA needs to be protecte by the key. or you are asking what we have today?
Cullen: Don’t believe the drone itself can not genenrate the private key. the private key will be leak in some way. better assume the private key can be extract. some of the security risk.
Daniel: Do we have to consider what we have today?
Stu: To the basic draft to highlight the private key will be comprised, add on optional thing DRIP can do we have mitigation solution avaliable.
Stephan: Regulatory requirments which Drone will be sold must complaimnt with those. regulations. IN a few years, drone will create whatever key regulator requires. every of the controller has a mimimum 32bits processor. I wont worry about the technical ability to do such thing, more concern on the regulatory.
Stu: The goal of RID is for safety of public if it is not identified.
Stephan: w.r.t private key environement is a valid design goal, but drawing assumption is a bad idea.
Stu: Agree, accept this risk will happen is bottom-line of the design.
Danei: Continue discuusion from mailing list. Not dig too much if it is leaking not worry about leaking.
Managing and Using an Aviation Domain Hierarchy, Michael Palage
Leverage existing internt procotol: ex: EPP, RDAP. the ID will be associate iwth air frame, base upon disucssion, there will be tendnecy only for drones, manned and unmamned aircrafts. The proposed solution is for both.
Leveraging ISO-3166-2, part of this is to take lots of localize context allowing that be handled relatent content in each country
Proposed eco-system: welcome feedback.
Continue engagement with global aviation community. Use existing naming schema/protocols and etc. Seaking an IETF 109 draft.
Daniel: Quesiton about about RDAP.
Michael: RDAP can provide solutions will work for a global scale.
Daniel: The level of maturity of those drafts and ask if those drafts are ready for WG last call.
Stu: I dont think it is ready for WGLC, still contiune to work on it. The req draft needs one more round of changes.
Daniel: It is also my perception.
Bob: Requirement is ready. Arch is not there yet but not far away.
Design considertaions:
Possible approaches:
lack of Hierarchy whihc is an “easy” add
RGC3972 : difficut crypto agility hard to fix RFC4982
Choosen apparoach: HIT with added hierarchy, like Miachel’s approach, lookup with DNS
DRIP Req met: GEN 1-3, ID 1-5, REG 1$2
Dan Harkins: did you consider if ID based encryption solution?
Bob: I am against id-based encryption, too much comproise, too risky. For sth this large,it is not good.
Daniel: Next draft need to be worked on. More reviews are needed. Ask Chairs for future plans. Send -arch and -req sent out before others
Bob: this is one the first technical solution. we need to first understand what is RID. personally want WG adopton sooner than later. Ask for WG adoption.
Daniel: ask for the public, is this a very bad solution?
[no response from the public]
Daniel: will get back Bob soon.
“we are flying DRIP” with prototypes.
Range testing, python3 implementation with ASTM 3411-19
findings for bt4 and 5, full certifidate message retrive testing
DRIP Auth solution: use HHIT, signature sieze of EdDSA25519, increase auth page limit from 5 to 10, add FEC for correctoin
Intro of ASTM F3411-19 BRID
Lack of trust of BT4
DRIP Header Details: is it a best way to do it?
=====
=====