IETF Logo Mail Archive

Re: [TLS] rfc7366: is encrypt-then-mac implemented?

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 29 October 2014 14:38 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2B91A010E for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 07:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTxIh6N1PSX5 for <tls@ietfa.amsl.com>; Wed, 29 Oct 2014 07:38:44 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1BE1A0143 for <tls@ietf.org>; Wed, 29 Oct 2014 07:38:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1414593525; x=1446129525; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=hH5KMlWszkxAejWrADHE/GcjG8HRBlAPLOu8qf0ZMds=; b=hbgRVaJCw3HWKh8NHqoxjfZ42gudNs0NzIeen7EEL5Jxh0kpIPhb8tDa VlivwrlQ7qbGLCXq0wj/XYM+wbthlsteMUnbHUVhp6Wp+jTpFZgJb8pGY NQCpiSkD4u1iFWP2YFZwtWOP0cv26YAA0wOH3NdFUqtFihG1t6GE8DIGi U=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286449498"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 30 Oct 2014 03:38:44 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Thu, 30 Oct 2014 03:38:42 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] rfc7366: is encrypt-then-mac implemented?
Thread-Index: Ac/zhgi8JCXtbQeBQ2WtrFxyWH+95A==
Date: Wed, 29 Oct 2014 14:38:41 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DB35D@uxcn10-5.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yjRa_9PWWtZbCEef0Kt3T8Ovdx8
Subject: Re: [TLS] rfc7366: is encrypt-then-mac implemented?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Oct 2014 14:38:46 -0000

Manuel Pégourié-Gonnard <mpg@polarssl.org> writes:

>What I'm doing to get this is interpret TLSCipherText.length exactly as it is
>defined in RFC 5246 (6.2.3.2, page 22):
>
>   The encrypted data length (TLSCiphertext.length) is one more than the
>   sum of SecurityParameters.block_length, TLSCompressed.length,
>   SecurityParameters.mac_length, and padding_length.
>
>Apparently to interoperate with the implementation at eid.vx4.net (and with
>OpenSSL 1.1.0-dev) one needs to rather interpret it as excluding
>SecurityParameters.mac_length. I couldn't find this explicitly stated
>anywhere.

Section 3 of RFC 7366 says:

  In [2] notation the overall packet is then:

   struct {
          ContentType type;
          ProtocolVersion version;
          uint16 length;
          GenericStream/BlockCipher fragment;
          opaque MAC;
          } TLSCiphertext;

   This is identical to the existing TLS layout with the only difference
   being that the MAC value is moved outside the encrypted data.

>I strongly agree with Nikos that an erratum should make this explicit if that
>was the intention of the document. 

It does make it explicit, see above.  The previous folks who interop'd with
the eid server seemed to have no problems with it.

Peter.

v2.23.0 | Report a Bug | By Email