IETF Logo Mail Archive

Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)) to Informational RFC

Nikos Mavrogiannopoulos <nmav@gnutls.org> Mon, 28 February 2011 08:44 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 8A6B63A6AE1; Mon, 28 Feb 2011 00:44:19 -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 quNVPkKBLtTV; Mon, 28 Feb 2011 00:44: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 9660F3A6ADE; Mon, 28 Feb 2011 00:44:18 -0800 (PST)
Received: by qyk7 with SMTP id 7so2818200qyk.10 for <multiple recipients>; Mon, 28 Feb 2011 00:45:18 -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; bh=UymXaXJnuCC627tlVYXTVhz3lxQeur095B1ozZsU4bg=; b=B7NLYoWtFZmYX4IE1+vbGMD6haaWoO5TrTkHAFlSFg6cn5mSXiNKKTea7GrLANWXEj Izu/IigAaXWB7GnHDaGmEfccjNRw3SeqOux3zBtwX8xU8BqQDQjix0aITo5/k1qvdofV 6dcW10tY/9eyqOJeNFWPjTAr31/O6qIQwjjHM=
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; b=EFcPw+k0vgzTcaGDHTNBmVx2z8ha1pp2Ps5suOjE1I0WlD0NzqjPAqOrwIZ4eUxuI+ 3uagM4LA4iDglCZDtt2Fz3FQ+eZrXg662gQUwYeaXIXh2l65VcIni7dL3xhQOmtd4PdT 4KF6C99x+R4UxUiWY7jU8FTnEb2VPm0Qf6/TI=
MIME-Version: 1.0
Received: by 10.229.192.149 with SMTP id dq21mr4003295qcb.57.1298882717179; Mon, 28 Feb 2011 00:45:17 -0800 (PST)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.229.20.71 with HTTP; Mon, 28 Feb 2011 00:45:17 -0800 (PST)
In-Reply-To: <4D6B423D.1010402@po.ntts.co.jp>
References: <20110223172955.27054.7913.idtracker@localhost> <4D654B4D.8020800@gnutls.org> <4D6B423D.1010402@po.ntts.co.jp>
Date: Mon, 28 Feb 2011 09:45:17 +0100
X-Google-Sender-Auth: D_Tw3CaUBrjRgfMaDfjpEitKzHA
Message-ID: <AANLkTikAu_yzjzH92Fx89EheEvU1zKjTyNi7=NwG1raY@mail.gmail.com>
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
To: Satoru Kanno <kanno.satoru@po.ntts.co.jp>
Content-Type: text/plain; charset="UTF-8"
Cc: ietf@ietf.org, tls@ietf.org
Subject: Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)) to Informational RFC
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, 28 Feb 2011 08:44:19 -0000

On Mon, Feb 28, 2011 at 7:35 AM, Satoru Kanno
<kanno.satoru@po.ntts.co.jp> wrote:

>> I see that this document defines ciphersuites with a PRF based on
>> SHA384... However it does not specify the verify_data_length, thus
>> the default value of 12 applies, and the SHA384 PRF is being truncated
>> to 96 bits. Is this intentional? If yes, then what is the purpose to
>> use the SHA384 as PRF?
> Hi Nikos,
> Thank you for your comment.
> I think that the verify_data_length with a PRF based on
> SHA384 is specified in RFC5246.
> As a result, I refer to RFC5246 as well as other documents( e.g., RFC5289,
> RFC5487, and draft-nsri-tls-aria etc.,) in our document.
> I think that your comment is not only our draft but all documents specifying
> the PRF base on SHA384 for TLS.

Yours was the first document I noticed to use SHA384 as PRF. If there
are other documents that specify that, and don't set the verify_data_length
size then it applies to those as well. (just noticed that applies to RFC5288
as well).

regards,
Nikos

v2.23.0 | Report a Bug | By Email