Dave Crocker wrote:
Stephen Farrell wrote:
I don't think that exchanging public (or even private, yuk) keys between
ADMDs is internal. Nor do I think that encouraging such would be likely
to sit well when our specs are reviewed later on. (E.g. by secdir, where
I would raise the issue if I drew the document - must check if that can
happen:-)
Yeah, that's what I thought you were going to say.
Sometimes security-type-opinions are pretty easily predictable, I
agree:-)
I also agree that that doesn't make me right.
With respect to the interaction between signer and validator -- and that is what
-base does -- in fact the exchange of private keys is *entirely* an internal
matter for the signer to deal with.
You make an ostensibly reasonable case; one with which I disagree as it
happens.
There are lots of inter-organization activities needed for administering many
different Internet protocols, and we do not specify how they are done. For
example, do we specify how coordination must be done between a domain name
holder and the third party administering their DNS entries?
What makes the specifics of communicating private keys, among consenting
organizations, a matter to count as a *prerequisite* for approving the
interaction between signers and validators?
Well, because private keys are not meant to be sent about willy-nilly,
that's an inherent part of the game. And they're mostly not simple
values that are exchanged like strings either (see pkcs#12 if you
like self-inflicted pain;-). Even public keys are generally transported
in odd formats like certificates etc. that easily generate a lack of
interop. if different folks implement things differently.
I realise that some of the niceties of key management will be over the
top for DKIM, but as someone once said, DKIM has to use signatures since
that's the only mechanism available, so we have to live with some of
the crypto-baggage. (That may even be you I'm misquoting there.)
It seems to be pretty frequent that folks confuse the concept of
internal/external for an Internet service's architecture, with the vagaries of
administrative mix, for portions of the service. This leads to requiring too
much up-front specification, delaying release of work that is factorable and
entirely useful on its own. (A classic "big system syndrome" problem for
standards and systems designers.)
You do have a point, but I don't agree that it applies in this case.
Where the delagatee supplies a public key to the delegator then its
quite likely that that public key will never get updated. That's a bad
thing.
1. We are not specifying how frequently keys must be changed.
Correct. But neither do we think its ok to have most keys never
change, right?
2. We cannot dictate how frequently key are changed.
Sure. But if change is needed, IMO we need to say how to do it (at
least one way) to get interop. (Note - this doesn't apply to
key records from base where in this respect things are IMO fine
right now.)
3. Your assertion that there is, somehow, a particular human/operations impact
when the private key crosses the boundary between partner organizations is
interesting. Do you have an empirical basis for asserting it? The observation
is likely to have a significant impact on quite a bit of Internet administration
and the standards for it.
Do I have quotable stats? Not offhand. Have I seen this happen in the
real world. Yes. Numerous times. And with messages between banks
involving payments. (In one case a single-DES MACing key was unchanged
for >5 years and was also shared between the bank and >>1 customers.
Major yuk.) I do think this happens for human factors reasons; operators
see the system working fine since when crypto works, its basically
invisible. They easily miss the relationship between staff changes or
retiring equipment and changing those key things that some consultant
setup a few years ago.
I'm *not* saying that we have to invent any kind of key management, but
if keys are to be sent between domains (even in a minority of cases),
then we do need to have analysed those cases and shown that there's an
easy way to handle them.
No we don't. That is why it is important to recognize that the issue is
*entirely* internal, with respect to the portion of the service that we *are*
designing.
Fair enough. We disagree.
IMO, the SSP DSD mechanism is potentially
better from this angle since its ok to exchange signer names once and
Yes, path registration is a very appealing concept... except for the problems
with it, such as completeness and keeping things current.
If I am understanding the DSD concept, it pertains to publication of an
authorization list. So I think you are confusing publication of signer agent
name, with the choice between NS delgation to an outsourced signer vs. giving a
private key to them.
Stated differently: I believe that publication of domains authorized to do
signing provides the same functionality as NS delegation of a sub-domain, albeit
with more mechanism, more complexity, and more risk. But it has nothing to do
with the way private keys are exchanged.
Offhand, I am not seeing why the communication of private keys is all that
different when the signing group is outsourced than when it is exchanged within
an organization.
I think Jon answered the above better than I could, so I won't make it
worse:-)
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html