(2011/02/24 3:00), Nikos Mavrogiannopoulos wrote:
On 02/23/2011 06:29 PM, The IESG wrote:
The IESG has received a request from an individual submitter to
consider the following document: - 'Addition of the Camellia Cipher
Suites to Transport Layer Security (TLS)'
<draft-kanno-tls-camellia-00.txt> as an Informational RFC
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send substantive
comments to the ietf(_at_)ietf(_dot_)org mailing lists by 2011-03-23.
Exceptionally, comments may be sent to iesg(_at_)ietf(_dot_)org instead. In
either case, please retain the beginning of the Subject line to allow
automated sorting.
The file can be obtained via
http://datatracker.ietf.org/doc/draft-kanno-tls-camellia/
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.
What do you think?
Regards,
Satoru
regards,
Nikos
_______________________________________________
TLS mailing list
TLS(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tls
--
Satoru Kanno
Security Business Unit
Mobile and Security Solution Business Group
NTT Software Corporation
e-mail: kanno(_dot_)satoru(_at_)po(_dot_)ntts(_dot_)co(_dot_)jp
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf