[TLS] Re: Response to CoI Complaints

(apologies to the TLS list for more noise - I’ll try to push further discussions to admin-dicuss)

Jacob

I was planning to say much the same as Deb (and no we haven’t discussed it).  I’m very happy to answers questions but not when there’s a high burden on me to work out just what I’m being asked.  Also, I am unwilling to answer questions in a thread with such extraordinarily intrusive questions to another IETF participant as I do not want to be seen to legitimise that behaviour.  

Putting that all together, please send me a much shorter and focused set of questions, separate from any questions to anyone else and please either do so directly or cc the admin-discuss list as the proper venue for discussion of this IETF LLC policy.

Jay

> On 16 Jul 2026, at 21:32, Jacob Appelbaum <[email protected]> wrote:
> 
> 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

-- 
Jay Daley
[email protected]
www.ietf.org



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