Subject: [secdir] secdir review of draft-housley-aes-key-wrap-with-pad-03

From: Dave Cridland <[email-masked]>
Date: Tue, 16 Jun 2009 17:26:01 +0100

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 document is not within my expertise, but I felt it was mostly  
adequately clear for someone not fully familiar with the underlying  
cryptography. The Security Considerations in particular cover  
everything I was expecting to see, and some information I'd not  
previously been aware of.

However, the 7th paragraph is somewhat surprising to me, beginning:

   The key wrapping technique specified in this document requires the
   length of the key data to be at least nine octets because a single
   application of the AES codebook is sufficient to protect up to  
eight
   octets of key data.  In particular, if the key data consists of  
eight
   or fewer octets, then a 64-bit integrity check value could be
   prepended to the key data to form a single 128-bit block.  For

Was this intended to be:

   [...] application of the AES codebook is INsufficient to protect  
up to eight [...]

Otherwise, the paragraph doesn't fully make sense to me.

Aside from this, the document is clear and, in my opionion, suitable  
for publication.

Dave.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 22 Jun 2009 15:41:11 -0700

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 is an experimental protocol for creating "traceable anonymous certificates". These certs split the authority into two entities, one who issues an end-entity cert with a pseudonym, and another who verifies that the end entity has the private key.

There are many pretty deep security issues with the proposal, mostly that there are many ways where the anonymity of the user can be exposed. In many ways, this represents leap-of-faith anonymity. The security consideration section swings around wildly on recommendations for how a user can maintain their anonymity, but at least mentions a few times that this is all pretty much conditioned on factors over which the end entity has no control.

On a personal note, I doubt that this will be at all useful in practice. The end entity is trading off trusting one CA to not reveal personal information against two CAs with not colluding plus having to get multiple certs over time from different CAs. Having said that, there are probably no security/privacy considerations that are not already covered in the document.