Re: [TLS] New version of draft-ietf-tls-ecdhe-psk after the WGLC

Hi Pasi,

Pasi.Eronen@nokia.com wrote:
> Mohamad Badra wrote:
>> Dear Pasi,
>>
>>> The contents of the draft have changed quite a bit since version
>>> -02 (which was posted just before the Dublin meeting), and I have
>>> some comments about the changes:
>>
>> In fact, we discussed adding SHA256 and SHA348 to the document to
>> avoid publishing several seperated documents; and if I recall well,
>> your recommendation was to do that in one single document. If the
>> group doesn't agree with this change, I will post the old version.
> 
> I think having them all in a single document is better; it's 
> the other changes in -03 I commented.

OK.

> 
>>  > It's a bit surprising that
>>  > e.g. TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA, when negotiated in TLS
>>  > 1.2, would use the TLS PRF with SHA-1 as the hash function. Note
>>  > that e.g.  TLS_DHE_PSK_WITH_AES_128_CBC_SHA (from RFC 4279) would
>>  > in this situation use the TLS PRF with SHA-256.
>>
>> In this case, I would know where I can read that cipher suites
>> described in RFC 4492, when negotiated in TLS 1.2, will use the TLS
>> PRF with SHA-256. Do you refer to Section 5 of TLS 1.2?
>>
>> The same for TLS_DHE_PSK_WITH_AES_128_CBC_SHA.
> 
> Yes, I'm referring to Section 5 of TLS 1.2.

OK.

> 
>>  > My suggestion would be to say that all these cipher suites can be
>>  > negotiated with any TLS version; when used with TLS <1.2, they use
>>  > the PRF from that version; when used with TLS >=1.2, they use the
>>  > TLS PRF with SHA-256 or SHA-384. (In other words: they'd work the
>>  > same way as the cipher suites in RFC 4492/4279/4785.)
>>  >
>>  > This change would probably allow us to remove the SHA-1 suites
>>  > completely.
>>
>> With regard to version 2 of the document, only SHA-1 suites are 
>> described. So why we need to do this step?
> 
> I would ask it this way: if the document has SHA-256/384 based
> suites, why does it need the SHA-1 suites?
> 
> (Cipher suites isn't one of those things where having more
> is automatically better.)

Unfortunately, these new arguments aren't presented in WGLC, which would 
also have been applicable to the previous two versions.

I don't know, but don't we need a WG consensus on that change?

>>  > Also, while I can understand combining AES-128 with
>>  > SHA-256, and AES-256 with SHA-384, I'm not sure why we need to
>>  > combine NULL encryption with three different MACs...
>>
>> In the case we are going to remove the SHA-1 suites with NULL
>> encryption, only 2 combinations will be available (if we keep the
>> logic of moving away from SHA-1 and towards stronger hash
>> algorithms, as RFC 5288 and 5289 do).
> 
> Yes, but why do we need two combinations? What problem is solved
> by having two, instead of just one?

Which one do you suggest? and why only one of both?
(WRT RFC5288 and 5289 portfolio, I prefer keeping both of them,)

Best regards,
Badra

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls