[saag] Fwd: New Version Notification for draft-moskowitz-ads-b-auth-02.txt
Robert Moskowitz <rgm-sec@htt-consult.com> Fri, 14 August 2026 18:07 UTC
Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: saag@mail2.ietf.org
Delivered-To: saag@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BA1F4129F717D; Fri, 14 Aug 2026 11:07:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1786730857; bh=ObTNa+lhnbMoudISdcQRIpDtNxhmPfBbweEF89AUyYA=; h=Date:From:Subject:To; b=xKvG79RMVXwGmk0n37LyNalriVeiVzvl0uVwUmIYRudjpNtIFw30WQ1Fh3HOhgnOO yjTGWckLAabWb7+fr0mkSdeOSlnRiXO+E5Y/CdFRywbscX8yq2OVUWDZrMZUOgdDQH NKauX9/E+kJlDTvrZWrwvkK3ttJNnneF6fCaP1/A=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=htt-consult.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtgdDffupZNu; Fri, 14 Aug 2026 11:07:37 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [23.123.122.149]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 064FC129F7176; Fri, 14 Aug 2026 11:07:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=htt-consult.com; s=mail; t=1786730850; bh=ObTNa+lhnbMoudISdcQRIpDtNxhmPfBbweEF89AUyYA=; h=Date:From:Subject:To:From; b=kTcJJ3aiEggM7TxSSQ3yfnA/Po+EBKJIzpfChMkIKdvpYlB7I//yUHVpQmzXnk6ww XGZsqQG4RuSnkHGH+dDLUDc4tZNMxKa3zNqz1lHBxxVfd/FfLUX5nud59V2vu8vkI9 YHdP1ZToGe4U0LlijXdIKqKe3hwupjwfYbLahN4YsFlHsTLeF2s5RUk55k7w1RAP4h 36qWr5rp2hc31jYtQZEbSIOMDwTUNJGrUDPNay/pb3ws3ih9gW39N9Gta2fbIraZo9 imkVvkPPlTrCo78VvqU+ozonEbRviacg/9CIRDR8+0VAA2uy8Nkf9XOKSs5JFHS1Le qWaFv7PCrc6Tw==
Received: from authenticated-user (klovia.htt-consult.com [23.123.122.149]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by klovia.htt-consult.com (Postfix) with ESMTPSA id C2E854A0322; Fri, 14 Aug 2026 14:07:29 -0400 (EDT)
Content-Type: multipart/alternative; boundary="------------5L7vfsI6xPJvOneIXYchmyaV"
Message-ID: <042a26e2-1795-490a-affb-7e25cdb13c40@htt-consult.com>
Date: Fri, 14 Aug 2026 14:07:28 -0400
MIME-Version: 1.0
From: Robert Moskowitz <rgm-sec@htt-consult.com>
To: IETF SAAG <saag@ietf.org>, rfc4082-update@ietf.org
Content-Language: en-US
Message-ID-Hash: PW2UNUUSZUI3FPL7XC6OQ2U72IPOSQ6Y
X-Message-ID-Hash: PW2UNUUSZUI3FPL7XC6OQ2U72IPOSQ6Y
X-MailFrom: rgm-sec@htt-consult.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-saag.ietf.org-0; header-match-saag.ietf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [saag] Fwd: New Version Notification for draft-moskowitz-ads-b-auth-02.txt
List-Id: Security Area Advisory Group <saag.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/mGacUARM-JqelZtd-fN0nwMIMaI>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Owner: <mailto:saag-owner@ietf.org>
List-Post: <mailto:saag@ietf.org>
List-Subscribe: <mailto:saag-join@ietf.org>
List-Unsubscribe: <mailto:saag-leave@ietf.org>
Here is an updated version with more technical content. I really request review of the TESLA aspects. Particularly sec 3.3.3.1 this is where I have the various hashing and key MACing functions. Of course a couple of big points: The TESLA MAC is 28 bits. That is all I can really fit into the messages. But the authentication key is only used for ~31 messages before moving on to the next key in the hash-chain. And this ties into PQC concerns. 128-bit key works nice in that it works well in the disclosure of 144 bits available in a TESLA maced message. If I drop the MACing, I can go up to a 192-bit key. A 224-bit key is possible if I make this a complete new message (grabbing 51 bits from the PPM portion, 196+51), but taking up valuable channel capacity. At most there is only 255 bits available if I really push the design; a 256-bit key is just not possible. But as the authentication key as from a hash-chain and ONLY used for ~31 messages (current TESLA interval design, may change), and KMAC is the Manditory mac (HMAC optional), is there a real QC risk against the 128-bit key? Thank you for any reviews/feedback! Bob -------- Forwarded Message -------- Subject: New Version Notification for draft-moskowitz-ads-b-auth-02.txt Date: Fri, 14 Aug 2026 10:46:25 -0700 From: internet-drafts@ietf.org To: Stuart W. Card <stu.card@axenterprize.com>, Mikaëla Ngamboé <mikaela.ngamboe@amdg-research.com>, José M. Fernandez <jose.fernandez@bastionnage.ca>, Adam Wiethuechter <adam.wiethuechter@axenterprize.com>, Jose Fernandez <jose.fernandez@bastionnage.ca>, Mikaela Ngamboe <mikaela.ngamboe@amdg-research.com>, Robert Moskowitz <rgm@labs.htt-consult.com>, Stuart Card <stu.card@axenterprize.com> A new version of Internet-Draft draft-moskowitz-ads-b-auth-02.txt has been successfully submitted by Robert Moskowitz and posted to the IETF repository. Name: draft-moskowitz-ads-b-auth Revision: 02 Title: ADS-B Authentication Date: 2026-08-14 Group: Individual Submission Pages: 46 URL: https://www.ietf.org/archive/id/draft-moskowitz-ads-b-auth-02.txt Status: https://datatracker.ietf.org/doc/draft-moskowitz-ads-b-auth/ HTML: https://www.ietf.org/archive/id/draft-moskowitz-ads-b-auth-02.html HTMLized: https://datatracker.ietf.org/doc/html/draft-moskowitz-ads-b-auth Diff: https://author-tools.ietf.org/iddiff?url2=draft-moskowitz-ads-b-auth-02 Abstract: Automatic Dependent Surveillance – Broadcast (ADS-B) is a surveillance technology mandated in many airspaces. It is now widely deployed but suffers from a lack of security and privacy. From a security point of view, it is relatively easy to spoof ADS-B messages with readily available hardware and software. From a privacy point of view, every ADS-B message contains the aircraft's assigned 24-bit ICAO address, a unique identifier that can be cross-referenced with external databases (e.g. aircraft registries) to reveal the owner, and can be used to track when and where a specific aircraft has flown. In addition, the main transmission medium used for ADS-B, the 1090 MHz frequency, on which messages are broadcast using the Extended Squitter (1090ES) format, is approaching saturation in some parts of the world due to the volume of ADS-B and other protocol messages, resulting in packet loss in certain areas. This paper presents the IETF TESLA protocol along with X.509 certificates issued by ICAO member states for each aircraft to authenticate all ADS-B messaging. It leverages the 8PSK phase overlay (PO) scheme proposed in the Minimum Operational Performance Standards (MOPS) for ADS-B (RTCA [DO-260C]), which enables 1090ES ADS-B transmissions to convey three times more information, to support the transmission of the extra security information required by the authentication scheme. By doing so, the impact of authentication on channel usage is negligible. Beyond message authentication, this scheme protocol has two important additional benefits: 1) the possibility to implement a Flight Authorization scheme, allowing ATC and intercepting aircraft to not only authenticate an aircraft but to verify that it is authorizes to conduct that flight and 2) a privacy-preserving methodology that assigns random 24-bit identifiers to designated aircraft while still enabling blind authentication of their ADS-B transmissions. The IETF Secretariat
- [saag] Fwd: New Version Notification for draft-mo… Robert Moskowitz
- [saag] Re: Fwd: New Version Notification for draf… John Mattsson
- [saag] Re: Fwd: New Version Notification for draf… Robert Moskowitz