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

Alfred Hönes <ah@tr-sys.de> Mon, 20 October 2008 14:01 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5032C3A6ACE; Mon, 20 Oct 2008 07:01:40 -0700 (PDT)
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC543A6AAD for <tls@core3.amsl.com>; Mon, 20 Oct 2008 07:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.262
X-Spam-Level: *
X-Spam-Status: No, score=1.262 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce0W8WM36f-g for <tls@core3.amsl.com>; Mon, 20 Oct 2008 07:01:38 -0700 (PDT)
Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 2B1953A68D0 for <tls@ietf.org>; Mon, 20 Oct 2008 07:01:36 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA289581283; Mon, 20 Oct 2008 16:01:23 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA25056; Mon, 20 Oct 2008 16:01:18 +0200 (MESZ)
From: Alfred Hönes <ah@tr-sys.de>
Message-Id: <200810201401.QAA25056@TR-Sys.de>
To: tls@ietf.org
Date: Mon, 20 Oct 2008 16:01:17 +0200
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Subject: Re: [TLS] WGLC for draft-ietf-tls-psk-new-mac-aes-gcm-03.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls