Update TLS coverage to 1.3

Author: drbruced12

crypto.rst

@@ -598,6 +598,8 @@ recomputed code to the code received in the message.
 
    Computing a hashed message authentication code (HMAC).
 
+.. this appears to be out of date, see https://en.wikipedia.org/wiki/HMAC#Design_principles   
+
 One way to implement the approach just described is to apply a cryptographic hash (such as
 SHA-3) to the concatenation of the plaintext message and the
 secret value, as illustrated in :numref:`Figure %s
@@ -624,13 +626,13 @@ In recent years, the idea of using a single algorithm to support both
 authentication and encryption has gained support for reasons of
 performance and simplicity of implementation. This is referred to as
 *authenticated encryption* or *authenticated encryption with
-associated data*. The latter term allows for some data fields
-(e.g., packet headers) to be transmitted as plaintext—these are the
-associated data—while the rest
-of the message is encrypted, and the whole thing, headers included, is
-authenticated. We won't go into details here, but there is now a set of
-integrated algorithms that produce both ciphertext and authentication
-codes using a combination of ciphers and hash functions.
+associated data*. The latter term allows for some data fields (e.g.,
+packet headers) to be transmitted as plaintext—these are the
+associated data—while the rest of the message is encrypted, and the
+whole thing, headers included, is authenticated. We won't go into
+details here, but there is now a set of integrated algorithms that
+produce both ciphertext and authentication codes using a combination
+of ciphers and hash functions.
 
 If you want to get a deeper understanding of the principles of ciphers
 and hash functions, among other cryptographic concepts, we recommend the following book.

figures/SecurityFigs.pptx

@@ -373,9 +373,11 @@ end-users to authenticate themselves with public key cryptography, but
 if you need to authenticate yourself to, say, your bank, it's
 overwhelmingly the case today that you will use some combination of
 user name (maybe an account number or an email address) and a
-password. Encryption (using TLS) prevents your password from being
-seen by eavesdroppers when it is sent to the bank's site, but we
-normally don't use public key cryptography to authenticate users.
+password. Perhaps another factor such as a one-time code sent to your
+phone will also be used. Encryption (using TLS) prevents your password
+from being seen by eavesdroppers when it is sent to the bank's site,
+but currently there is little deployment of public key cryptography
+for the authentication of users.
 
 Password-based authentication had proven enormously problematic, with
 passwords frequently being compromised by a variety of attacks. If a
@@ -393,11 +395,11 @@ to the expected one, on a site that mimics the visual style of the
 legitimate web site.
 
 A range of efforts have been under way for many years to reduce the
-reliance on passwords and to drive adoption of public key
-cryptography. The most visible recent development has been the
-appearance of *passkeys*, which, as the name suggests, are a form of
-user authentication that replaces passwords with public key-based
-authentication.
+reliance on passwords and to drive adoption of public key cryptography
+for end-user authentication. The most visible recent development has
+been the appearance of *passkeys*, which, as the name suggests, are a
+form of user authentication that replaces passwords with public
+key-based authentication.
 
 .. can add a figure here
 
@@ -436,6 +438,13 @@ coming from the correct web site using the standard authentication
 methods of TLS. A fraudulent web site will fail this check, so the
 user will not try to authenticate to the site.
 
+Of course, if passkeys are to be effective as a phishing-prevention
+tool, they need to *replace* passwords, not just supplement them. If
+passwords remain available as an alternative, it seems safe to assume
+that attackers will keep using that option to breach user
+accounts. This is one of the problems that needs to be addressed in
+the deployment of passkeys.
+
 
 The WebAuthn spec allows for considerable implementation flexibility,
 but there are two broad categories of passkey implementation. One
@@ -460,7 +469,7 @@ password manager and then is made available to the user across
 different devices (laptops, mobile phones, etc.) when they need the
 passkey.
 
-Both approaches have their strengths and weaknesses. Hardware tokens
+There are strengths and weaknesses for each approach. Hardware tokens
 make phishing attacks almost impossible, since the only way to get
 access to the user's credential is to have physical access to the
 key. A password manager, on the other hand, is a piece of software