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

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.

>  > 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.

>  > 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.)

>  > 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?

Best regards,
Pasi
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls