Hi Bryan,
I guess Dmitry is talking about the trick when each datagram is encrypted with
its own key,
derived from the "master" session key using some unique public parameter of the
datagram,
like its sequence_number. This trick makes attacks on encryption key almost
useless.
It is not specifically bound to GOST cipher, however it is sometimes used with
this cipher
to deal with its short (by current standards) block size. See for example the
(now expired) draft
https://www.ietf.org/archive/id/draft-fedchenko-ipsecme-cpesp-gost-04.txt
(it is about ESP, but the general principles are the same for DTLS).
As far as I understand your proposal makes impossible to use this trick,
if we consider packets loss and reordering.
Regards,
Valery Smyslov.
From: Bryan Ford
To: Dmitry Belyavsky
Cc: tls@ietf.org
Sent: Wednesday, December 02, 2015 12:11 PM
Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re:
Encrypting record headers: practical for TLS 1.3 after all?)
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> 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
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
------------------------------------------------------------------------------
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
