Ben Campbell wrote: > I think it's reasonable to say that good administration practices involve > random key generation, and that the interface should not prevent the entry of > arbitrary hex strings. But the text says things like > > "When creating keys, it is RECOMMENDED that keys be derived from a > cryptographically secure pseudo-random number generator (CSPRNG) instead of > allowing administrators to invent "secure" keys on theur [sic--add that as > an editorial comment] own." > > That part seems to say explicitly that the implementation shouldn't let > admins enter their own keys.
It says nothing of the kind. It says that administrators *inventing* their own keys is bad practice. They are still allowed to *enter* the keys into the administration interface. People are bad at creating secure passwords. That's all it's trying to say. I don't understand why this is controversial. > I accept that, and my real concern is not about allowing the admin to enter > arbitrary hex strings. My concern is that it also says the admin should not > be able to enter their own keys (see above.) How do you expect the interface > to prevent the use of "invented on their own" keys, while allowing arbitrary > hex strings? I'm not a jackass, and you shouldn't insinuate that I am one. The text says keys should be DERIVED from a secure source. Do you understand the DERIVING keys is about CREATING them? And that is a completely different process from ENTERING keys into an administration interface? > Are you explicitly recommending against doing client authentication in the > DTLS handshake? Now you're being deliberately rude. > That seems inconsistent with the 3rd paragraph, that says "Any authentication > credentials for that client are then determined solely from the client > identity, and not from an IP address." The authentication credentials it's talking about are the ones that the server has. i.e. when the client connects to the server, the server must have some pre-configured credentials for that client. It uses those credentials to authenticate the client. Is that clear enough? Or can you suggest alternative phrasing which prevents people from deliberately misunderstanding the text? > But, my concern was not just about servers authenticating clients. Paragraph > 5 says: > > "authentication credentials for that relationship should also be statically > configured. That is, a client connecting to a DTLS server SHOULD be > pre-configured with the servers credentials (e.g. PSK or certificate)." > > That seems to exclude the possibility of the client being pre-configured with > a host name for the server, No, it doesn't. And it's ridiculous to claim that. Especially when it's in response to MY statement saying that such information is statically pre-configured. > then the server presents a certificate issued from a trusted CA that includes > that host name. This is a common TLS/DTLS use case. Now, maybe you consider > that to still be static configuration of credentials, since the host name and > the trust anchor need to be statically configured. But your statement that > there is no (as in never?) binding of a certificate to a host name makes me > think otherwise. (Or at least confused me.) It's not hard, apparently. I talked about servers checking client certs. You turned that into something clients checking server certs. > I assume you expect to do something with trusted CAs, since paragraph 6 talks > about their configuration. I have no idea what you assume or why. This review is done. You've stepped past the bounds of social propriety into insinuating I'm an idiot who engages in magical thinking, among other deliberate misunderstandings. I'll try to weasel-word the document some more. But it's hard to make the document idiot-proof. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
