Re: [Gen-art] Gen-ART LC review of draft-ietf-keyprov-dskpp-10.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 23 April 2010 21:06 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=HkvVjmr3YAP5FwJW6XcGIlIh6TDDtBc3CYivQ+o+Mx7EgvucYXtKSQo9Vuec9R44hE vmw/x3EtrP+igCO5KKqttZ2s9dkGRTwQblxtl2DcMwR19Da+L0wPDgvFqU2iTeoeRQkA IKlOXANAc3MrezAvwygAmql4jZfpmm/FHETM8=
Message-ID: <4BD20BA9.1020008@gmail.com>
Date: Sat, 24 Apr 2010 09:05:45 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: andrea.doherty@rsa.com
References: <4BCF9EEC.3080004@gmail.com> <9ED76AB595E4944BB33D8998DE448D110968C3C9@CORPUSMX10B.corp.emc.com>
In-Reply-To: <9ED76AB595E4944BB33D8998DE448D110968C3C9@CORPUSMX10B.corp.emc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: gen-art@ietf.org, draft-ietf-keyprov-dskpp.all@tools.ietf.org
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-keyprov-dskpp-10.txt
Precedence: list

Andrea,

That would help a lot, in my opinion.

The one remaining question is whether anything can be said about
backwards compatibility. But as we know from (e.g.) SSL/TLS experience,
allowing negotiation down to deprecated algorithms can be viewed
as a weakness. Maybe there is nothing useful you can say in Version 1
about backwards compatibility for Version 2.

Thanks
   Brian

On 2010-04-24 08:48, andrea.doherty@rsa.com wrote:
> Brian,
> 
> Thank you for your review (attached).  
> 
> This email is a response to the issue that you raised regarding cryptographic algorithms.  Please let me know whether there is something I missed, as I want to ensure that we fully address your comment in the next update of the draft.
> 
> Rather than have one document for the protocol and another for algorithms, we have relied on versioning the protocol. I propose making the following changes to the document:
> 
> 1. Change Section 1.2 on "Versions" to read:
> 
> "There is a provision made in the syntax for an explicit version number.  Only version "1.0" is currently specified.
> 
> The purpose for versioning the protocol is to provide a mechanism by which changes to required cryptographic algorithms (e.g., SHA-256) and attributes (e.g., key size) can be deployed without disrupting existing implementations; likewise out-dated implementations can be de-commissioned without disrupting operations involving newer protocol versions."
> 
> 2. Add the following to the Security Considerations Section 10.6 on "Miscellaneous Considerations"
> 
> "Many protocols need to be algorithm agile.  One reason for this is that in the past many protocols had fixed sized fields for information such as hash outputs, keys, etc.  This is not the case for DSKPP, except for the key size in the computation of DSKPP-PRF. Another reason was that protocols did not support algorithm negotiation.  This is also not the case for DSKPP, except for the use of SHA-256 in the MAC confirmation message.  Updating the key size for DSKPP-PRF or the MAC confirmation message algorithm will require a new version of the protocol, which is supported with the Version attribute."
> 
> Andrea Doherty
> P.S. We will also address the Nits that you raised in the next update of the draft.
> 
> -----Original Message-----
> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
> Sent: Wednesday, April 21, 2010 8:57 PM
> To: draft-ietf-keyprov-dskpp.all@tools.ietf.org; General Area Review Team
> Subject: Gen-ART LC review of draft-ietf-keyprov-dskpp-10.txt
> 
> 
> 
>

[Gen-art] Gen-ART LC review of draft-ietf-keyprov… Brian E Carpenter
Re: [Gen-art] Gen-ART LC review of draft-ietf-key… andrea.doherty
Re: [Gen-art] Gen-ART LC review of draft-ietf-key… Brian E Carpenter