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

Nikos Mavrogiannopoulos <> Mon, 14 March 2011 20:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B17263A6AAA; Mon, 14 Mar 2011 13:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.662
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3si8ZY6o9ICz; Mon, 14 Mar 2011 13:29:43 -0700 (PDT)
Received: from ( []) by (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;; 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;; 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 with SMTP id u1mr3083260bkz.26.1300134653077; Mon, 14 Mar 2011 13:30:53 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id v21sm5460546bkt.23.2011. (version=SSLv3 cipher=OTHER); Mon, 14 Mar 2011 13:30:51 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <>
Message-ID: <>
Date: Mon, 14 Mar 2011 21:30:49 +0100
From: Nikos Mavrogiannopoulos <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.2
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
> and the second part of this message from Hugo Krawczyk
> 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.