IETF Logo Mail Archive

Re: [saag] draft-iab-crypto-alg-agility-00

S Moonesamy <sm+ietf@elandsys.com> Mon, 07 April 2014 01:09 UTC

Return-Path: <sm@elandsys.com>
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 F13FB1A0434 for <saag@ietfa.amsl.com>; Sun, 6 Apr 2014 18:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.8
X-Spam-Level:
X-Spam-Status: No, score=-3.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, GB_I_LETTER=-2, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 7DHaV75V_o3C for <saag@ietfa.amsl.com>; Sun, 6 Apr 2014 18:09:40 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9314E1A01DD for <saag@ietf.org>; Sun, 6 Apr 2014 18:09:40 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.147.33]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s3719JSl000471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Apr 2014 18:09:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1396832973; bh=QymmQOLAGvFaoFPvg6+/bRkL4n2VKhS+AL9/xQs0IEE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=LMC7YbTU9bB7qyMQcplIyV/ypyZ8NuQTEvYnzc9EuEHJqT8Caigy42Rfa3bV1QNbi /7FG1uCCwAn0mMhSqPQCNSTegpEDDDPJ1BTYzhHmZhxqscacvdvvfgt7PfhlOIGn73 wczAe8H2pGQLobvSEHy0nzjTLwRVSbZckQJE7VD0=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1396832973; i=@elandsys.com; bh=QymmQOLAGvFaoFPvg6+/bRkL4n2VKhS+AL9/xQs0IEE=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=B6nNsr9MKR8NUHt1uU3myvfOyZhHbfwMOTdJ/w2GsGghA7pGTU5XWnkXo38o2Bsjd luwNv2ySpdsb/+glSGYZcd+gWRJLxtRYJoCqOdDJEWfF3Hw9y+82HiL583hSuvHzvl kWolHr6qrKBAQS+xU9IHeh4qJ3xpakcuQh3klU1A=
Message-Id: <6.2.5.6.2.20140406164511.0bf19e48@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sun, 06 Apr 2014 18:05:35 -0700
To: "Salz, Rich" <rsalz@akamai.com>, S Moonesamy <sm+ietf@elandsys.com>, Ben Laurie <ben@links.org>, Russ Housley <housley@vigilsec.com>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp .akamai.com>
References: <5999195E-9073-4649-A224-BF71BA61CBAF@vigilsec.com> <CAG5KPzzqSQ++YpQcnYesecL0GQ0+J0ieMXBrNk6txMAC58xEQQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD0@USMBX1.msg.corp.akamai.com> <6.2.5.6.2.20140406121529.0bd2d730@resistor.net> <2A0EFB9C05D0164E98F19BB0AF3708C7120A04EBD7@USMBX1.msg.corp.akamai.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Archived-At: http://mailarchive.ietf.org/arch/msg/saag/nKA6VT7DRj9b7FbTH0YdXEy_EJ8
Cc: saag@ietf.org
Subject: Re: [saag] draft-iab-crypto-alg-agility-00
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Mon, 07 Apr 2014 01:09:45 -0000

Hi Rich,

Replying again based on the comment from Stephen Farrell.

At 14:54 06-04-2014, Salz, Rich wrote:
>Having said that, I think the agility document should say "protocols 
>and data formats."
>
>I was arguing (with Google folks, mainly) for crypto identifies in 
>the CT data structures before the WG was convened. And I still think 
>that CT should be brought in line with the letter and spirit of the 
>agility document:  identify the mechanisms used, in the data types. 
>If interop is a concern, make the current set be MUST and say SHOULD 
>NOT implement anything else.
>
>CT should not be a special case exemption from the agility spec.

If I understood draft-iab-crypto-alg-agility-00 correctly, the point 
is to insulate the application layer protocol from the cryptography 
altogether.  The data formats would not be part of the 
protocol.  What is being done is securing the transport.  The issue 
may be clearer if the interoperability parts of 
draft-ietf-trans-rfc6962-bis-00 were identified.

Regards,
S. Moonesamy

v2.8.7 | Report a Bug | By Email