Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

Nikos Mavrogiannopoulos <nmav@gnutls.org> Mon, 14 March 2011 20:29 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17263A6AAA; Mon, 14 Mar 2011 13:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.662
X-Spam-Level:
X-Spam-Status: No, score=-3.662 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3si8ZY6o9ICz; Mon, 14 Mar 2011 13:29:43 -0700 (PDT)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 81BE93A6A6D; Mon, 14 Mar 2011 13:29:42 -0700 (PDT)
Received: by bwz13 with SMTP id 13so5399878bwz.31 for <multiple recipients>; Mon, 14 Mar 2011 13:31:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=c9h3fdP0WknkXBIdhccubo1clf0LqLx3L9NC9xpT5IY=; b=YHW+DitnpYOjvqeCVv/GdHu7XsxU40O2JzBqLG4IQi3+AIgcVqybjzWtYJ8wtcNCDq q15h8hKmrka8Crd8NRwBRLwrXoa+0DKTl+NJRRtTbuGsywb/4NLRkukAb0DwS5V/9pY8 twhdJg9EqFXmeBV4rp0iMDjhiakvZe5jEHEb4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=kFe4DKC7T80HsUYEl/9o9B1mUZeur94/bB4c+X835fFsYLrjYmmFxv0Wb43mABl+Ot cWw/nd5JT2/IkyTew2OZhhsclJh6n14+2TzwhTpJZ23wmybvN9KtasrCuTJ+D8Xfqg2u DbgexAGv2wxv1O+5SBMZPyM2Hg8J9NmjKtps4=
Received: by 10.204.174.193 with SMTP id u1mr3083260bkz.26.1300134653077; Mon, 14 Mar 2011 13:30:53 -0700 (PDT)
Received: from [10.100.2.14] (78-23-65-69.access.telenet.be [78.23.65.69]) by mx.google.com with ESMTPS id v21sm5460546bkt.23.2011.03.14.13.30.50 (version=SSLv3 cipher=OTHER); Mon, 14 Mar 2011 13:30:51 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4D7E7AF9.7070409@gnutls.org>
Date: Mon, 14 Mar 2011 21:30:49 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: mrex@sap.com
References: <201103141728.p2EHSXl3019185@fs4113.wdf.sap.corp>
In-Reply-To: <201103141728.p2EHSXl3019185@fs4113.wdf.sap.corp>
X-Enigmail-Version: 1.1.2
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org, ietf@ietf.org, kent@bbn.com
Subject: Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Mon, 14 Mar 2011 20:29:46 -0000

On 03/14/2011 06:28 PM, Martin Rex wrote:
> Nikos Mavrogiannopoulos wrote:
>>
>> This sounds pretty awkward decision because HMAC per record is full
>> (e.g. 160-bits on SHA-1), but the MAC on the handshake message
>> "signature" is truncated to 96-bits. Why wasn't the record MAC
>> truncated as well? In any case saving few bytes per handshake
>> is much less of value than saving few bytes per record. Was
>> there any other rationale for truncation?
> 
> Are you wondering why the HMAC on the TLS data records is is sent
> in its full beauty, while the TLS Finished.verify_data is a
> truncated output of the PRF (which in the abstract definintion
> uses HMAC as the outermost function, but in the case of TLSv1.0
> is actually the XOR of two different HMACs over half the secret).
> The reason might be about the "secret" input to the HMAC, which in
> case of the TLS data records is a derived traffic key, while in
> case of the Finished.verify_data, is the "master secret" of the session.
> 
> That was, what I assume, the fear, based on the second part of this
> message from Dan Simon
>    http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0224.html
> and the second part of this message from Hugo Krawczyk
>    http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0231.html 
> Since the TLSv1.0 finished message was defined based on the output
> of the TLS PRF (a function with indefinite output length),
> defining a truncation was inevitable.  :)

Indeed. It seems the messages you list summarize that design decision
in a nice way. The concerns for the one-wayness of the MAC used lead
to that truncation. That way one-wayness is ensured by discarding data
at the cost of having a weaker MAC. I don't know if the current
construction can be extended for a longer size without implications.

regards,
Nikos