Hi,
On the 8th of March 2009 I posted on this mailing list to engender
feedback on a roughly sketched proposal to add symmetric key exchanges
using pre-shared secrets to the SSL/TLS protocol. Our objective was
to enhance SSL/TLS to offer a post quantum secure mode of operation.
We sought to achieve this with symmetric protocols using standards
based ciphers already trusted by the crypto community to be post
quantum secure. The protocols would perform key exchanges, while
ensuring a) that the enhanced SSL/TLS protocol remained interoperable
with unmodified SSL/TLS implementations and b) that the modified
protocol did not interfere with the stability of the established SSL/
TLS user base.
I received excellent constructive feed back to that earlier posting,
and I wish to thank the OpenSSL list for their replies. In that feed
back I received some advice on my initial proposal outline and links
to related efforts performed by others around TLS-PSK such as the work
by Pascal Urien http://www.infres.enst.fr/~urien/openeapsmartcard/ .
I also wish to acknowledge Ger Hobbelt's feedback that flagged caution
with adding new protocols within the SSL/TLS framework.
I have looked at the TLS-PSK protocol, carefully reviewed the OpenEAP
Smart card technologies, and continued to evaluate our project's
requirements and objectives. I have also been watching the list and
taken an interest in the discussions around FIPS 140 certification.
In my original posting I sketched a system that would selectively use
PSK techniques and fall back to public key techniques if PSK wasn't
present.
However, there now appears to be some major downsides to this approach:
* Building a proprietary extension within the SSL/TLS universe would
result in a maintenance overhead either to the SSL/TLS community (if
it chose to integrate it), or to us to ensure patches continue to work
with new releases.
* Organisations that require their data to be protected using FIPS 140
"Authorised" security functions and modes of operations couldn't take
advantage of the proprietary extension in this form.
* Any FIPS 140 OpenSSL certified products that wanted to support the
proprietary extension would need to be re-certified.
We recognise and acknowledge the requirements of organisations to
deploy and maintain FIPS 140 certified security products. Since FIPS
140 crypto systems that use Authorised public key technologies are not
secure against code-breaking quantum computers, and since currently
recorded SSL/TLS traffic may therefore be decrypted at a later time,
the optimum way forward would seem be to provide the post quantum
security enhancement using a FIPS certified module running a “non-
Authorised” post processing step.
The post processing step we are now exploring is to build a SSL/TLS
protocol-specific secure tunnel (exoskeleton / inline filter) that
wraps around and protects the at-risk cryptographic components without
modifying FIPS approved modules or implementations of SSL/TLS products.
This would leave the existing SSL/TLS FIPS approved solutions
unchanged and would continue to guarantee the existing FIPS base-line
level of security.
The PQS-exoskeleton sitting on the network facing side of the SSL/TLS
connections on the client and sender sides would monitor the hand-
shake operations and the choice of negotiated ciphers. To achieve
post quantum security it would double-encrypt the existing at-risk
components using symmetric techniques known and accepted by the crypto
community to be Post Quantum Secure e.g. Double-encrypting RSA or ECC
key exchange and digital certificate ciphertext using AES-256-CTR.
With regards to network performance, by actively monitoring the length
fields of the TLS Record Protocol we can ensure that the network
session transmission buffers are flushed at the right time. The post
quantum secure tunnel would also have to match TCP/UDP modes as
appropriate.
We welcome any feed back and advice on this revised approach.
Does anyone have experience or knowledge of writing tunnels for SSL/
TLS (such as in wireless networks, virtual private networks, etc)?
Also, if anyone can point us to related published work that would be
appreciated too.
In addition to the pqs-exoskeleton tunnel we are also exploring auto
detection within this framework. The details are as follows. We are
thinking of registering a new cipher suite (e.g., TLS_PQS_TUNNEL)with
IANA (RFC 2434) corresponding to the post quantum secure tunnel (PQS-
tunnel) mode of operation. When a new SSL request is received by the
PQS-tunnel, the PQS-tunnel would open a network session sending a
hello request to the targeted recipient, asking for just the PQS-
tunnel mode of operation.
If the receiving end doesn't recognise the PQS-tunnel cipher suite,
then the receiver would follow the existing protocol specifications
and send a “handshake_failure” message and the network session would
be closed gracefully. The PQS-tunnel on the sending end would then
send the original SSL hello message over a second independent network
session. This process would be fast and could trigger a notice to the
SSL user that a PQS-tunnel has been affected or not, allowing the
option/choice on whether to continue with the connection or not. (It
would also be possible to preemptively open the second socket
connection without sending the hello message until the first session
failed. This would have a very low overhead on the receiving side and
keep latencies low. The protocol could also cache the result of the
first query to prevent double-checking on every socket connection to
that IP:Port address.)
In the event that the receiving end does respond positively to the
first hello, then a PQS-tunnel is negotiated and within that tunnel
the original SSL/TLS messages would be relayed with the at-risk
sections double-encrypted.
In both cases, whether or not the PQS-tunnel is implemented, the
messages of the hand shake protocol would appear untouched to the SSL/
TLS implementations, ensuring the handshake message digests match and
that all original security properties (such as FIPS Authorised) were
maintained.
We anticipate that a draft RFC may need to be written so that the
TLS_PQS_TUNNEL enumeration could openly support different protocols /
versions over time through IANA.
We welcome the communities feedback and advice on the above approach
for the auto detection strategies. Also, if anyone has attempted
similar work that they can share with us, or if anyone can point us to
published work in this area, then that will also be appreciated.
Lastly, if there are members of the list that are interested in double-
checking our design proposals as they mature to ensure they do not
interfere with your community, please contact us.
We have taken on board Ger Hobbelt's suggestion that the discussion
may get more active responses in the TSL/SSL listing. We will send a
revision of this posting to that list and will shift our discussions
into that list unless we have a message that is highly targeted to
implementation issues with OpenSSL in particular.
Once again, thank you for the feed back on our earlier proposal and we
look forward to hearing your thoughts now on this new approach.
Thanks and best regards,
Benjamin Gittins
Chief Technology Officer
Synaptic Laboratories Limited
W: http://synaptic-labs.com
W: http://vestciphers.com
W: http://hardware-ciphers.com
E: c...@pqs.io
T: +356 9944 9390 (mobile)
TZ: CET (UTC+1)
This email and its zero or more attachments contains confidential
material.
If you receive this email in error, please contact me immediately.
