aboutsummaryrefslogtreecommitdiff
path: root/content
diff options
context:
space:
mode:
authorRob Austein <sra@hactrn.net>2023-02-15 10:33:04 -0500
committerRob Austein <sra@hactrn.net>2023-02-15 10:34:05 -0500
commit9541525e51d1c47806d2daebb8a9736a9b6cd4dc (patch)
tree3bcfb3bbbdad46407f3538d1633e984e279684ba /content
parentac0c73f9b6ef6b399fa65e0c6e972f37be5e67bb (diff)
Markdown syntaxHEADmaster
Continuation paragraph in list is sensitive to indentation level
Diffstat (limited to 'content')
-rw-r--r--content/SecureChannel.md94
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.