ietf-openpgp
[Top] [All Lists]

Re: Four Points.

2004-10-27 15:20:23

Good points. I'll incorporate them when I have a moment. I did some work on the draft yesterday and would have sent out a new one but the pre-meeting close on new drafts was Monday.

My only comment myself is that I think there's a lot of implementation notes in the draft as it is, and if anything too many. There is also a lot of paternal tongue-clucking about what people should do when there's an error. I'll tidy up, but I think there is if anything too much as it is.

        Jon

On 27 Oct 2004, at 4:30 AM, Ian Grigg wrote:


Four points, indicated by roman numerals.

The first suggests a change of substance.

iang

====================================================================
     5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18)
     ...

i. Can we migrate Tag 18 to a MUST support, or at least a MUST read?
Something like:

   A conforming implementation MUST support decryption of this
   packet.

( At the moment, it is a "SHOULD prefer" which I take to mean an
implementation should strive to send out/encrypt these packets when
it has a choice.  That's fine, as long as there is some statement
on reading/decrypting.)

When was this feature introduced?  I suspect enough time has
passed, and enough implementations are doing it that we can
move this to a MUST.  It is certainly the standard that these
days, protocols should be MAC'd or MDC's in some fashion.



ii. It seems that section 5.13 duplicates much of the special
CFB processing rules, except for a caveat at the end.  Maybe
duplication is needed here for care reasons, or maybe this could
more readily refer to "12.7. OpenPGP CFB mode"  Just a thought.



   ...
   During decryption, the plaintext data should be hashed with SHA-1,
   including the prefix data as well as the packet tag and length field
   of the Modification Detection Code packet.  The body of the MDC
   packet, upon decryption, is compared with the result of the SHA-1
   hash.  Any difference in hash values is an indication that the
   message has been modified and SHOULD be reported to the user.
   Likewise, the absence of an MDC packet, or an MDC packet in any
   position other than the end of the plaintext, also represent message
   modifications and SHOULD also be reported.

iii. The latter 2 sentences above seem less severe than the
similar sentence in the below section 13, section starting
"In late summer 2002..." (below, at end).

     * In late summer 2002...
       ...
       An implementation
       MUST treat an MDC failure as a security problem, not merely a
       data problem.

I'd suggest adding
reference to the MUST treat as a security problem, above.
Perhaps:

   ...  Any difference in hash values is an indication that the
   message has been modified and MUST be treated as a security
   problem.  Likewise, the absence of an MDC packet, or an MDC
   packet in any position other than the end of the plaintext,
   also represent message modifications and MUST be treated as
   a security problem.  These events SHOULD be reported to the
   user.

Although I think it could be tidied up more:

   Any failure of the MDC indicates that the message has been
   modified and MUST be treated as a security problem.
   Failures include a difference in the hash values, but also
   the absence of an MDC packet, or an MDC packet in any
   position other than the end of the plaintext.  Any failure
   SHOULD be reported to the user.




     13. Security Considerations

     * This specification uses Public Key Cryptography technologies.
       Possession of the private key portion of a public-private key
       pair is assumed to be controlled by the proper party or parties.

iv. This seems unworthy of stating, but either way, might be better written:

     * This specification uses Public Key Cryptography technologies.
It is assumed that the private key portion of a public-private key
       pair is controlled and secured by the proper party or parties.

====================================================================



<Prev in Thread] Current Thread [Next in Thread>