(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]
