Re: [TLS] rfc7366: status

Peter Gutmann <> Sun, 07 December 2014 03:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6E9621A7032 for <>; Sat, 6 Dec 2014 19:09:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9xhLttUl9rnt for <>; Sat, 6 Dec 2014 19:09:17 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CEDF1A802A for <>; Sat, 6 Dec 2014 19:09:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1417921756; x=1449457756; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=YMPR0ylEBO/0T9thVZN/g5tUYouU1hdhKML6vT9t7kA=; b=h+XDd3mZeXwdIik8k5dMUC44Q/cB96VTvPAybjDaAfZM4Bf3FDi6Twr1 3qd/r/1x2wPD6yJQ1CBVHf+IZzpGZ4nG3CFbu3pLbuNEELxP60QBdUN3O hzjrWtxS9bJ7P2sxAdcJ6YuhdPyMV0KDnhTLEj0TaLw6EFcTnRJaxsyL4 s=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="295298635"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 07 Dec 2014 16:09:14 +1300
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Sun, 7 Dec 2014 16:09:14 +1300
From: Peter Gutmann <>
To: "<>" <>
Thread-Topic: rfc7366: status
Thread-Index: AdARyy2xBUfdikGMR7uNIL1XUxOQjA==
Date: Sun, 07 Dec 2014 03:09:13 +0000
Message-ID: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] rfc7366: status
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: Sun, 07 Dec 2014 03:09:23 -0000

Nikos Mavrogiannopoulos <> writes:

>Is there any update on RFC7366 errata process? Is there a plan to update the
>existing text?

I'd sent the following as a private message to some of the people involved in
the discussion, I haven't had any feedback yet so I guess it's OK?  In that
case I'll submit it as an update...

-- Snip --

Note that the length value used for the MAC computation differs from the
length value as encoded on the wire since the MAC value is not included in the
MAC computation.  The value of the 'uint16 length' field in the TLSCiphertext
record therefore differs from the length value used in the MAC calculation,
since the TLSCiphertext record contains both the ciphtertext and the MAC,
while the MAC calculation is performed only over the ciphertext.  The length
value encoded in the TLSCiphertext record is therefore 'length' while the
length value used in the MAC calculation is 'length -

More formally, if:

  TLSCiphertext.content = ENC(content + padding + padding_length)

then in TLS notation the MAC calculation for TLS 1.0 without the explicit
Initialization Vector (IV) is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (TLSCiphertext.content) +

and for TLS 1.1 and greater with an explicit IV is:

   MAC(MAC_write_key, seq_num +
       TLSCipherText.type +
       TLSCipherText.version +
       length of (IV + TLSCiphertext.content) +
       IV +

-- Snip --

I didn't use TLSCiphertext.fragment since that includes the MAC so I've had to
invent a new name 'TLSCiphertext.content', not sure if that's the best option.