[secdir] secdir review of draft-mavrogiannopoulos-ssl-version3

"Dan Harkins" <dharkins@lounge.org> Mon, 02 May 2011 17:52 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE17E06A3; Mon, 2 May 2011 10:52:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Level:
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOeKoiwtqVk9; Mon, 2 May 2011 10:52:30 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6BFF4E0678; Mon, 2 May 2011 10:52:30 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3AD051022400A; Mon, 2 May 2011 10:52:30 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 2 May 2011 10:52:30 -0700 (PDT)
Message-ID: <315e69dc80b49e18950a478f6ab49972.squirrel@www.trepanning.net>
Date: Mon, 02 May 2011 10:52:30 -0700
From: Dan Harkins <dharkins@lounge.org>
To: iesg@ietf.org, secdir@ietf.org, draft-mavrogiannopoulos-ssl-version3.all@tools.ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Subject: [secdir] secdir review of draft-mavrogiannopoulos-ssl-version3
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 02 May 2011 17:52:31 -0000

  Hello,

  I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

  This draft is a formal description of SSL 3.0 which was never formally
published by the IETF. TLS has made it obsolete but having a stable
reference would be valuable, so it's being published as historical.

  This is a very well-written draft (I wish more I-Ds were written this
clearly, my own included). It notes, in the Foreward, that no changes
from the original SSL 3.0 document were made except to remove portions
that no longer apply and a few trivial editorial changes. I would like to
suggest some changes that I believe would fall into those buckets as well.

  Trivial editorial changes to give normative behavior normative wording:
   - section 5.6.1.1 Hello request, "After sending a hello request,
     servers SHOULD NOT repeat the request...."
   - section 5.6.1.2 Client hello after description of the contents
     of the SessionID, "Warning: Servers MUST NOT place confidential
     information in session identifiers, and MUST NOT let the contents
     of fake session identifiers cause any breach of security."
   - section 5.6.4, Certificate request, "Note: An anonymous server
     requesting client information MUST result in a fatal
     handshake_failure alert."
   - section 5.6.9, Finished, "It SHALL be a fatal error if a finished
     message is not preceded [spelling?] by by a change cipher spec
     message at the appropriate point in the handshake."

  Removal of wording that no longer applies in the current environment
  (and was not really unique to the US anyway):
   - section 5.6.3, remove note about US export law restricting RSA
     moduli to 512 bits or less.
   - Appendix D.1, remove mention of US export restrictions limiting
     RSA keys used for encryption to 512 bits.

  Trivial editorial change to conform to RFC structure
   - make section 7 into section 8 and move Appendix F into a new
     section 7 entitled "Security Considerations".

  regards,

  Dan.