[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Photuris
Now to address the ones that came _after_ midnight....
> From: rivest@theory.lcs.mit.edu (Ron Rivest)
>
> Page 9: What is the length of the "Type" field (in this and the
> other message types)?
>
one octet. Fixed.
> Also: There is no explicit "version number" in the header anywhere,
> which makes me nervous. Is the "Reserved" field (which is present
> in all but the Cookie_Request) intended for this purpose? If so,
> perhaps it should be called "Version_Number" instead of "Reserved".
> If not, perhaps a "Version_Number" field should be added.
>
There are _two_ version numbers:
1) the major version number is the UDP port. A protocol that is truly
different will need another port.
2) the minor version number is the Scheme. A protocol that differs
only in small ways, such as moduli, will use a different scheme
number. Also, this field was increased from 8 bits to 16 bits.
NSA claims they are going to have thousands of variants, including
some which don't have all the same steps after the cookie exchange.
> Page 10: [Size of cookies]
>
> The size of the cookies (16 octets) seems unnecessarily large.
> Why not 8 octets each?
>
Very simply, it's the output of MD5.
Have to do all 128 bits of work, whether or not we use all of the bits.
Meanwhile, the Photuris exchanges are so rare (every 10 minutes or so)
that even on bandwidth constrained links, this size isn't very big.
So, no real savings in terms of computation time or bandwidth, which are
the important factors.
> This argument is perhaps not correct if the adversary can detect
> when he has success; but this I don't see how to do unless he uses
> his real IP address, which he is unlikely to do.
>
Correct. Which is the second sentence in the design decision covers.
ATM clouds. They claim to be gigabit speeds. The field also needs to
be big enough to be improbable when 2^32 cookies a second can be tested.
Even then, 8 bytes is probably enough, from a theoretical standpoint.
> Even then, if the recipient increments his secret value for computing
> cookies every so often, then the adversary can't keep pounding on a
> discovered cookie.
>
Yes, and probably should change more often on the faster links.
> 2^{-64} is really quite small...
>
> (If you think it is too big you should certainly never use DES, since
> its key is only 56 bits long...)
>
Yeah, we all agree on that!
> Page 11: Section 2.5 Variable Precision Numbers
>
> It seems possible that a variable-precision number could have
> a size of 0 octets. Indeed, many of the examples given have
> exactly that (e.g. the Validity-Choice field on pages 27--28 are
> shown as 16-bits, which must be a size of 0). Yet the value
> of such a quantity is undefined. Is it 0?
>
Yes. Fixed:
A value of zero is represented by a Size of zero, and no value field.
A value of one is represented by a Size of one, and no value field.
However, you've mistaken the validity-choice field. That field is an
attribute, which has a type-length format.
The validity-choice is followed by the Verification, which is a separate
variable precision number.
If you look carefully, you will notice that the MD5 attribute is
16-bits, and the VPN Size is 16 bits, making the hash value align
neatly on the next 32-bit boundary. (of course, this cannot be depended
upon for other algorithms, but I did optimize for the defaults.)
> You might also leave an "escape" for longer numbers. I always
> worry about fixed upper bounds on the lengths of things. In the
> case of Photuris, for example, a single such variable-length
> number is supposed to be able to contain a certificate chain.
> When everyone is done throwing everything they think they want
> in the certificates (e.g. explicit statements of certification
> policies translated into all languages), certificates might be
> a lot bigger than we expect, and we might overrun this limit with
> a long certificate chain. (I hope not, but I see no reason to
> needlessly restrict this here...)
>
There is also a maximum size on the UDP packet of 16 bits.
> There are lots of standard techniques for handling such things
> (presumably ASN.1 DER has one such technique), or you could
> do something ad-hoc (reserve 0xFFFF to mean that the length
> is in the next four bytes, followed by the value, etc..)
>
True -- anybody have any preferences? Know off the top of their head
what PGP does? X.509?
> Page 23, Key Generator Choice:
>
> It is not clear to me how to take the output of the Key
> Generator Choice and use it as a session key. Do I use the
> the first bits or the last bits, or what? (For example, the
> discussion of MD5 on pages 44-45 only says that when MD5 is
> chosen as the Key Generator Choice, it generates 128 bits of
> keying material. It does not say how to pick a subset of those
> bits for an algorithm that might need fewer than 128 key bits,
> nor does it describe what to do if the algorithm needs more
> (for example, RC5 takes a variable-length key as input, and could
> easily make use of more than 128 key bits.)
>
Correct. That's why _each_ algorithm which _uses_ a key specifies how
it uses the bits.
MD5:
... its SPI session-key uses the entire Key-Generator-Choice
generated keying material.
DES-CBC:
... its SPI session-key uses the most significant 64-bits of
Key-Generator-Choice generated material. The least significant bit
of each octet is ignored (parity).
RC5 (in extensions draft):
... its SPI session-key uses the most significant Key-Size bits of
Key-Generator-Choice generated material.
> Page 23: Signature:
>
> "The field may be any integral number of octets in length,
> as indicated by its Size field. It does not need to have
> any particular alignment (the 32-bit alignment shown in
> the figure is merely for convenience in the illustration)."
>
Thank you. Done.
> Page 25: "accept only those users found there" -->
> "accept only those users whose certificates are found there".
>
Done.
> Page 32: Is the error code 3 supposed to be used as well if the
> certificate fails to verify (as opposed to the certificate
> being OK, but the signature failing)? Probably another error
> code would be better...
>
Yes, as currently written.
Why? Usually, you don't want to give out that kind of information....
Such as when a username is unrecognized, but the same error is given as
if the password is invalid.
> Page 22 and page 32:
>
> Is an Error_Message sent if a Signature_Message is received
> with an invalid Signature-Choice or an invalid Key-Generator-Choice?
> If so, what error code is to be used?
>
Nothing currently written. For other messages, either!
How about a new error code #5 indicating invalid attribute choice?
Or would it be better to just silently discard the bad message? Could
be an attack where an invalid message is sent during an exchange to
abort the exchange.
Needs thought.
Bill.Simpson@um.cc.umich.edu
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2