Subject: Re: [TLS] WGLC for draft-ietf-tls-psk-new-mac-aes-gcm-03.txt

From: Alfred Hönes <[email-masked]>
Date: Mon, 20 Oct 2008 16:01:17 +0200 (MESZ)

At Mon, 20 Oct 2008 12:17:34 +0300, Pasi.Eronen at nokia.com wrote:

> Hi,
> 
> <not wearing any hats>
> 
> I have one comment: I think it'd be useful if the CBC mode cipher
> suites could be used with TLS 1.0/1.1 as well. (This would mean
> saying that when TLS 1.0/1.1 is negotiated, the TLS 1.0/1.1 PRF
> is used.)
> 
> Best regards,
> Pasi
> 
>> -----Original Message-----
>> From: [email-masked] On Behalf Of ext Joseph Salowey (jsalowey)
>> To: [email-masked]
>> Sent: 06 October, 2008 05:21
>> Subject: [TLS] WGLC for draft-ietf-tls-psk-new-mac-aes-gcm-03.txt
>>
>> This is a working group last call for
>> draft-ietf-tls-psk-new-mac-aes-gcm-03.txt.  Please send any
>> comments on this draft to the list by October, 20 2008.
>>
>> Thanks,
>>
>> Joe

This comment indeed raises a reasonable question.

Technically, it would apparently not be a problem to follow
this proposal, it's perhaps more a question of WG policy.

As far as I can see, in the recent past this WG has -- maybe
more implicitely than explicitely stated -- followed the policy
to *not* retrofit support for cipher suites incorporating use
of SHA-2 algorithms into TLS v1.0 / v1.1 in *Standards-Track*
documents (cf. the CBC cipher suites in RFC 5289); this has
only been done so far in documents intended for Informational
or Experimental status. (Note: Using an established TLS v1.0/v1.1
implementation as the basis of an experiment is deemed useful
to further experimentation.)

Since this draft also aims at Standards Track, it would seem
consequential to not deviate from this policy, and hence not
extend the scope of the draft to TLS v1.0/v1.1 for the CBC
cipher suites, unless there are specific reasons to do so.

Pasi:
Do you have specific use cases in mind that could justify that?

All:
Or is the perceived view of WG policy wrong, and consistency
with RFC 5289 less important than extended utility?

My proposal:

It might make sense to now leave the draft "as is" and defer
the final decision on this amendment until comments from
IETF LC have been received and can be considered as well.
Documenting the question in the PROTO Writeup could direct
the community at large to consider this topic during LC,
and doing so thus would be a good chance to see if someone
explicitely calls for the addition if this feature.

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 22 Oct 2008 16:47:46 -0700

> the final decision on this amendment until comments from IETF 
> LC have been received and can be considered as well.
> the community at large to consider this topic during LC, and 
> doing so thus would be a good chance to see if someone 
[Joe] Since there has been no more discussion, this is the approach I will take with Proto write-up and submission to the IESG. 

My personal opinion is that we should keep the draft as it is.  I don't see a glaring need for TLS 1.1 compatibility.  As a minor point of consistency I think the new long MACs should use the TLS 1.2 PRF.

---

From: <[email-masked]>
Date: Thu, 23 Oct 2008 18:58:04 +0300

Alfred,

I'm not sure if we have decided on any WG policy about whether new
cipher suites (defined from now on) should apply only to TLS 1.2, 
or also to earlier versions (when they don't need new features of 
TLS 1.2, like AEAD).

(This question is anyway quite recent, as all earlier cipher suites
were always version-independent -- mostly worked even with SSLv3.)

My personal opinion is that if being compatible with TLS 1.0/1.1
requires just a single sentence in the spec, it's the probably 
safer than not doing it (since we don't have to try to predict if 
someone will use it or not).

Best regards,
Pasi

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Alfred HÎnes
> Sent: 20 October, 2008 17:01
> To: [email-masked]
> Subject: Re: [TLS] WGLC for draft-ietf-tls-psk-new-mac-aes-gcm-03.txt
>