This list might be interested in the draft I proposed to the IETF TLS
working group.
If you think you might implement or benefit from this proposal (or not!)
comments are welcome on the IETF [TLS] list.
- Marsh
------------------------------
http://datatracker.ietf.org/doc/draft-ray-tls-encrypted-handshake/
A new version of I-D, draft-ray-tls-encrypted-handshake-00.txt has been
successfully submitted by Marsh Ray and posted to the IETF repository.
Filename: draft-ray-tls-encrypted-handshake
Revision: 00
Title: Transport Layer Security (TLS) Encrypted Handshake Creation
date: 2012-05-04
WG ID: Individual Submission
Number of pages: 18
Abstract:
This specification defines a Transport Layer Security (TLS) extension
which allows endpoints to negotiate the use of encryption with
forward secrecy at the beginning of the handshake. Two levels of
functionality are defined. Implementations are free to support one
or both levels, with the first level incurring no additional
computational or round-trip overhead. The TLS cryptographic
calculations are unchanged.
------------------------------
This draft is motivated by the discussions in recent weeks, when some
related issues came up in a similar context:
* AGL et al. have some particular requirements for the handshake when
using the NP(N)/SPDY feature. They really need confidentiality in
negotiating the next protocol but they cannot afford the overhead of
even one extra round trip (let alone renegotiation). I would like for
them to be able to implement NP(N) in an RFC-defined way.
* When coupled with the RFC 4680 'TLS Handshake Message for Supplemental
Data' that Martin Rex pointed out, it provides a powerful and very
general way of negotiating features under encryption. It could possible
enable new features.
* Alternatively, we could view this as a round-trip-saving optimization
for certain handshake operations that really do need encryption.
* It allows to encrypt the client certificate without renegotiation,
magic cipher suite values, or a bunch of new protocol that isn't useful
for anything else.
* I watched a fascinating presentation from the Tor project
https://www.youtube.com/watch?v=GwMr8Xl7JMQ
Unfortunately, they are having to minimize their dependence on TLS
because it's so easy to DoS selectively. I don't know if this proposal
will make TLS suitable for Tor again, but I do think it represents a
shortcoming of the protocol which deserves fixing.
* There's simply no reason TLS needs to leak so much plaintext.
* I believe it may help a little with the issue Nikos Mavrogiannopoulos
and I were discussing, where an attacker is able to trick the client
into interpreting the server's signed key exchange parameters as the
wrong type of structure.
* To the implementers in the group: don't be fooled, it's not as big a
change as it looks! I just tried to be extra careful to describe it
step-by-step in the spec. Did I mention it doesn't change the crypto
calculations?
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
