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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Thu, 30 October 2014 16:17 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 DD6EF1A0099 for <tls@ietfa.amsl.com>; Thu, 30 Oct 2014 09:17:30 -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 LJ1Jr5SzV6WR for <tls@ietfa.amsl.com>; Thu, 30 Oct 2014 09:17:26 -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 5FA9E1A0023 for <tls@ietf.org>; Thu, 30 Oct 2014 09:17:24 -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=1414685844; x=1446221844; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=9Y0cG4a9Uzr/0pJXf/vUxVPp9lGR8GIgx6pGVMSaJn4=; b=RWer/zAW8g3qYFJCran7a2fDvs/N/4wK7m+7TOR4NnnC1c8ODxbMx1eM 3wpRv0VUoF4uKbVw9/wLzjxUNO5x/HWzTrswsgbZ54090uXINcfgSIFI/ Atd3ZM9K8dXmD7CJWMSDxxtAKvfVrLn8v8YZFKO/lAdONTWTQfp41BJam A=;
X-IronPort-AV: E=Sophos;i="5.04,630,1406548800"; d="scan'208";a="286691359"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 31 Oct 2014 05:17:22 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.15]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Fri, 31 Oct 2014 05:17:22 +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/0XPwJ5+DRaXDcT3GS9QhU9NOHtA==
Date: Thu, 30 Oct 2014 16:17:21 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9DC255@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/VjXOqhDKpiZhkc4LuBMuYZJy1qI
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: Thu, 30 Oct 2014 16:17:31 -0000

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

>Another (related) idea: explicitly change the definition of
>GenericBlockCipher when EtM is in use

Henrick had suggested something like that as well, but at that point you're
starting to rewrite chunks of the main TLS RFCs, which may be overkill if the
goal is merely to explain which length value to use.  That is, it's valuable
for a future RFC (e.g. TLS 1.3) where you'd explicitly want to make this the
standard record format, but it may be a bit heavy going for an erratum that's
only supposed to say "use this value for the length".

The ideal explanation would be as short and concise as possible, and one where
no-one has any concerns about different interpretations.  This was why I was
leaning towards the "for the avoidance of any doubt ..." style of annotation,
it's a brief clarification to the existing text to clear up ambiguity.  My
concern is that adding a complex technical definition, while very precise, may
then require another erratum later on to explain it.

If anyone can come up with a clear one-paragraph note (which, when posted to
the list, no-one complains about :-), I'd be happy to use that.

Peter.