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

Reconciling link authentication and key rotation



Nick brought this issue up in person, and I'm passing it to the list.
(George might be the best person to answer, but others should too?)

The spec says:

|A FWD/IP4 routing type indicates that the message must be
|retransmitted using the TLS/Mixminion transport protocol. The IP field
|represents the IPv4 address.  The KEYID field contains the SHA1 hash
|of the ASN.1 representation of the next node's transport public key.
|(Note that a node's transport key does not need to be the same as the
|key it uses to decrypt subheaders.)

The design doc says:

|Each subheader also includes the address of the next node to which
|the message should be forwarded, along with its expected signature key
|fingerprint --- the mix refuses to deliver the message until the next
|hop has proved its identity.

We clearly include a hash of the next hop's key in the message. But which
key? If transport key, then how do we deal with rotating the transport
key? (We could let a node provide all transport keys that have been
recently valid; but that's kind of kludgy. Or we could include more than
one hash in the message, but there's no space for that.)

I think I tend toward what the design doc says -- the hash included in
the message is a hash of the identity (signature) key of the next mix.

So when two nodes create a forward secure link with each other, they
each provide a certificate, including the transport key, signed by their
signature key? Is there a standard procedure for providing a new transport
key that's just as authentic (signed) as the old one?

--Roger