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

From: <[email-masked]>
Date: Wed, 1 Oct 2008 13:30:12 +0300

Hi,

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:

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.

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

Best regards,
Pasi 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Mohamad Badra
> Sent: 29 September, 2008 13:27
> To: Joseph Salowey (jsalowey); Eric Rescorla
> Cc: tls mailing list
> Subject: [TLS] New version of draft-ietf-tls-ecdhe-psk after the WGLC
> 
> Dear all,
> 
> A new version of draft-ietf-tls-ecdhe-psk is now available 
> (http://www.ietf.org/internet-drafts/draft-ietf-tls-ecdhe-psk-03.txt).
> 
> All WGLC and post-WGLC comments received have now been acted 
> upon, the 
> References have been updated, and the new version now 
> includes a minimum 
> number of cipher suites using SHA-2 algorithms as in RFC 5289 
> etc. (and 
> which are only usable with TLS 1.2 and up) as well, in order to avoid 
> having to produce an extra document to conform with the IESG 
> appeal to 
> move to stronger hash algorithms.
> 
> The draft should now be ready to request publication as an 
> RFC; at IEFT 
> 72, the WG had agreed to postpone that until after the publication of 
> TLS 1.2, RFC 5246 (which has happened six weeks ago) and the 
> progress of 
> the other two TLS cipher suite WG drafts (which have been 
> published as 
> RFCs 5288 and 5289 five weeks ago), to simplify the treatment 
> of References.
> 
> Best regards,
> -- 
> Mohamad Badra
> CNRS - LIMOS Laboratory
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
> 
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: [email-masked]
Date: Wed, 1 Oct 2008 14:49:47 +0200 (CEST)

Dear Pasi,

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

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

> 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

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

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 01 Oct 2008 16:48:34 +0200

(sorry for the trouble in my last mail subject)

Dear Pasi,

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.

 > This change would probably allow us to remove the SHA-1 suites

With regard to version 2 of the document, only SHA-1 suites are 
described. So why we need to do this step?

 > 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

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 01 Oct 2008 17:01:35 +0200

> same way as the cipher suites in RFC 4492/4279/4785.)

OK, I agree with that.
Best regards

---

From: <[email-masked]>
Date: Thu, 2 Oct 2008 11:29:21 +0300

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

Yes, I'm referring to Section 5 of TLS 1.2.

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

> 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

---

From: Mohamad Badra <[email-masked]>
Date: Thu, 02 Oct 2008 11:57:48 +0200

Hi Pasi,

> the other changes in -03 I commented.

OK.

> Yes, I'm referring to Section 5 of TLS 1.2.

OK.

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

> 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