Added blurb on crypto primitive negotiation

README.md

@@ -47,6 +47,14 @@ Currently supported session algorithms:
 * HMAC-SHA256
 * HMAC-SHA512
 
+### Wait. You offer a lot of cryptographic primitives there. According to some, 'Cipher-agility' is considered bad in 2021. What gives?
+
+An interesting question. See [this write-up for a discussion](https://paragonie.com/blog/2019/10/against-agility-in-cryptography-protocols).
+
+xs implements the philosophy that it is the server admin's prerogitive to allow or deny connection using any particular combination of cryptographic primitives. The protocol makes no allowance for any sort of 'downgrades' or algo substitution during negotiation. The 'negotiation', if you can even call it that, is precisely: (client proposes a KEX, session cipher alg and hash) -- (server accepts or refuses and drops connection). If the server admin wishes, xsd (server) can accept any supported configuration, or a subset, or exactly one.
+
+Furthermore, the code allows no accidental or implied 'sliding' between one configuration and another -- there is no 'fallback' mode or two-way negotiation of what primitives to use (which would open the possibility of downgrade attacks). HOWEVER, the current code does default to the server (xsd) allowing 'all' combinations unless command-line switches give a restriction list. Perhaps I will invert that, and require a list of allowed configurations instead. This is trivial to implement with the current architecture.
+
 
 ### Conn
 Calls to xsnet.Dial() and xsnet.Listen()/Accept() are generally the same as calls to the equivalents within the _net_ package; however upon connection a key exchange automatically occurs whereby client and server independently derive the same keying material, and all following traffic is secured by a symmetric encryption algorithm.