diff options
Diffstat (limited to 'pelican/content/SecureChannel.md')
| -rw-r--r-- | pelican/content/SecureChannel.md | 13 |
1 files changed, 6 insertions, 7 deletions
diff --git a/pelican/content/SecureChannel.md b/pelican/content/SecureChannel.md index 3f6f1b5..7469716 100644 --- a/pelican/content/SecureChannel.md +++ b/pelican/content/SecureChannel.md @@ -20,41 +20,40 @@ Basic design goals: * 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. -* Provide some form of mutual authentication between client library +* 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 +* 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 @@ -62,10 +61,11 @@ Basic design goals: anything. -* Simple enough that we can implement it easily in HSM, PKCS #11 +* Simple enough that we can implement it easily in HSM, PKCS #11 library, and Python library. + ## Why not TLS? We could, of course, Just Use TLS. Might end up doing that, if it @@ -176,7 +176,6 @@ doing at all, etc. Maybe clients just shouldn't do that. * 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 |