Markdown syntaxHEADmaster

Continuation paragraph in list is sensitive to indentation level

1 files changed, 36 insertions, 58 deletions

diff --git a/content/SecureChannel.md b/content/SecureChannel.md
index 6a40c63..e484720 100644
--- a/content/SecureChannel.md
+++ b/content/SecureChannel.md
@@ -13,57 +13,42 @@ pieces are still missing.
 
 Basic design goals:
 
+*   End-to-end between client library and HSM.
 
-* End-to-end between client library and HSM.
+*   Not require yet another presentation layer if we can avoid it (so,
+    reuse XDR if possible, unless we have some strong desire to switch
+    to something else).
 
+*   Provide end-to-end message integrity between client library and HSM.
 
+*   Provide end-to-end message confidentiality between client library
+    and HSM.  We only need this for a few operations, but between PINs
+    and private keys it would be simpler just to provide it all the
+    time than to be selective.
 
-* Not require yet another presentation layer if we can avoid it (so,
-  reuse XDR if possible, unless we have some strong desire to switch
-  to something else).
+*   Provide some form of mutual authentication between client library
+    and HSM.  This is tricky, since it requires either configuration
+    (of the other party's authenticator) or leap-of-faith.
+    Leap-of-faith is probably good enough for most of what we really
+    care about (insuring that we're talking to the same dog now as we
+    were earlier).
 
+    Not 100% certain we need this at all, but if we're going to leave
+    ourselves wide open to monkey-in-the-middle attacks, there's not
+    much point in having a secure channel at all.
 
+*   Use boring simple crypto that we already have (or almost have) and
+    which runs fast.
 
-* Provide end-to-end message integrity between client library and HSM.
-
-
-
-* Provide end-to-end message confidentiality between client library
-  and HSM.  We only need this for a few operations, but between PINs
-  and private keys it would be simpler just to provide it all the time
-  than to be selective.
-
-
-
-* Provide some form of mutual authentication between client library
-  and HSM.  This is tricky, since it requires either configuration (of
-  the other party's authenticator) or leap-of-faith.  Leap-of-faith is
-  probably good enough for most of what we really care about (insuring
-  that we're talking to the same dog now as we were earlier).
-
-
-  Not 100% certain we need this at all, but if we're going to leave
-  ourselves wide open to monkey-in-the-middle attacks, there's not
-  much point in having a secure channel at all.
-
-
-* Use boring simple crypto that we already have (or almost have) and
-  which runs fast.
-
-
-
-* Continue to support multiplexer.  Taken together with end-to-end
-  message confidentiality, this may mean two layers of headers: an
-  outer set which the multiplexer is allowed to mutate, then an inner
-  set which is protected.  Better, though, would be if the multiplexer
-  can work just by reading the outer headers without modifying
-  anything.
-
-
-
-* Simple enough that we can implement it easily in HSM, PKCS #11
-  library, and Python library.
+*   Continue to support multiplexer.  Taken together with end-to-end
+    message confidentiality, this may mean two layers of headers: an
+    outer set which the multiplexer is allowed to mutate, then an
+    inner set which is protected.  Better, though, would be if the
+    multiplexer can work just by reading the outer headers without
+    modifying anything.
 
+*   Simple enough that we can implement it easily in HSM, PKCS #11
+    library, and Python library.
 
 ## Why not TLS?
 
@@ -84,14 +69,12 @@ tweaked in places to fit tools we have readily available.
 
 Toolkit:
 
-
 * AES
 * SHA-2
 * ECDH
 * ECDSA
 * XDR
 
-
 As in the book, there are two layers here: the basic secure channel,
 moving encrypted-and-authenticated frames back and forth, and a higher
 level which handles setup, key agreement, and endpoint authentication.
@@ -165,18 +148,13 @@ doing at all, etc.  Maybe clients just shouldn't do that.
 
 ## Open issues
 
+*   Does the resulting design pass examination by clueful people?
 
-* Does the resulting design pass examination by clueful people?
-
-
-
-* Does this end up still being significantly simpler than TLS?
-
-
+*   Does this end up still being significantly simpler than TLS?
 
-* The Cryptography Engineering protocols include a hack to work around
-  a length extension weakness in SHA-2 (see section 5.4.2).  Do we
-  need this?  Would we be better off using SHA-3 instead?  The book
-  claims that SHA-3 was expected to fix this, but that was before NIST
-  pissed away their reputation by getting too cosy with the NSA again.
-  Over my head, ask somebody with more clue.
+*   The Cryptography Engineering protocols include a hack to work
+    around a length extension weakness in SHA-2 (see section 5.4.2).
+    Do we need this?  Would we be better off using SHA-3 instead?  The
+    book claims that SHA-3 was expected to fix this, but that was
+    before NIST pissed away their reputation by getting too cosy with
+    the NSA again.  Over my head, ask somebody with more clue.