Re: [sidr] Key learning procedures in BGPsec?

[Stephen Kent <[e-mail]>]

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