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

Re: comments on "shrinkwrap"

Thank you for your prompt review.  However, I had some difficulty
understanding the details of your comments.

> From: Markku-Juhani Saarinen <mjos@ssh.fi>
> o the references are missing
>
I rarely work on the references for a draft until it is ready to be
published, unless a reference is unusual, and needed for understanding.

Which reference could you not find without a detailed reference section?
[SPKI]?  UDP [RFC-768]?


> o description of the used conventions, such as the byte order, is
>   missing
>
Pardon?  What byte orders are possible?  This is a network protocol, a
product of the IETF, and of course, network protocol byte order is used.
See RFC-1700 page 3.


> 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)
>
What is a reduction server?  Currently, the text says:

   The verification server (usually residing in the same machine as the
   key management daemon) listens for requests at TCP port XXX.  The
   verifier will attempt to do the chain reduction specified in [SPKI],
   and return a Reduction_Response certificate or an error message.

How would a client "do it itself?"

Are you sure that you read [SPKI] 3.3.1 pages 16-17?

Is there some confusion about a certificate in the context of SPKI?
Aren't all certificates signed?


>   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 ?
>
   SPKI allows the verifier to reduce a certificate chain to a single
   certificate.  This ShrinkWrap protocol utilizes TCP [RFC-761,
   RFC-793] to transport long certificate chains, and request a single
   certificate for subsequent use.


>   This is guesswork; the draft should clearly specify the purpose and
>   scope of the protocol.
>
Is the definition of "verifier" unclear in the context of SPKI?  "single
certificate"?  "subsequent use"?


> 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)
>
I don't understand.  What form would "syntactically valid but empty
certs" take?

How would the verifier mistake these for valid certificates?

How would the prover not "see" an empty result that has no Assertions,
when the prover sent certificates that had Assertions for verification?


> 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'm sorry you think this is useless.  Since the prover is attempting
verification, and cannot get verification, it really doesn't matter
which resource is unavailable.  Trying over again and again might be an
option, but I expect that most implementations will just log the problem
and stop.  I'll try to remember to note that in the next draft.

And how does the implementation know that its lack of resources is
temporary?  Keep a minute by minute histogram?


>    I'd suggest using english ASCII error messages (ftp-style perhaps).
>
How will that help?

Indeed, the IETF is moving away from using english ASCII messages.  Hard
to Internationalize.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: