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

"Valery Smyslov" <> Fri, 04 December 2015 06:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CAE1C1B2E27 for <>; Thu, 3 Dec 2015 22:56:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.229
X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hLB1zuOFGFtW for <>; Thu, 3 Dec 2015 22:56:35 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77E211B2E25 for <>; Thu, 3 Dec 2015 22:56:34 -0800 (PST)
Received: by lbbkw15 with SMTP id kw15so15118144lbb.0 for <>; Thu, 03 Dec 2015 22:56:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=Kf1WCWm4NzGc7XoZvTRWN5oIRIVkQSRkToZ99oFykyU=; b=hJIwuS0LoYriTtWIEEQYXuhqS01oajPNAnCu//HkUnkIUNAqlwBxfoeO7u9vuiUe4n C4hU/nCTz3qP7Sx/Q7k7Vsu3/9PfdwbTumXdRrZsjVRjIpgawhuFst32sapNqmWr+aBk of/iPOvnYxCl0XH03tXwPk+MKEFxWvKP/wKQCBpesPeKBbwENcN+/fN1Nq35CahxQwCp QfZ5+EQJmNL3LDMihu5fq2lyvOMkzQIh/qZsNWYOBkC+/MXjcrJ/613ilhp5Fbxi78Uh RlAFCrFBeombhstpJZJIQk/6AVQ51TqLmQkgppLzSYdejb4imRRtwITVm8tjU5e9umfp iqPw==
X-Received: by with SMTP id tn5mr7274296lbb.47.1449212192721; Thu, 03 Dec 2015 22:56:32 -0800 (PST)
Received: from buildpc ([]) by with ESMTPSA id d203sm2014870lfg.39.2015. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Dec 2015 22:56:31 -0800 (PST)
Message-ID: <7F6CAD8F92F54AD5A4F6B14D5F471740@buildpc>
From: Valery Smyslov <>
To: Bryan Ford <>, Dmitry Belyavsky <>
References: <> <> <> <> <> <> <> <>
Date: Fri, 04 Dec 2015 09:56:29 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0BA6_01D12E7A.0C5D3D60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: <>
Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Dec 2015 06:56:37 -0000

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
(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.

Valery Smyslov.

  From: Bryan Ford 
  To: Dmitry Belyavsky 
  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 <> wrote:

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



    SY, Dmitry Belyavsky


  TLS mailing list