Re: [TLS] Changes to draft-ietf-tls-dtls-heartbeat resulting from IESG review

"Dan Harkins" <dharkins@lounge.org> Tue, 06 December 2011 18:11 UTC

Return-Path: <dharkins@lounge.org>
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 6016921F8C0C for <tls@ietfa.amsl.com>; Tue, 6 Dec 2011 10:11:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
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 vMqpesjOEWHn for <tls@ietfa.amsl.com>; Tue, 6 Dec 2011 10:10:52 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8A50621F8BFE for <tls@ietf.org>; Tue, 6 Dec 2011 10:10:52 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2818C20054; Tue, 6 Dec 2011 10:10:36 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 6 Dec 2011 10:10:36 -0800 (PST)
Message-ID: <299bdcba9ed4bc96b1f87ee7bd40c753.squirrel@www.trepanning.net>
In-Reply-To: <CAJU7zaLZMOB1u9cOTQGyKKq7+dAfVgPoGMPbq2pXfrh8ABag2A@mail.gmail.com>
References: <6D345690-D3F1-4A65-8314-D9A7E47D857E@cisco.com> <CAJU7zaJLH2L6W6CjSvAZ0OL6=hqMscqdx_gwg0J0jwOP3Sr=VA@mail.gmail.com> <cf07c3568cb7473f31a491e248ed9192.squirrel@www.trepanning.net> <CAJU7zaLZMOB1u9cOTQGyKKq7+dAfVgPoGMPbq2pXfrh8ABag2A@mail.gmail.com>
Date: Tue, 6 Dec 2011 10:10:36 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: "Nikos Mavrogiannopoulos" <nmav@gnutls.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: tls@ietf.org
Subject: Re: [TLS] Changes to draft-ietf-tls-dtls-heartbeat resulting from IESG review
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, 06 Dec 2011 18:11:02 -0000

On Tue, December 6, 2011 8:17 am, Nikos Mavrogiannopoulos wrote:
> On Mon, Dec 5, 2011 at 6:04 PM, Dan Harkins <dharkins@lounge.org>; wrote:
>
>>>> One of the requested changes was to randomize to the data in the
>>>> heartbeat message to attempt to head of any issues occurring from weak
>>>> or flawed ciphers.   Since the change was relatively simple, the
>>>> document was modified even though modern ciphers should not have a
>>>> problem.  Flaws may be discovered in one of the many cipher suites in
>>>> the future.
>>> Are there any papers or cipher documentation discussing how using
>>> randomized data in a packet would solve possible future cipher flaws?
>>  Check out "Deterministic Authenticated Encryption"* by Rogaway and
>> Shrimpton. It defines a cipher mode for key-wrapping but the proof of
>> security (appendix C) is based on the notion of randomized data in the
>> packet-- i.e. that part of the data (the key) being wrapped is random.
>
> Indeed, but this is not a generic encryption mode like CBC or CTR. It
> is specifically designed to encrypt random keys, and thus depends on
> its randomness. Typical encryption modes are specifically designed to
> prevent someone distinguishing a given plaintext encryption from a
> random one.

  Actually it is a generic encryption mode. It's a generic AEAD scheme
(like GCM or CCM) and has code-points allocated by IANA for AEAD
algorithms defined by RFC 5116:

http://www.iana.org/assignments/aead-parameters/aead-parameters.xml

Unlike other AEAD schemes this one has the benefit of misuse-resistance
(see section 7).

  It is also provably-secure key-wrapping scheme, as you note. I
mention this because it formally addresses the issue of randomness
in the packet and its effect on the security of the cipher mode which
is what I thought you were asking about.

  It's a generic AEAD mode...it's a key-wrapping scheme... for a
crypto protocol developer, it's the new SHIMMER!

http://www.nbc.com/saturday-night-live/video/shimmer-floor-wax/1056743/

> Now, if one would like to use a subliminal channel in TLS, the
> heartbeat extension now provides an unbounded channel.

  Well that's a whole different issue....

  Dan.