IETF Logo Mail Archive

Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 24 September 2013 04:52 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E48F21F9C9B for <tls@ietfa.amsl.com>; Mon, 23 Sep 2013 21:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level:
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZLMBaYw5Cix for <tls@ietfa.amsl.com>; Mon, 23 Sep 2013 21:52:46 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 9992D21F99E7 for <tls@ietf.org>; Mon, 23 Sep 2013 21:52: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=1379998366; x=1411534366; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=86lSi61AfLSU/FkpjUN3xFDzoo1YLDBm2h/SouqgA88=; b=T0631YqKBCFzkb2j/0ufvZWM87eUMhCo4QoCgiAzs+ogOuAXdYsl/+Hm Qe2jORJ2RV/OU9Y0J6DtlVbDfB+Dojz3nUqCriFrCfq3wLCraMBfIcb0r I0AjQWodbUsq464MfzWkpDF/VjTad4kvVfqYNvb4ntyA00rWd+OaQpSsI U=;
X-IronPort-AV: E=Sophos;i="4.90,968,1371038400"; d="scan'208";a="213848518"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 24 Sep 2013 16:52:43 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 16:52:42 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
Thread-Index: Ac644ec6SWGYiizlRSe+ZS0RmDI5Jw==
Date: Tue, 24 Sep 2013 04:52:42 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355676092@uxcn10-6.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 24 Sep 2013 04:52:51 -0000

Nikos Mavrogiannopoulos <nmav@gnutls.org> writes:

>The innovate refers to how the current EtA proposal by Peter ignores all best
>practices in implementing EtA in protocols.

You seem to be saying there that HMAC has security problems unless it's
truncated, which is something that AFAIK no other cryptographer has ever
noticed.  Perhaps you could clarify the weakness for the list, and then
consider publishing a conference paper on it.  It sounds like an amazing
breakthrough in the cryptanalysis of HMAC.

>Existing EtA protocols like IPSec truncate the HMAC to avoid revealing the
>whole internal state of the hash algorithm.

S/MIME doesn't truncate it.  TLS doesn't truncate it.  PGP (although that
doesn't really use a MAC, but still...) doesn't truncate it.

In any case TLS has, for some years now, allowed for truncated MACs.  If
anyone really feels this is an issue, they can use truncated_hmac to require
truncation to any length they feel comfortable with.

Peter.

v2.23.0 | Report a Bug | By Email