Re: [TLS] New version of draft-ietf-tls-ecdhe-psk after the WGLC
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] New version of draft-ietf-tls-ecdhe-psk after the WGLC
(sorry for the trouble in my last mail subject)
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.
> 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.
>
> 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?
> 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).
Best regards,
Badra
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.