IETF Logo Mail Archive

Re: [saag] Last Call: <draft-dukhovni-opportunistic-security-01.txt> (Opportunistic Security: some protection most of the time) to Informational RFC

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 15 August 2014 22:18 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606541A075D; Fri, 15 Aug 2014 15:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbl_J253dBBm; Fri, 15 Aug 2014 15:18:15 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CD41A075B; Fri, 15 Aug 2014 15:18:13 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C573C2AB29E; Fri, 15 Aug 2014 22:18:06 +0000 (UTC)
Date: Fri, 15 Aug 2014 22:18:06 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: saag@ietf.org, ietf@ietf.org
Message-ID: <20140815221806.GA5476@mournblade.imrryr.org>
References: <20140708150940.1412.7682.idtracker@ietfa.amsl.com> <53E4DF84.5030509@cs.tcd.ie> <53EDF437.6070108@cs.tcd.ie> <53EE7D42.2030900@bbn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <53EE7D42.2030900@bbn.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/rhBqEhCerFEeJjftMjCFh8JVssE
Subject: Re: [saag] Last Call: <draft-dukhovni-opportunistic-security-01.txt> (Opportunistic Security: some protection most of the time) to Informational RFC
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: saag@ietf.org, ietf@ietf.org
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Aug 2014 22:18:25 -0000

On Fri, Aug 15, 2014 at 05:36:02PM -0400, Stephen Kent wrote:

> Viktor did provide me woth a copy of -03, and solicited comments.
> 
> I am sorry to say that almost none of my comments seem to have been
> incorporated into the text, expect splitting the reference section
> as required by RFC conventions.

I must say I at least tried:

    commit 07e1bd3bd599266b07a162ae56b2e36fa3d4eead
    Author: Viktor Dukhovni <ietf-dane@dukhovni.org>
    Date:   Wed Aug 13 21:44:35 2014 -0400

	Steve Kent feedback.

     draft-dukhovni-opportunistic-security |  398 ++++++++++++++++++---------------
     1 file changed, 216 insertions(+), 182 deletions(-)

sorry if it is not what you had hoped, a lot more of the comments
were  addressed than might appear at first glance.  Not necessarily
by adopting the suggested changes as-is, but the comments were
useful, were taken seriously, and not simply ignored.

> I repeat my comments below. I have not bothered to remove ones that may
> have been addressed, since Viktor didn't even bother to reply to me to
> discuss the comments.

I've been integrating comments from multiple people burning the
candle at both ends for a whole week.  Cycles for individual
back/forth correspondence were not available.

My response was -03.  If you're just resending the comments for
stale versions of the work in progress, I can't really make use of
those I'm afraid.  They've already been processed and taken seriously.

> I also note something I didn't mention in my review. The Terminology
> section redefines "authenticated encryption" and defines "unauthenticated
> encryption" so that the terms means what Viktor wants. This introduces
> needless conflict with a widely accepted term (the former). If Viktor used
> the phrases "authenticated, encrypted communication" and "unauthenticated,
> encrypted communication" there would be no need for this contradictory
> terminology.

This is a reasonable new suggestion, I'll see whether this introduces
any problems in the context in which these are used.  It may well
reduce the need for the "this is not AEAD" diclaimers.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email