[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

comments on "shrinkwrap"

 
Some comments on the the proposed SPKI ShrinkWrap protocol (version 00).

o the references are missing 

o description of the used conventions, such as the byte order, is
  missing

o it looks like this protocol is for "reduction servers", systems
  that will do chain reduction for the client. Why can't the client
  do it itself ? Or is the server supposed to sign the result cert ? 
  (the draft doesn't say anything about signing)

  I guess that I could use this protocol to ask the target machine
  to reduce a cert chain for me. If I want to do business with the target
  machine again, I could give this reduced cert (sort of a "token") and
  this would speed things up. Is this correct ?

  This is guesswork; the draft should clearly specify the purpose and 
  scope of the protocol.

o How can the client be sure that the result cert is actually the
  true reduced cert ? Reduction can be done in a number of ways
  that are effectively the same but look different.

  -> The attacker (possibly MIN) can insert syntactically valid but
     empty certs in the client -> server stream. The server will reduce
     these and produce an empty result cert, sign it, and send it back to
     the client. The client can't see that the cert is actually useless
     and won't get service. (and can't know why -- because the error
     messages are are not very informative)

o p.5 :

   " This error message is sent by the verifier when too many certificates
     are included in a single transaction, a certificate is too large, too
     many other reduction sessions are in progress, or some other resource
     is unavailable. "

   Sounds useless. If the client gets this message, it can't know
   whether it should send the the same certificates again or not. 
   (i.e. the message doesn't say if the server is temporarily out of
    resources or is the certificate chain just too big).

   I'd suggest using english ASCII error messages (ftp-style perhaps).
   
- mj

Markku-Juhani O. Saarinen <mjos@ssh.fi>, SSH Communications Security Ltd
Follow-Ups: