Re: Last Call: <draft-salter-rfc5430bis-01.txt> (Suite B Profile for Transport Layer Security (TLS)) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/27/2011 09:02 PM, Russ Housley wrote:

>>>> The fact that the SHA-384 is used in the latter case in combination
>>>> with AES_256 it implies that SHA256 was replaced by SHA384 to
>>>> increase the security (the same way AES-128 was replaced by
>>>> AES-256). However there is no evidence that a 96-bit SHA384 based
>>>> MAC is stronger than a 96-bit SHA256 MAC.
>>> Elsewhere in the Suite B profiles, SHA-384 is always paired with 
>>> AES-256 and EC algorithms using the P-384 curve.  This selection was
>>> done for consistency.
>>
>> This is however, cannot be deducted from the document. The document
>> describes two combinations of suites one of 128-bit security level and
>> another of 192-bit. In the 128-bit security level a SHA-256 PRF is used
>> and in the 192-bit the SHA-384 PRF. To someone reading this document it
>> is apparent that the choice of the SHA-384 PRF is done to increase to a
>> 192-bit security level. However, as you say this is not the case, and
>> this IMO deserves at least a sentence in the security considerations
>> section.
> 
> If this document were defining the ciphersuites, I might agree.  However, this document is using ciphersuites that are defined in other documents. 

Ok then we have a loop where the documents that define the ciphersuites
don't discuss the security levels because they will be discussed
somewhere else, and the documents that define the security levels don't
actually discuss them because they should have been discussed in the
ciphersuites document.

regards,
Nikos
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]