[secdir] Secdir review of draft-ietf-tls-4366-bis

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 28 October 2009 17:57 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 99EB63A6A39; Wed, 28 Oct 2009 10:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.293
X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id dxAermcrLf3D; Wed, 28 Oct 2009 10:57:58 -0700 (PDT)
Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie []) by core3.amsl.com (Postfix) with ESMTP id A1B673A697A; Wed, 28 Oct 2009 10:57:55 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by mail.newbay.com (Postfix) with ESMTP id 549A21004162A; Wed, 28 Oct 2009 17:58:09 +0000 (GMT)
X-Virus-Scanned: amavisd-new at newbay.com
Received: from mail.newbay.com ([]) by localhost (mail.newbay.com []) (amavisd-new, port 10024) with ESMTP id xqiEoJ16npZU; Wed, 28 Oct 2009 17:58:08 +0000 (GMT)
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id C91EE100415F8; Wed, 28 Oct 2009 17:58:02 +0000 (GMT)
Message-ID: <4AE8862B.9040802@cs.tcd.ie>
Date: Wed, 28 Oct 2009 17:58:03 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Thunderbird (X11/20090812)
MIME-Version: 1.0
To: draft-ietf-tls-rfc4366-bis@tools.ietf.org, tls-chairs@tools.ietf.org, sec-ads@ietf.org
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: secdir@ietf.org
Subject: [secdir] Secdir review of draft-ietf-tls-4366-bis
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2009 17:57:59 -0000

Everyone here knows the drill:-)

I reviewed http://tools.ietf.org/html/draft-ietf-tls-rfc4366-bis-06

Other than the first two points below this is basically fine.

Section 5 only allows SHA-1 to be used for certificates referenced
by URLs. That seems wrong these days. I assume this was discussed
in the WG, but still wonder about it. Perhaps a note as to why
a hardcoded hash alg is considered ok here would be good?

Section 6 also has a hardcoded SHA-1 hash for a client to
indicate root CA information. Same comment/question as above.

Section 8 allows a client to nominate an OCSP responder and
provide extensions. Seems like this could provide a new covert
channel between the client and OCSP responder, via the server.
Not sure that's even worth noting though.

Not security related but section 3 says that literal IPv4 &
IPv6 addresses are not allowed as a HostName, what about
in-addr.arpa? (Might be better to say MUST NOT there too
rather than "not permitted")