Subject: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Tue, 16 Aug 2016 15:19:14 -0600

Hello everyone,

this comment is with respect to the following draft specifying new Diffie-Hellman groups for SSH key exchange:

https://tools.ietf.org/html/draft-ietf-curdle-ssh-kex-sha2-03

The current version of the draft specifies the following:

  diffie-hellman-group14-sha256     MAY/OPTIONAL
  diffie-hellman-group16-sha512     SHOULD/RECOMMENDED
  diffie-hellman-group18-sha512     MAY/OPTIONAL
 
A previous version of this draft specified the following methods:

https://tools.ietf.org/html/draft-baushke-ssh-dh-group-sha2-03

  diffie-hellman-group14-sha256     MAY/OPTIONAL
  diffie-hellman-group15-sha512     MUST/REQUIRED/SHALL
  diffie-hellman-group16-sha512     SHOULD/RECOMMENDED
  diffie-hellman-group17-sha512     MAY/OPTIONAL
  diffie-hellman-group18-sha512     MAY/OPTIONAL
 
Note the presence of additional groups 15 and 17 which were removed in version 4 of the original Baushke draft.

Groups 15 and 17 were removed based on feedback from one implementer. Basically, this feedback was one line:

> +1 to dropping the odd-numbered groups and onlist listing group14/16/18

I would like to counter this, and move to restore the previous table including groups 15 and 17 - or failing that, at least group 15 - with the same parameters as above, in version 3 of the original Baushke draft.

My reasons for proposing this are as follows:

- According to NSA recommendations, the 3072-bit strength would be the current sweet spot between performance and acceptable security. Group 15 is 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit.

- The additional security of group 16 in comparison to group 15 is estimated to be small. Symmetric security estimates I've seen are 80 bits for group 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for group 15 (3072-bit). Based on this, I expect the security of group 16 (4096-bit) to be between 136 - 144 symmetric bits.

- Based on practical measurements, it appears that group 16 is about a factor of 2 slower than group 15. With group 15, I'm getting about 20 full DH key exchanges per second; with group 16, I am getting around 10. I think this difference is significant, and can affect real world usage scenarios on heavily loaded servers.

At this time, I do not have a particular need for group 17 (or 18), but I find it peculiar that this draft would not specify a group that matches the exact recommended DH group size suggested by the NSA. It is weird that we have to choose either between group 14, which does not meet the requirements; or group 16, which is significantly slower.

For our next Bitvise SSH Server and Client versions, I have implemented support for groups 15 as well as 16, where group 15 is implemented with SHA-512, as specified above. When using DH key exchange, our SSH Server will favor group 15, whereas group 16 will be disabled by default for performance (but it will be enabled and preferred in the SSH Client).

denis

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 17 Aug 2016 11:26:28 +0000

>Hellman groups for SSH key exchange:

A further comment on the draft:

   The United States Information Assurance Directorate (IAD) at the
   National Security Agency (NSA) has published a FAQ
   [MFQ-U-OO-815099-15] suggesting that the use of Elliptic Curve
   Diffie-Hellman (ECDH) using the nistp256 curve and SHA-2 based hashes
   less than SHA2-384 are no longer sufficient for transport of Top
   Secret information.  It is for this reason that this draft moves
   ecdh-sha2-nistp256 from a REQUIRED to OPTIONAL as a key exchange
   method. 

So you've got an arbitrary ruling by some random US govt. agency that's
dictating how the entire world's SSH implementations have to function (sigh).
We know from global TLS scans that pretty much the entire planet uses SHA-256,
with SHA-384 and SHA-512 essentially lost in the noise.  However, this spec is
making the universal worldwide standard a MAY and the least-used form of the
entire SHA-2 family a MUST.  If the NSA's IAD wants to use whatever weird
config they decide on they can create their own spec (Suite B, anyone?), but a
global standard should go with whatever the world as a whole has decided on,
and that's overwhelmingly SHA-256.

Peter.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 17 Aug 2016 11:45:14 +0000

Speaking as an individual, I strongly agree with Peter; SHA256 should be MUST and any other variant should be a MAY.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Daniel Migault <[email-masked]>
Date: Wed, 17 Aug 2016 14:15:27 +0000

Hi,

Going briefly through the draft, it seems redundant to have MAY/OPTIONAL, SHOULD/RECOMMENDED, MAY/OPTIONAL.  I am not sure this does not result in a combination of recommendation for the users as well as a recommendation on algorithms to implement. I would recommend we only focus on requirements for algorithm implementation. We should also specify that all non specified algorithms in this document are "MAY".

I have not found any recommendations for these algorithms at the IANA web page [1], nor in another document. If that is the case, maybe this document should clarify this so a status can be assigned for each kex. The IANA page also does not mention all algorithm and I have not found documentation for all suites found in the manual.

Updating the different algorithm should consider two aspects: security and interoperability, which means a SHOULD NOT status is expected to be done for a cipher suite with a SHOULD status. In other words going from MUST to SHOULD NOT should be avoided unless there are strong reasons to do so. So maybe we should do a little bit more cleanup.

I do not know the current status for SSH but it would be good to end up in group1 and SHA1 set to MUST NOT - eventually SHOULD NOT later being updated to MUST NOT.

SHA256 set to MUST, SHA386 to MAY and SHA512 set to SHOULD to have it ready when SHA256 will be replaced.

Maybe we should also consider the current use of the various group, and those not widely used may be set to MAY.

BR,
Daniel

[1] http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16

From: Curdle [mailto:[email-masked]] On Behalf Of denis bider (Bitvise)
Sent: Tuesday, August 16, 2016 5:19 PM
To: Curdle <[email-masked]>
Cc: [email-masked]; [email-masked]; Mark D. Baushke <[email-masked]>
Subject: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2

Hello everyone,

denis

---

From: Watson Ladd <[email-masked]>
Date: Wed, 17 Aug 2016 07:28:56 -0700

On Wed, Aug 17, 2016 at 7:15 AM, Daniel Migault
<[email-masked]> wrote:
> Hi,
>
>
>
>
>
> Going briefly through the draft, it seems redundant to have MAY/OPTIONAL,
> SHOULD/RECOMMENDED, MAY/OPTIONAL.  I am not sure this does not result in a
> combination of recommendation for the users as well as a recommendation on
> algorithms to implement. I would recommend we only focus on requirements for
> algorithm implementation. We should also specify that all non specified
> algorithms in this document are “MAY”.

There must be a single algorithm that everyone is required to
implement. Make it P256 SHA2. Do not make it P384. There are no
efficient constant time implementations. (I have written a constant
time P384 this summer at Mozilla: it is not that fast). By contrast
OpenSSL has a constant time P256 implementation (possibly not used by
default: the rumors are unclear. Can you guys go ahead and ensure that
it is used by default?)

That's on top of everyone uses P256+SHA256.

>
>
>
> I have not found any recommendations for these algorithms at the IANA web
> page [1], nor in another document. If that is the case, maybe this document
> should clarify this so a status can be assigned for each kex. The IANA page
> also does not mention all algorithm and I have not found documentation for
> all suites found in the manual.
>
>
>
> Updating the different algorithm should consider two aspects: security and
> interoperability, which means a SHOULD NOT status is expected to be done for
> a cipher suite with a SHOULD status. In other words going from MUST to
> SHOULD NOT should be avoided unless there are strong reasons to do so. So
> maybe we should do a little bit more cleanup.
>
>
>
> I do not know the current status for SSH but it would be good to end up in
> group1 and SHA1 set to MUST NOT – eventually SHOULD NOT later being updated
> to MUST NOT.
>
>
>
> [1]
> http://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-parameters-16
>
>
>
>
>
> this comment is with respect to the following draft specifying new
> Diffie-Hellman groups for SSH key exchange:
>
>
>
> I would like to counter this, and move to restore the previous table
> including groups 15 and 17 - or failing that, at least group 15 - with the
> same parameters as above, in version 3 of the original Baushke draft.
>
>
>
> - According to NSA recommendations, the 3072-bit strength would be the
> current sweet spot between performance and acceptable security. Group 15 is
> 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit.
>
>
>
> - The additional security of group 16 in comparison to group 15 is estimated
> to be small. Symmetric security estimates I've seen are 80 bits for group 1
> (1024-bit), 112 bits for group 14 (2048-bit), and 128 bits for group 15
> (3072-bit). Based on this, I expect the security of group 16 (4096-bit) to
> be between 136 - 144 symmetric bits.
>
>
>
> - Based on practical measurements, it appears that group 16 is about a
> factor of 2 slower than group 15. With group 15, I'm getting about 20 full
> DH key exchanges per second; with group 16, I am getting around 10. I think
> this difference is significant, and can affect real world usage scenarios on
> heavily loaded servers.
>
>
>
> At this time, I do not have a particular need for group 17 (or 18), but I
> find it peculiar that this draft would not specify a group that matches the
> exact recommended DH group size suggested by the NSA. It is weird that we
> have to choose either between group 14, which does not meet the
> requirements; or group 16, which is significantly slower.
>
>
>
> For our next Bitvise SSH Server and Client versions, I have implemented
> support for groups 15 as well as 16, where group 15 is implemented with
> SHA-512, as specified above. When using DH key exchange, our SSH Server will
> favor group 15, whereas group 16 will be disabled by default for performance
> (but it will be enabled and preferred in the SSH Client).
>
>
>
> denis
>
>
>
>
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 17 Aug 2016 07:30:26 -0700

> and that's overwhelmingly SHA-256.

+1 to Peter's comment. The fact that the NSA has two levels of "must 
never be exposed to anyone" that are poorly understood even within their 
own government doesn't mean that the IETF should follow suit.

--Paul Hoffman

---

From: Daniel Migault <[email-masked]>
Date: Wed, 17 Aug 2016 14:35:40 +0000

If that is the default, it would ease to deprecate what we want to deprecate. And I agree its status should be indicated in the draft.

BR, 
Daniel

-----Original Message-----
From: Watson Ladd [mailto:[email-masked]] 
Sent: Wednesday, August 17, 2016 10:29 AM
To: Daniel Migault <[email-masked]>
Cc: denis bider (Bitvise) <[email-masked]>; Curdle <[email-masked]>; [email-masked]; [email-masked]; Mark D. Baushke <[email-masked]>
Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2

On Wed, Aug 17, 2016 at 7:15 AM, Daniel Migault <[email-masked]> wrote:
> Hi,
>
>
>
>
>
> Going briefly through the draft, it seems redundant to have 
> MAY/OPTIONAL, SHOULD/RECOMMENDED, MAY/OPTIONAL.  I am not sure this 
> does not result in a combination of recommendation for the users as 
> well as a recommendation on algorithms to implement. I would recommend 
> we only focus on requirements for algorithm implementation. We should 
> also specify that all non specified algorithms in this document are “MAY”.

There must be a single algorithm that everyone is required to implement. Make it P256 SHA2. Do not make it P384. There are no efficient constant time implementations. (I have written a constant time P384 this summer at Mozilla: it is not that fast). By contrast OpenSSL has a constant time P256 implementation (possibly not used by
default: the rumors are unclear. Can you guys go ahead and ensure that it is used by default?)

>
>
>
> I have not found any recommendations for these algorithms at the IANA 
> web page [1], nor in another document. If that is the case, maybe this 
> document should clarify this so a status can be assigned for each kex. 
> The IANA page also does not mention all algorithm and I have not found 
> documentation for all suites found in the manual.
>
>
>
> Updating the different algorithm should consider two aspects: security 
> and interoperability, which means a SHOULD NOT status is expected to 
> be done for a cipher suite with a SHOULD status. In other words going 
> from MUST to SHOULD NOT should be avoided unless there are strong 
> reasons to do so. So maybe we should do a little bit more cleanup.
>
>
>
> group1 and SHA1 set to MUST NOT – eventually SHOULD NOT later being 
> updated to MUST NOT.
>
>
>
> Maybe we should also consider the current use of the various group, 
> and those not widely used may be set to MAY.
>
>
>
> BR,
>
> Daniel
>
>
>
> [1]
>> +1 to dropping the odd-numbered groups and onlist listing 
>> +group14/16/18
>
>
>
> including groups 15 and 17 - or failing that, at least group 15 - with 
> the same parameters as above, in version 3 of the original Baushke draft.
>
>
>
> current sweet spot between performance and acceptable security. Group 
> 15 is 3072-bit, whereas groups 14 and 16 are 2048- and 4096-bit.
>
>
>
> - The additional security of group 16 in comparison to group 15 is 
> estimated to be small. Symmetric security estimates I've seen are 80 
> bits for group 1 (1024-bit), 112 bits for group 14 (2048-bit), and 128 
> bits for group 15 (3072-bit). Based on this, I expect the security of 
> group 16 (4096-bit) to be between 136 - 144 symmetric bits.
>
>
>
> factor of 2 slower than group 15. With group 15, I'm getting about 20 
> full DH key exchanges per second; with group 16, I am getting around 
> 10. I think this difference is significant, and can affect real world 
> usage scenarios on heavily loaded servers.
>
>
>
> At this time, I do not have a particular need for group 17 (or 18), 
> but I find it peculiar that this draft would not specify a group that 
> matches the exact recommended DH group size suggested by the NSA. It 
> is weird that we have to choose either between group 14, which does 
> not meet the requirements; or group 16, which is significantly slower.
>
>
>
> For our next Bitvise SSH Server and Client versions, I have 
> implemented support for groups 15 as well as 16, where group 15 is 
> implemented with SHA-512, as specified above. When using DH key 
> exchange, our SSH Server will favor group 15, whereas group 16 will be 
> disabled by default for performance (but it will be enabled and preferred in the SSH Client).
>
>
>
> denis
>
>
>
>

---

From: Phill <[email-masked]>
Date: Wed, 17 Aug 2016 10:55:18 -0400

I think we are getting into the weeds here. The point of standards is to ensure interoperability. The only reason NIST/NSA has any particular significance is that they have a lot of users of crypto and they have a huge amount of purchasing power.

From an IETF perspective, I want exactly two algorithm choices, one that is very secure and one that is ridiculously secure. I see no value in IETF endorsing anything else. By ‘very secure’ I mean a work factor of 2^128 (WF128) and by ridiculously secure I mean a work factor of 2^256. In the age when Quantum Computing is starting to look as if it may be feasible, a 2^256 () conventional work factor isn’t insane.

So I see 6 classes of crypto

1a) MUST NOT: Stuff we know is bad and there is no reason to use (MD4 etc.)
1b) SHOULD NOT: Stuff we know is bad but is still needed for some legacy systems (SHA-1)
2) MUST: The algorithm we think everything should support (SHA-2-256)
3) SHOULD: The backup algorithm (SHA-2-512)
4) MAY: Anything else that a client might need for interop in specific environments.
5) - : That of which we remain silent (most algorithms)

Rather than reading NIST docs and trying to interpret them, why not ask NIST to write a draft specifying the set of suites to use and publish it themselves or as a FIPS. 

The thing is that we don’t have change control for that particular use area and don’t want it.

One set of choices I think we can dispense with is work factor WF192 crypto. I can’t see any point to it. Either performance matters a lot or it does not. If performance matters then you are going to be sticking to WF128 algorithms. If not there is really no reason not to go to WF256. Which is what I do anyway.

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Wed, 17 Aug 2016 16:18:09 -0600

I perceive a substantial problem in the current tendency of IETF to try to serve as a recommender, or even an authority on best practice, instead of serving as a documenter and a dispassionate record of existing work. When I implement a program or a solution, I do not ask the IETF for suggestions on what to implement. I decide what to implement based on real-world considerations that apply in my usage case, and then consult IETF for documentation – if any! – relating to the thing I’ve decided.

I find there’s a disproportionate attitude, in this group and elsewhere, presuming that the protocols that IETF documents are IETF protocols. This is not the case. The IETF is not the final authority on its protocols, the users are; and before the users, the implementers. To the extent that the IETF wishes to not be obsolete, it must submit to these final authorities, and document the protocols in the way they are actually used, rather than in a way that seems to elevate the judgments of people involved in the IETF process.

The refusal of IETF to serve this role results in useful specifications not ever making it to RFC, so that the role that used to be served by documents in the RFC status (note that this stands for “Request for comments”!) is now increasingly being served by hypothetically expiring Internet-Drafts, which really serve as actual specifications for widely used internet protocols, such as SFTP, because all we really want from a standards organization is the ability to coordinate, and we are not so much interested in its efforts to pontificate, opinionate, and mandate what’s to be done in practice.

The reason I say this is because the US federal government represents a big chunk of end users who actually pay for software development, and from the best of my impressions, their current recommendations appear very reasonable. Based on articles that are now coming out with respect to progress in the development of quantum computing, real quantum computers are just around the corner, and when they arrive, 256-bit elliptic curves that we are now recommending as “MUST” everywhere will be the first to go. Guess which national intelligence organization will be the first to have their own quantum computers, and apply them generously to all of the Curve25519 traffic that they will have recorded in preceding years, ready for cracking in their ample storage?

The desire to completely ignore the NSA just because they are not entirely our ally is highly questionable, and counter-productive. Chances are that they have more information about crypto cracking and the future of quantum computing than any of us, and not only have a good idea of the timeline, but also what they are going to do with it. They are better informed about their own abilities than we are, so if they say folks should use 3072-bit RSA and DH, and at least 384-bit hash functions, I reckon we’re taking chances when we don’t listen.

A big chunk of users are going to heed these recommendations, and are going to need a standards body that accommodates them. NIST is not going to publish a spec on how to use 3072-bit DH with SHA-512 in SSH. But as an implementer, I need to do this, and if IETF will not address this case, then – why would I need IETF, or respect any of its specifications?

From: Phill 
Sent: Wednesday, August 17, 2016 08:55
To: Paul Hoffman 
Cc: Curdle ; Peter Gutmann 
Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 17 Aug 2016 15:33:58 -0700

On 17 Aug 2016, at 15:18, denis bider (Bitvise) wrote:

> A big chunk of users are going to heed these recommendations,

It is developers that need the standards, not the users. The users will 
demand that certain standards they have heard of or are required to use 
in the software they purchase or download.

> and are going to need a standards body that accommodates them.

s/a standards body/standards/  If the IETF does not encode a standard 
that Some Government demands, someone else (hopefully That Government) 
will fill the gap.

> NIST is not going to publish a spec on how to use 3072-bit DH with 
> SHA-512 in SSH.

That seems like a harsh statement. NIST had multiple publishing arms; 
they could do it easily. Also, NIST has more than a handful of people 
who know how to write Internet-Drafts that could become Informational 
RFCs specifying how to implement what they want.

> But as an implementer, I need to do this, and if IETF will not address 
> this case, then – why would I need IETF, or respect any of its 
> specifications?

You don't "need" the IETF unless you want to follow the IETF's 
standards. If you have a better way to publish standards that are 
accepted by other developers who want to interoperate with you, you 
should do so. I say that in all seriousness: if you do a good job, the 
IETF can learn about our failings. (FWIW, I say this as a happy paying 
customer for your software.)

--Paul Hoffman

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Wed, 17 Aug 2016 16:47:05 -0600

Paul:

> IETF can learn about our failings. 

Indeed, the thought has crossed my mind several times, but I’d rather not have to. It would be much more efficient if the existing standards body were to accept a more generous understanding of its role, especially given that its flaws are incidental more so than fundamental. Trying to improve existing systems is often frustrating, but if successful, it’s more effective than creating a new one.

> (FWIW, I say this as a happy paying customer for your software.)

Much appreciated. :-)

From: Paul Hoffman 
Sent: Wednesday, August 17, 2016 16:33
To: denis bider 
Cc: Curdle 
Subject: Re: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2

--Paul Hoffman

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 17 Aug 2016 23:40:51 +0000

Denis,

Are the others who share your views?  This isn’t the first time you’ve expressed it, but from my limited viewpoint, it seems to not be shared.

I also find some inconsistency in your message; how can the IETF mandate Internet interoperability without doing things like MUST, and thereby it, well, MUST serve as a recommender, no?

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Wed, 17 Aug 2016 19:50:05 -0600

Hello Rich,

I don’t know; I guess I’m here to find out.

Quite possibly, I’m not going to find out, because people who share my views might not be here in the first place. There’s a selection bias in any volunteer group, and this may make the group look very different from a random population sample.

It also makes for an echo chamber. Groups will normally attract people who are in sync with the dominant group values, and repel people who are not quite.

The dominance of the group’s values does not mean the values are preferrable, or good, or justified. It does not mean these values are even helpful to the group’s ostensible purpose.

Often, groups are ostensibly about one thing, but really about another. I don’t agree with Robin Hanson about the extent to which all human motivation revolves around seeking status. However, there is a kernel of truth in that a lot of activity that is ostensibly about lofty things, is in fact about seeking status. Academia. Volunteerism. Participation in standards bodies.

The work we’re doing here should not be interesting, or flattering. We should not be here to put our names on things. We are here to serve the community by documenting things, not to exercise power by judging and mandating. That is a role for a different, more ephemeral authority, that does not at the same time try to assume the role of the internet’s main documenter of how things work.

Specifications are forever; judgments last about 3 weeks.

denis

From: Salz, Rich 
Sent: Wednesday, August 17, 2016 17:40
To: denis bider (Bitvise) ; Curdle 
Subject: RE: [Curdle] Group 15 needed in draft-baushke-ssh-dh-group-sha2

Denis,

--

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 18 Aug 2016 13:28:26 +0000

denis bider (Bitvise) <[email-masked]> writes:

>The refusal of IETF to serve this role results in useful specifications not
>ever making it to RFC, so that the role that used to be served by documents
>in the RFC status (note that this stands for “Request for comments”!) is now
>increasingly being served by hypothetically expiring Internet-Drafts, which
>really serve as actual specifications for widely used internet protocols,
>such as SFTP, because all we really want from a standards organization is the
>ability to coordinate, and we are not so much interested in its efforts to
>pontificate, opinionate, and mandate what’s to be done in practice.

Too true, sigh.  The sixteen-year fiasco that is SCEP and my attempt to get
TLS-LTS adopted are other examples of this.
 
>The desire to completely ignore the NSA just because they are not entirely
>our ally is highly questionable, and counter-productive. 

It has nothing to do with their motives.  The NSA are one single organisation
that deals with crypto among an ocean of organisations that deal with crypto,
and in particular one that doesn't exactly have a good track record of backing
workable crypto standards (CCEP, Clipper, Fortezza, Suite B, is there anything
that they - not NIST - have pushed that's actually gone anywhere?).  If we're
going to jump whenever the NSA says so, why shouldn't we do the same for the
FSB, DSD, CESG, BSI, ANSSI, FRA, NSM, MSS, NICRD, and an entire other alphabet
soup of government agencies, not to mention the 13 pages of industry bodies
who'd all like their pet algorithms included in anything that gets
standardised?  Why build the NSAs wish list into SSH but not the IAGR (that's
"International Association of Gaming Regulators", who are actually involved in
crypto standardisation work)?

If someone really wants their pet algorithm baked into SSH, they can write the
profile themselves.  The IETF is here to serve the needs of the people that
contribute to it and, in turn, their users/customers, not to rule that
everyone has to use whatever someone's guess as to the wishes of one specific
US government agency is.  It's not even as if we've had anyone from the NSA
ask for this, it's just your guess at what the NSA might in theory want if
someone asked them.

Peter.