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

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 09 March 2011 14:00 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 BAE343A69BF for <tls@core3.amsl.com>; Wed, 9 Mar 2011 06:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 jC7CzoPL-l4p for <tls@core3.amsl.com>; Wed, 9 Mar 2011 06:00:18 -0800 (PST)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id D610F3A6821 for <tls@ietf.org>; Wed, 9 Mar 2011 06:00:17 -0800 (PST)
Received: by qyk7 with SMTP id 7so436437qyk.10 for <tls@ietf.org>; Wed, 09 Mar 2011 06:01:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4myV0puXkDMFbfN5rIH3+khEmknOMp9y6IbE6n6kzjA=; b=KNcwB7/5EHAeFDYDQoeAWN+r7rHl2UJ0L3zmub2vUi5AaPElAqVZxQCcmeqE///KES 1pMrfWLR4v4EjE1XWLGwerdXSYsPHOwHmK/BjFSpa4SwTDg+UrcVrFeeGDJCH8RIUnR7 dpllk9Hck3u5cK3Qice9Alp8fanvM/tBkI2II=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=oAX07ITcdDhgh0HLyKVw2iKn05GdzSWO7DxjGQrv7Wf/evxvZ9u6Q+BLjtJgD8rQF8 N3cOb7KflE+DTLKZ5hpDPmZRA4OJGEP7Z52PrRItVwhu+5STR40kDUXZmP02JwULq8L7 xfPK7xIOaEg1+g17DKqmT6a2Ezm+VX/ElmdGg=
MIME-Version: 1.0
Received: by 10.229.79.196 with SMTP id q4mr5201805qck.132.1299679292628; Wed, 09 Mar 2011 06:01:32 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.229.20.71 with HTTP; Wed, 9 Mar 2011 06:01:32 -0800 (PST)
In-Reply-To: <197ECCE1-F179-4CF2-BBCE-8FE686A33497@checkpoint.com>
References: <201103091206.p29C61fq005174@fs4113.wdf.sap.corp> <197ECCE1-F179-4CF2-BBCE-8FE686A33497@checkpoint.com>
Date: Wed, 09 Mar 2011 15:01:32 +0100
X-Google-Sender-Auth: 8bnFynZqayzSUfrXaNsE8fE4IMg
Message-ID: <AANLkTi=OPisOQDkpJHCc0wup=i5dni35nMZpGkE99Lj4@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <tls@ietf.org>
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: Wed, 09 Mar 2011 14:00:18 -0000

On Wed, Mar 9, 2011 at 2:27 PM, Yoav Nir <ynir@checkpoint.com> wrote:

>> What I'm reading here is that a truncation of an HMAC or an HMAC-like
>> construct to 96 bits cuts the effective security down to 96-bit.
> I've heard the balance argument before, and I don't really find it compelling. It implies that if I'm using 1024-bit RSA, then it is inherently wrong to use AES-128 or SHA-384. There are other considerations in design besides bit-strength. Bit strength should be used as a minimum value, depending on the estimated resources of your opponent.
[...]
> The point is, that many factors may influence my choice of algorithms, and there's nothing wrong with having an imbalanced suite. Just as long as all the algorithms meet (or exceed) my target strength.

This would be fine if the target strength was formally set in TLS
cipher-suites. There
is no such thing in them and this is the reason we see RC4 with a 96-bit MAC on
handshake, AES-128 with a 96-bit MAC, AES-256 with the same MAC etc.
What was the target strength in those ciphersuites?


regards,
Nikos