On 02 Dec 2015, at 09:42, Dmitry Belyavsky <beld...@gmail.com> wrote: > On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford <brynosau...@gmail.com > <mailto:brynosau...@gmail.com>> wrote: > On 12/1/15 9:49 PM, Dmitry Belyavsky wrote: > > Dear Bryan, > > > > DTLS: > > > > Now there's still the important question of whether this (new) proposal > > could be made to work in the context of DTLS. For the DTLS case, my > > current thinking is that some elements of my earlier proposal is > > probably more suitable: namely using a stream cipher (or AEAD used as a > > stream cipher) to encrypt and recognize the explicitly-transmitted > > sequence numbers that DTLS needs. This could operate basically the same > > as I described in my earlier E-mail on this topic. Note that the length > > field is no longer a problem in DTLS as it is in TLS, because the > > receiver already gets the length of the datagram from UDP. > > > > > > Do I understand correctly that your propose makes difficult to derive > > the key from the original value depending on the sequence number? > > I'm not sure I understand your question; can you clarify? What is the > "original value" you are worried about the key being derivable from? > Certainly if the cipher (stream cipher or AEAD) is working correctly, it > should make it cryptographically infeasible for an attacker to derive > the shared secret key from anything the protocol transmits. > > I mean something like http://tools.ietf.org/html/rfc4357#section-7 > <http://tools.ietf.org/html/rfc4357#section-7> > We have the keys calculated during the handshake and want to modify it for > each record.
Hmmm - the RFC you point to is about the GOST cipher, and section 7 seems to be about “secret key diversification”, but I know nothing about GOST other than that it’s a cipher and it’s not obvious to me what exactly “secret key diversification” means here or what exactly it has to do with TLS (which works with many different ciphers). I guess I still need a more detailed clarification of your question if I’m going to be able to try to answer it. B > > > -- > SY, Dmitry Belyavsky
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
