Re: [TLS] WGLC for draft-ietf-tls-psk-new-mac-aes-gcm-03.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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: tls-bounces at ietf.org On Behalf Of ext Joseph Salowey (jsalowey)
>> To: tls at ietf.org
>> 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:  ah at TR-Sys.de                     |
+------------------------+--------------------------------------------+

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