[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