[TLS] Re: Response to CoI Complaints

Hello Deb,

Thank you for replying and for making clear that these discussions are
within the bounds of acceptable IETF discourse. I am not questioning
your technical competence, personal character, or right to participate.
I am asking about disclosure, continuing obligations, recusal, and
specific technical decisions. Everything I know about you leads me to 
believe that I am not wasting my time by trying to reach you.

Hello Jay,

This appears to be a question as well for Jay and the Board, so I cc'ed
the Jay as he has been fairly responsive in the past. Jay, would you be 
willing to help us clarify any of the conflict of interest business and 
disclosure aspects listed below?

I had planned to attend Vienna, but I cancelled after direct and
indirect off-list conduct that I experienced as harassment and
intimidation. Other participants have reported similar events including
inappropriate contact associated with a non-American government agency.
I will raise that separately through the applicable process rather than
litigate the details here. I have encouraged others to do the same. I
mention it because it materially affected my participation and because
the policy scope below is not abstract.

And back to the email to Deb,

Requesting that you address the specific questions in my original email
[16] would be helpful. A direct answer, including "no" or "I cannot
answer," would reduce repetition and establish a useful record.

By my read of everything, the IETF LLC disclosure page is not the
applicable disclosure mechanism for an Area Director but rather the
applicable policy is the IESG Conflict of Interest Policy [0]. Its
current table lists:

Deb Cooley    None    None
2024-08-05, updated 2024-12-11, confirmed 2025-04-08,
updated 2025-06-16, confirmed 2026-04-10

What was updated on 2024-12-11 and 2025-06-16?

The separate IETF LLC disclosure system is still relevant context. Sean
Turner's 2024 form identifies Akayla, Inc. and contains entries on both
pages marked exactly "[DISCLOSED TO BOARD & REDACTED]" [1][2].
Redaction may be legitimate, but the public should at least receive a
general characterization of the conflict. My read of the IESG policy
similarly requires a general explanation when public detail is
restricted, and recusal is _required_ where a conflict _cannot_ be
disclosed [0]. What is very tricky here is that in the national security
context, if something cannot be disclosed, then it follows that no one
outside of a cleared setting probably knows about the issue to report
that a secret is being withheld! Argh!

Most strikingly, is that the IETF LLC Whistleblower Policy
expressly says that IESG members are not "Covered Individuals" (!)
unless separately and formally authorized in an LLC capacity [3]. Anyone
may report, and the policy bars retaliation by Covered Individuals, but
the policy does not itself place an ordinary IESG member inside that
disciplinary framework. This raises two questions:

- 1. Who is authorized to review the redacted disclosure, and under what
   confidentiality and conflict rules?

- 2. What policy governs retaliation or misconduct by an IESG member who
   is not acting as an LLC Covered Individual?

Who besides the LLC Board, if anyone, may review the redacted
information, and what confidentiality, recusal, and conflict rules apply
to each reviewer? Separately, what process governs retaliation or
misconduct by an IESG member acting solely in an IETF capacity? I hope
all of those people have Whistleblower protections.

The LLC Community Engagement and Code of Conduct policies likewise
apply to LLC roles, while standards work remains under IETF processes
[4][5]. RFC 7776 remains available for participant harassment reports
[6]. This split makes clear public disclosure and a direct answer
especially important. As far as I can ascertain, we are within the
bounds of all of those documents.

It seems certain to me however that one of those details could be
incorrect, so forgive me in advance if I have misread or misunderstood
the various documents and policies. It is a lot to take it.

Thank you again for your public service.

On 7/15/26 20:49, Deb Cooley wrote:
> For the record:  I have been a Security Area Director since March 
> 2024, that is 2 years and a couple of months.
> 
> There have been previous inquiries into my ability to perform the 
> duties of Security Area Director

I do not accept the framing that the concern is your ability to perform
the role. Your public biography reflects more than thirty-seven years at
NSA and a role as a Special Government Expert for DHS/CISA [7]. Your
technical competence is not the issue.

The present questions are narrower:

1. Did the DHS/CISA role overlap with your service as an Area Director,
    working-group chair, or another IETF leadership role?

2. Did that role involve remuneration, sponsorship, consulting, or
    another relationship covered by the IESG policy?

3. Was that role, its commencement, or its ending reflected in either
    recorded disclosure update?

4. Do any continuing clearance, reporting, confidentiality,
    nondisclosure, post-employment, or similar obligations affect your
    IETF work, your ability to discuss relevant subjects, or your ability
    to act independently on them?

5. If such an obligation exists but cannot be described specifically,
    has it been disclosed in general terms or managed through recusal as
    contemplated by [0]?

A simple "no" is useful where the answer is no. If you cannot answer,
saying so is also useful. These are institutional questions, not a
judgment about whether you are kind, well regarded, or technically
qualified.


> via the SSHM working group, and as part of complaints against the 
> TLS chairs/AD.

I do not want to distract here but I do want to say that this only
increases the need for us to resolve the key concerns.

The SSH hybrid exchange (mlkem768x25519) _may_ have the same-shaped 
issue before client authentication (pre-auth): the server encapsulates 
to a client-supplied ML-KEM public key, and that client can decapsulate 
the server-generated value. We know NSA could decrypt SSH sometimes 
because this was shown in research and also as an NSA claim in some 
media disclosures. We would not want that kind of security failure to be 
repeated in the transition to a PQC world.

This is the wrong working group for SSH concerns but I am happy to share 
my analysis wherever.

> Those have been responded to by the IESG, the artifacts are below:
> 
> https://mailarchive.ietf.org/arch/msg/ 
> ssh/7KRZCX_bvZWUOG50HqDg_KVT77c/
> 
> https://datatracker.ietf.org/group/iesg/appeals/ (see artifacts 
> 125/126, as well as 128/129)

I have read artifacts 125, 126, 128, and 129 [8][9][10][11]. They
address earlier complaints and the IESG's disposition of them, but they
do not answer the current factual questions above.

In particular, they do not explain the two disclosure updates, the
terms of the DHS/CISA role, possible continuing obligations, or whether
specific recusals occurred. They also reduce a broader concern about
financial, legal, and operational constraints to a perception arising
from former NSA employment. NomCom's appointment decision does not end
the continuing disclosure duties imposed by [0].

Maybe I am alone in being surprised to learn that you are retired from
NSA. However you have also declared that you are working or have worked 
in some capacity with the Department of Homeland Security. That is a 
kind of retirement. The timeline is not clear to me but it could be that 
DHS was before or after NSA retirement. I trust we can agree that this 
is at least a little confusing!

I am not asking you to re-litigate the appeals. I am asking for current,
direct answers especially since those appeals do not cover the issues I
have raised here or elsewhere.

> The recourse for anyone who doesn’t believe this is a sufficient 
> response is free to take a look at RFC 8713, Section 7

Are you saying that a community member seeking factual clarification
should initiate an IESG recall under RFC 8713 [12]?

I am not proposing recall. That is extreme and it would signal an end to
seeking understanding which frankly would severely harm the IETF
regardless of outcome.

I am proposing that you not hold yourself in your official capacity as
beyond reproach and that you engage with the substantive questions so
that we can lower the temperature with facts. I am doing this because I
have worked for the better part of my life to uncover the citations that
I have provided, and I do not view you personally or professionally, or
even the GCHQ or the NSA as an enemy.

I understand that the feeling about "indigenous" cryptographers is
probably not positive. I am not the only person in this thread who is
confirmed to have been _directly_ and _indirectly_ targeted for
surveillance by NSA (and FBI, and DHS, and CBP/ICE, and DIA, and DNI,
etc., etc. etc.). I am one who is willing to speak up to try to find a
way forward with fact finding. If there is doubt about my claim here, I
will provide evidence but anyone paying attention to the citations. My
FOIA lawsuits against various US Government agencies have been fruitful,
to say the least.

In any case, a Recall would be a disproportionate substitute for a short
factual response. It appears to me as a huge distraction and an awful,
unnecessary escalation. If you believe that no further answer is
possible and recall is the only remaining procedure... I suppose that is
a valid position... but then please say that plainly.

> Just a couple of minor points:
> 
> 1. Retirement means that I don't work for NSA anymore. I earn no 
> salary.

I accept that you no longer work for NSA and receive no NSA salary.

I am not raising the concerns covered in the appeals that you cited.
Hopefully we can agree that my concerns are not about your pension payments.

Retirement from NSA does not answer whether you received remuneration,
sponsorship, or other support from DHS/CISA or another US Federal
entity after retiring from NSA; whether that relationship overlapped
your IETF leadership work; or what changed in the two IESG disclosure
updates.

Is it the case that after your retirement that the Department of
Homeland Security (as listed on your data tracker page) paid you any
amount of money at all for anything related to the IETF?

> 2. Retired does not mean the same as 'defected'.

I did not call you a defector. Did anyone do so? If so, would you please
identify the statement. This causes a lot of conclusion.

This part of your message seems to have been interpreted by others on
the list as if someone called you that name. Did that happen?

As far as I understand it, I read the use of "defected" as... an
unsettling characterization by _you_ of my and other people's questions.
That has a chilling cold-war frame of reference and I hope I 
misunderstand. It also implies that the people asking questions are 
defectors or worse.

If answering the questions that I posed in the other email would be
considered defection, I find that deeply concerning.

Answering questions about public duties, continuing obligations, or
technical decisions is not defection. No one has accused you of
defecting, right? What is the implication? Could you finish the thought? 
Defect to what or to whom?

If a particular answer is barred by an ongoing legal or confidentiality
duty, that fact is relevant to the disclosure and recusal analysis even
if the protected information cannot be revealed.

> 3. My bio is accurate see here: https://datatracker.ietf.org/ 
> person/ Deb%20Cooley. 37+ years of service in Cybersecurity which 
> used to be Information Assurance, which used to be Information 
> Security, which used to be COMSEC.

Thank you again for your service.

The biography you linked states that you retired from the NSA
Cybersecurity Directorate in December 2023 and that you served as a
Special Government Expert for DHS/CISA [7]. A biography and a
conflict-of-interest disclosure serve different purposes. I was 
surprised to see the DHS in addition to NSA on your page because of the 
regular mentioning of retirement from the NSA and the Federal government.

Respectfully, I request that you please clarify:

1. What were the start and end dates of the DHS/CISA role?

2. Did it overlap your Area Director term or another IETF leadership
    role?

3. Did you receive salary, honoraria, reimbursement, consulting fees,
    sponsorship, or other remuneration?

4. Was the role disclosed under the IESG Conflict of Interest Policy?

5. Was it related to the 2024-12-11 or 2025-06-16 update?

6. Are there other government, intelligence, defense, consulting,
    sponsorship, or compensated roles relevant under [0] that are not
    visible in the current disclosure?

7. Are you required to perform any reporting of foreign contacts [24] as
    part of continued or current holding a US Government security
    clearance?

> In addition to the artifacts above, I suggest that there might be 
> people for whom I have worked with that could give an opinion on my 
> work ethic and conduct for the last 2 plus years.


I am not seeking testimonials or disputing your work ethic. Character
references cannot answer whether an obligation exists, what was updated,
whether a recusal occurred, or why a technical concern was accepted
or rejected.

The immediate technical questions are:

1. Did you have any role in PROJECT BULLRUN, Extended Random, or related
    SIGINT-enabling work? If an ongoing obligation that prevents an
    answer also creates an actual or potential conflict concerning your
    IETF work, that conflict must be disclosed in general terms or
    managed through recusal as required by [0].

2. Will you support explicit Security Considerations text explaining
    FIPS 203's removal of Kyber's hash over `m`, the approved-RBG
    assumption used to justify that removal, and the fact that the
    decapsulating peer recovers `m` [13][14]?

3. Will you support a concrete mitigation, including restoration of
    Kyber's hashing strategy where conformance and applicable IPR permit?

4. Will you support asking NIST to correct or clarify the rationale and
    the IPR position so that this defense-in-depth measure is plainly
    available to implementers?

These questions concern what you will support in your present IETF role,
not your personal morality or popularity.

I expect that if you cannot or will not or do not answer item 1 above
then it may be that you also cannot do so. Worse yet, if you cannot do 
so then you probably are unable to answer by saying that you cannot 
answer that specific question.

Here's why I draw that conclusion:

Section 4 [0]:

"Each Covered Individual must publicly disclose their main employment,
sponsorship, consulting customers, other relevant sources of income, and
other likely sources of conflicts of interest when entering the IESG or
whenever there are updates. If relevant information cannot be disclosed
publicly due to confidentiality agreements or other reasonable factors,
a Covered Individual must explain the relevant facts and circumstances
in a general way (without revealing confidential information)."

and

"Aside from public disclosures related to general employment and
relevant income sources, which are required above, any other potential
conflicts of interest for a Covered Individual must be disclosed
internally to the IESG. Covered Individuals must promptly disclose when
they become aware that a topic discussed by the IESG or a decision to be
made by the Covered Individual could be perceived as an additional
conflict of interest or potential conflict of interest by a reasonable
person who is aware of the Covered Individual’s situation. If a Covered
Individual cannot disclose a conflict or potential conflict due to
confidentiality restrictions, they must recuse themselves from
discussion and decision-making on the relevant topic."

Section 5 [0]:

"If the IESG is alerted that a Covered Individual has failed to disclose
a potential conflict of interest, it must inform the Covered Individual
and allow the Covered Individual an opportunity to explain the alleged
failure to disclose. If the IESG decides that the Covered Individual has
in fact failed to appropriately disclose a possible conflict of interest
in accordance with this policy, the IESG will notify the broader IETF
community of this determination."

If one can't disclose then I read the relevant policy as saying that
recusal is basically required. Am I misunderstanding it? If you are able
to answer then I think that an answer at least avoids the possible
national security paradox. This stuff is confusing!

> 4. If you read RFC 9151, read all of it.  Section 6 and 7 have MAY 
> requirements which improve interoperability.  Note that the draft 
> was published in February 2021 when Adrian Farrel was the ISE.  It 
> was reviewed by a noteworthy set of reviewers including the late
> Jim Schaad.

The competence and good faith of the reviewers are not in question.
The narrower question posed by Ken was why RFC 9151 omits P-521 and does
not explain that omission in its Security Considerations [15]. P-521
is the NIST prime curve associated with a higher classical security
strength than P-384, yet Sections 6 and 7 do not explain why the
profile stops at P-384.

It seems perfectly fair to ask about this matter. Why did the CNSA
profile select P-384 and exclude P-521, and should RFC 9151 have
explained the security and policy rationale for that choice?

Will you answer why P-521 was omitted? If the reason was policy,
interoperability, profile scope, classification, or something else,
please say which. Will you support recording that rationale through an
appropriate public mechanism? An erratum may not be the right vehicle
for new guidance, but the rationale should be public.

Will anyone from NSA answer this? I guess that is a question also to
current NSA people, so if you do not want to answer that even as the
draft author, I could understand.

Thank you for engaging. Concise answers to the numbered questions would
substantially reduce repetition and allow the discussion to move forward.

If there is another forum where you would prefer to discuss the matter,
I am open to moving the non-technical aspects of the discussion there.

It should not take a recall proceeding to obtain clarity, protection 
from retaliation, or answers to ordinary disclosure questions. If 
nothing else, will you support a clear statement that off-list 
intimidation by any defense contractor or government-affiliated 
participant is unacceptable?

Kind regards,
Jacob Appelbaum

P.S. I am placing the broader context here so that the main questions
remain easy to identify, while preserving the issues that explain why I
consider them important.

First, the IETF must be nationality-neutral. The same disclosure,
recusal, and continuing-obligation questions should apply to
relationships with NSA, GCHQ, CSE, BND, DIU, IB, RAW, FSB, SVR, GRU,
MSS, or any comparable service. That is not discrimination against
veterans or former public servants. It is an idea of a consistent
governance for an international standards body for the Internet.

Second, the concern is grounded in documented cryptographic sabotage,
not a judgment about personal character. Published reporting states
that _832 people_ at GCHQ alone had been briefed into BULLRUN by 2011
and reports NSA activity directed at IETF standards work [17]. The same
reporting quotes a classification guide covering cryptographic
modifications to commercial or "indigenous" security systems [17]. My
questions about how such terminology and missions relate to
international IETF participation remain serious, even if a lighthearted
Dances with Wolves analogy about could be made. Given your experience,
do you believe the scale of such activity has diminished, remained
similar, or grown since 2011?

The relevant institutional question is whether the IETF applies one
standard to former US and allied intelligence personnel and another to
Russian, Chinese, Indian, Ukrainian, or other intelligence personnel.
If an identically situated former FSB, GRU, MSS, or RAW cryptographer
became a Security Area Director, the community would reasonably ask
about continuing duties, conflicts, and technical outcomes. The same
rule should apply here. Political-science and process-capture expertise
would help the IETF turn these concerns into systematic questions,
tracked answers, and auditable dispositions rather than personality
contests. I do not know that I would even bother engaging with any of
those other agencies. Part of the issue here is that I expect better of
former NSA, certainly compared with the big names from the other
countries...

Third, the GOST record illustrates why Security Considerations must be
maintained as cryptanalysis changes. RFC 5830, RFC 6986, and RFC 7801
contain minimal Security Considerations, while later work reports a
practical-time related-key attack on GOST 28147-89 with secret S-boxes
[18][19][20][21]. Earlier authors cannot be blamed for later results,
but the IETF still needs a systematic way to warn implementers when a
published security assessment becomes obsolete. The same question
arises for RFC 5831 and RFC 9189 where later analysis may materially
alter the security story [22][23]. Questions about unexplained S-box
provenance and lost generation records are also relevant, just as
parameter provenance was relevant to Dual_EC_DRBG [27]. The standard
should be equal scrutiny for NIST, GOST, and every national source, not
selective silence. Before a draft goes out, a finding that is confirmed
in the WG should be addressed with some text. The finding I raised is
confirmed and unfortunately it can also defeat a hybrid when the
recovered RBG lineage is used to generate the classical private value,
so that neither component remains independent of the compromise. It also
applies to many many other IETF protocols even when the protocol
otherwise did not leak this kind of information.

Fourth, some security-clearance regimes impose reporting obligations
for certain foreign-intelligence, media, or foreign-national contacts.
The DCSA SEAD 3 exercise is expressly limited to contractor personnel
under DoD cognizance, so I do not assume that it applies to you [24]. It
nevertheless demonstrates why the existence and scope of any current
reporting obligation is a factual governance question rather than an
assessment of character. Some foreign participants have told me they
are reluctant to engage because they fear being the subject of foreign
contact reporting requirements that later leads them to be targeted for
trying to improve security of protocols in the IETF. A direct statement
about whether any comparable obligation applies to your IETF contacts
would reduce that concern.

Fifth, the history of Dual_EC_DRBG and Extended Random is directly
relevant. Reuters reported a $10 million NSA contract tied to making
Dual_EC_DRBG the default in RSA BSAFE [26]. This financial history is
why an appeal response focused only on perceptions arising from former
employment is incomplete. Extended Random was coauthored with NSA
participation and was supported in some software, although the
researchers emphasized that they had no evidence that BSAFE versions
with Extended Random support shipped and that it was disabled by default
in the Java version they examined [25]. The concern is not merely which
directorate label a person carried, but what a proposal technically
enabled and whether defensive personnel were separated in practice from
SIGINT-enabling programs. If you were not read into BULLRUN or related
work, a direct statement would be valuable. As we are discussing adding 
a mitigation to the TLS WG ML-KEM drafts under discussion specifically 
related to Dual_EC_DRGBG which was reportedly part of PROJECT BULLRUN. 
If you read this differently, why would you use the term "defect" I 
wonder? I do not understand what you intended by the word “defected,” or 
whether anyone had actually accused you of defecting.


Finally,  If an ongoing obligation preventing an answer also creates an 
actual or potential conflict concerning your IETF work, that conflict 
must be described in general terms or managed through recusal as 
required by [0]. Please clarify.

[0] https://www.ietf.org/about/groups/iesg/iesg-coi-policy/

[1] https://www.ietf.org/administration/policies-procedures/conflict-
interest/coi-disclosures/

[2] https://www.ietf.org/media/documents/Turner_-_REDACTED_-_CoI_-
_Version_1_-_20240117.pdf

[3] https://www.ietf.org/administration/policies-procedures/whistleblower/

[4] https://www.ietf.org/administration/policies-procedures/community-
engagement-policy/

[5] https://www.ietf.org/administration/policies-procedures/code-of-conduct/

[6] https://datatracker.ietf.org/doc/rfc7776/

[7] https://datatracker.ietf.org/person/Deb%20Cooley

[8] https://datatracker.ietf.org/group/iesg/appeals/artifact/125

[9] https://datatracker.ietf.org/group/iesg/appeals/artifact/126

[10] https://datatracker.ietf.org/group/iesg/appeals/artifact/128

[11] https://datatracker.ietf.org/group/iesg/appeals/artifact/129

[12] https://www.rfc-editor.org/info/rfc8713/#section-7

[13] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf

[14] https://pq-crystals.org/kyber/data/kyber-specification-
round3-20210804.pdf

[15] https://datatracker.ietf.org/doc/html/rfc9151

[16] https://mailarchive.ietf.org/arch/msg/tls/ZWTVxeh52P1LoJEHBJp_WTRsVBA/

[17] https://www.spiegel.de/international/germany/inside-the-nsa-s-war-
on-internet-security-a-1010361.html

[18] https://datatracker.ietf.org/doc/html/rfc5830

[19] https://datatracker.ietf.org/doc/html/rfc6986

[20] https://datatracker.ietf.org/doc/html/rfc7801

[21] https://eprint.iacr.org/2023/374

[22] https://datatracker.ietf.org/doc/html/rfc5831

[23] https://datatracker.ietf.org/doc/html/rfc9189

[24] https://www.dcsa.mil/Portals/91/Documents/IS/DISS/
FINAL_SEAD%203%20Contact%20and%20Relationship%20Reporting%20Exercise.pdf

[25] https://www.theregister.com/security/2014/04/02/extended-random-
the-phantom-nsa-rsa-backdoor-that-never-was/1460359

[26] https://www.reuters.com/article/world/exclusive-secret-contract-
tied-nsa-and-security-industry-pioneer-idUSBRE9BJ1C5/

[27] https://who.paris.inria.fr/Leo.Perrin/pi.html

_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]