Ben Campbell wrote: > -- 3.2, last paragraph: > > I'm still confused about how this is a bid down attack. > > [The author replied that, when secure and insecure packets are allowed from > the same client, a > malicious or broken client can choose the insecure one. That's bad, > when the intent is to use DTLS.] > > While I agree that's bad, I don't see how it qualifies as a bid-down attack. > One assumes a malicious client already has access to the cleartext messages. > Are we talking about an MiTM "client"? Are there attacks where a third party > can induce the client or server to send unprotected packets, even with no > signaled negotiation? I can imagine one for the specific case where a node > falls back to clear text if DTLS packets fail; an attacker could induce > failures for DTLS packets, but that is covered elsewhere. > Comment not addressed.
The point of DTLS isn't just to protect from malicious clients. It's to protect clients and servers from malicious third parties. Those parties can read all RADIUS/UDP traffic now. They will not be able to read RADIUS/DTLS traffic. These third parties could actively cause DTLS to fail, and force the client and server to use an insecure transport. This sounds like a downbidding attack to me. Do you have another definition for downbidding which you are using? Or would another term be acceptable here? > -- 6, 2nd and 3rd paragraph: > > The RECOMMENDation to allow administrative entry of keys and to derive keys > from a PRNG seem contradictory. > > > [The author responded that it's a requirement that implementors allow > administrators to enter > strong keys. but I don't get that from the text, which both RECOMMENDS that > the interface allow people to enter human readable hex strings, and that keys > should be derived from a PRNG instead of letting administrators make up keys. > How can it be both? Because the administrators have to enter the same key on both the client and server. If one machine auto-generated a secure pseudo-random number, it would still have to be transported to the other, and entered in an administration UI... via the method suggested in the document. > I don't see how an interface could prevent administrators from entering > better keys. Perhaps the intent is to offer or interface with tools for > random generation, or to scan entered keys for things with insufficient > entropy?] Have you ever entered a password in a poorly designed on-line form? "special characters like !, %, &, $, etc. are not allowed". Vendors do this today with RADIUS systems, for the shared secret. Such idiocy should be discouraged. > -- 10.3, 2nd paragraph: > > This is redundant and inconsistent with previous normative requirements in > 5.1.1. > > [Author replied that it's worth reiterating security issues, and that the > sections were now consistent. But there's still conflicting normative > statements here. 5.1.1 says implementations SHOULD monitor number of > sessions. This section says MUST. > > And I still assert that, even if the security issue is worth reiterating, it > should not be reiterated _normatively_. Doing so creates confusion about > which text is authoritative, especially when they conflict. Even if they > don't conflict now, it's easy for future updates to accidentally create > conflicts.] I'll address that. > -- 10.4 5th and 6th paragraphs: > > Paragraph 5 says credentials should be manually configured, and strongly tied > to a host name. It is not clear to me from the text whether using a > certificate (perhaps issued by a trusted CA) to bind the credentials to the > hostname is permissible. The use of "manual" would seem to disallow that. But > paragraph 6 talks about configuring trusted CAs. > > [The author commented that dynamic discovery was out of scope--but I don't > think anything about this implies dynamic discovery. (e.g. configuring a > client to talk to foo.example.com, then using using a CA to validate that a > server certificate to ensure that that server really is foo.example.com is > not the same as dynamic discovery.] I'm not sure what the objection here is. The point is that when a client connects to a server, the server uses the source IP to determine which set of credentials to use. There is no "binding" of a certificate to a hostname. The system is configured to verify that "when you see packets from IP X, they must be using certificate C". This configuration is independent of the certificate contents. > -- 10.5, last paragraph: > > This seems to be making normative statements about RADIUS/UDP. It's not > appropriate to make those statements here unless this draft normatively > updates RADIUS/UDP. (Which and experimental rfc shouldn't do.) The consensus of the WG was that the text belonged. > Nits and Editorial Comments: > > > -- idnits reports: The document seems to use 'NOT RECOMMENDED' as an RFC 2119 > keyword, but > does not include the phrase in its RFC 2119 key words list. OK. I'll fix that. > > -- 6.1, first paragraph: "subsystem does not need to multiple > multiple sessions on one socket" > > I think one instance of "multiple" was intended as a different word? "manage multiple sessions on one socket" _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
