[TLS] Re: Response to CoI Complaints

Hi,

There are literally 4 numbered lists in your (very long) email.  If you can
succinctly and  concisely state a short list of questions, I will entertain
answering them.

In the meanwhile, I will clarify a couple of points.
1.  Ken compared my retirement to Ed Snowden's defection.  The implication
is highly offensive.

2.  I left off two words from my bio section on my CISA work.  Those words
were 'uncleared' and 'unpaid'.  I was not considered to be cleared for that
short position.  My plan was to find a sponsor to pay for the travel
associated with an IESG position.  It didn't work out, so I resigned.
That's it, now, I fund my own travel.  I say that it is funded by my
children's inheritance (I need a logo, BTW - DM me if you have any ideas).

3.  I'm not sure how many ways/times I can say that I worked the Cyber
Security mission.  But there are very few other ways to say this.  CSD does
not equal SIGINT, as much as you seem to want it to.

4.  I will not agree to answer questions on what I had for breakfast, or
how long I walk the dog in the mornings, or other intrusive questions.

Your messages are long and rambling.  Be short and concise, please.

Deb Cooley

On Thu, Jul 16, 2026 at 3:32 PM 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/
> <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
> <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/
> <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
> <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
> <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/
> <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]