Brian,
I see that Richard already commented on part of your DH message, but
to close the loop:
- DH uses public keys. no need for quotes here, as they are
completely analogous to public keys for other asymmetric algorithms.
- what you described is ephemeral DH. it is one version of
DH, and not the one originally envisioned by Whit and Marty when the
invented this alg. (Their initial proposal called for long-lived DH
keys, because they wanted to bind the public keys to people, for
authentication.)
- static DH keys are used in certs. one way to use TLS with
DH is based on cert-based DH keys. SMIME supports static-static and
static-ephemeral DH modes (RFC 2631), but there is no pure ephemeral
mode for SMIME, for obvious reasons. so, in a number of IETF
contexts, DH is not used in a purely ephemeral fashion.
- not all PKIs use long-lived certs, c.f., RFC 3280 (proxy
certs). I am familiar with at least one large PKI-based system where
a cert is distributed to each user with a one-time-use limitation, as
part of a secure provisioning scheme. so, even when a key is in a
cert, that does not imply that it has a long lifetime.
- in some PKI contexts, very few certs are published, e.g.,
the typical TLS context. Here the TAs (which need not be certs) are
published via browser distribution, but server certs (and client
certs, when employed) are pushed inline. The same can be true for
SMIME certs used to verify sigs, i.e., they can be passed inline vs.
published. so,
I was not able to follow the proposal you outlined in your long
message about using hash values and nonces distributed via DNSSEC.
However, I would agree with Ross's comment, i.e. any secret value
used in the computation of a hash chain is the moral equivalent of a
private/secret key. Thus compromise of that per-router secret also
will have adverse consequences. I also will note that non-repudiation
is not the required security service in this context. One needs
broadcast authentication, a service offered by digital signatures.
The authentication is "broadcast" in that an AS does not know all of
the other ASes that will have to verify a sig (of whatever form) on
an update.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
