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

"Christian Kahlo" <> Fri, 20 September 2013 16:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DDAA621F9BDB for <>; Fri, 20 Sep 2013 09:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uedGW8bgX04f for <>; Fri, 20 Sep 2013 09:10:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AA0C921F9BD0 for <>; Fri, 20 Sep 2013 09:10:56 -0700 (PDT)
Received: by with SMTP id mx12so270520bkb.34 for <>; Fri, 20 Sep 2013 09:10:55 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:reply-to:from:to:cc:references:in-reply-to :subject:date:organization:message-id:mime-version:content-type :thread-index:content-language; bh=8dgAAa1Jk2nQYmHX4z/bsHlMs88tElB2XrnqhHSnGtE=; b=YHhD6kIDiW9KZrL1T48kninyewQ0bP1IldKgiGSo+I2TG0HNA+v7+DAhMKKXD+zQ5O xdq+7SToT5pAtFPQjn5UreUSy4i9XNbnRgoNvbC7FXYEKSYWhkP4Lq+QLyIa2ql+Olr0 WvieeC5aUldLTFP0AYKLduy+tKsiuoytwryBaKnx2ZljcNZEZxx/xG5eMsVL9yBfksNp RQZd5wroGepVOqDcoN5ODSTkHPDAKDWvzlxBkG55A0RzcS1dmDCdkMpAEZq95Qco6G2Z V8CGLsX5ydsN0E50TCtBAktPGEbwWD7/nVpb4cUG6uXRBZ2PA5X7oCieP6C2PxzjOcjf MLDQ==
X-Gm-Message-State: ALoCoQk9TEs0l3YqHQnWDGBX1eDZUg6Q0wQdjJXZxfk5V1x9AQi/7VfCiR+tYtq3ogzS/VFfLOX/
X-Received: by with SMTP id i8mr6050015bkk.3.1379693455459; Fri, 20 Sep 2013 09:10:55 -0700 (PDT)
Received: from THINK2 ( []) by with ESMTPSA id b7sm4871940bkg.1.1969. (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 20 Sep 2013 09:10:55 -0700 (PDT)
From: "Christian Kahlo" <>
To: "'Eric Rescorla'" <>, <>
References: <>
In-Reply-To: <>
Date: Fri, 20 Sep 2013 18:10:56 +0200
Organization: AGETO Innovation GmbH
Message-ID: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CEB62C.C1473A50"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac62GbeJWByUsfvQQOecd2O6aVfcqgAAI1lQ
Content-Language: de
X-Mailman-Approved-At: Sun, 22 Sep 2013 10:52:04 -0700
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Sep 2013 16:13:56 -0000

Hi Eric,


just as side note. The Germen Federal Office for Information Security also
had a look

on this. See BSI TR-03116-4.



I'm sorry, there is no english translation yet. But it will be translated

On page 8, chapter 2.3, "Weitere Vorgaben" / "More specifications", 4th

It reads that Encrypt-then-Mac should be preferred instead of

The reasons are rather simple: GCM is not yet available everywhere. One

example are Java/JDK environments without additional crypto providers used

with many application servers.

Even some other standards bodies like ISO, CEN, BSI, etc. agreed on

(with or without EtM) as a lowest common factor with TLS.


So CBC WILL(!) exist regardless what you're specifying here. ;-)

There also at least implementations in our Federal project, OpenSSL, Bouncy

Castle and as I heard CyaSSL, too.


The discussion isn't about AEAD or not, the discussion is about a protocol

flaw lasting now for more than FOURTEEN YEARS.

Just compare it to ISO7816-4 secure messaging. EtM has been there from the







Christian Kahlo, Research Manager IT-Security,  <>, Tel. +49-3641-3678-305, Fax +49-3641-3678-101

AGETO Innovation GmbH, Winzerlaer Straße 2, D-07745 Jena

Geschäftsführung: P. Israel, S. Sauer, S. Scheppe HR: Amtsgericht Jena, HRB



Von: [] Im Auftrag von Eric
Gesendet: Freitag, 20. September 2013 17:53
Betreff: [TLS] Comments/Questions on




After reviewing this document I have a few comments/questions:


- Because this draft relies on extensions, it seems not to resist

  active attack when clients do insecure version fallback

  (see for instance:

  The existing attacks appear to principally be active attacks on the

  environment, which is where fallback tends to happen.


- Maybe I am misreading the draft, but I'm unclear on how you get

   the TLSCompressed.length for the MAC computation in Section 3.

   Does this have the same issue as was raised for McGrew's CBC AEAD



Am I missing something here?