diff options
| -rw-r--r-- | content/SecureChannel.md | 94 |
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. |