Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

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 <beldmit@gmail.com> wrote:

    On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford <brynosaurus@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