On Fri, Apr 23, 2010 at 07:13:14AM -0700, Paul Hoffman wrote: > Hi again. It appears that people have a hard time with the additional > random extension because it has limited applicability but I cannot > fully state what that is. The purpose here is to help fix problems > that shouldn't happen, and to be harmless when the bad situation > doesn't happen. This has led some people to think that an implementer > will therefore feel free to code more carelessly. I have a higher > respect for TLS implementers, but maybe I shouldn't. Why can't you add text explaining that this particular extension (as opposed to master-secret-input generally) can only be used with certain cipher suites and is intended only for the purpose of strengthening the maste secret computation. Stay away from discussions of entropy, except to explain that any random octet strings sent in cleartext contain zero entropy relative to attackers (since they can see it passively). Also, if you insist on saying that this extension can add entropy, can you explain what it does that the existing client_random and server_random don't do? > I am not sure that I can convince people of what seems like an obvious > fact: the PRNG on a system might fail in a way that the TLS > implementation cannot detect. If it could detect the failure, of > [...] Irrelevant: if the random octets being sent don't add entropy (because they are sent in cleartext) then this extension is completely orthogonal to PRNG failures. Incidentally, I think this I-D should specifically mention that the extension is a client and server Hello extension, which will help clarify for the reader that it is sent in cleartext (except for renegotiation, but note that when used in renegotiation this extension still adds no entropy if the same key exchange was used on the outer negotiation). > I still believe that this extension itself is harmless in all cases, > and helpful in limited ones; I have not seen anyone directly prove > otherwise. Having said that, I'm of course willing to go along with > IETF consensus if people think that the mere standardization of this > extension will somehow weaken existing implementations. I do believe it's mostly harmless; I am concerned that 2^16 max octets seems like a bit much, possibly a source of DoS attacks. I believe it's also useless. As such I'm not opposed to it as an Experimental or even Informational RFC. I'm opposed to putting known-useless things on the Standards Track. I don't feel too strongly about that: if the IESG and IAB don't mind putting known-useless things on the Standards Track, I can live with that, provided, in any case, that the decision to do so explicitly considers the utility of known-useless Standards. Note that I believe that draft-hoffman-tls-master-secret-input _is_ useful, and should be on the Standards Track (even if initially there are no uses of it also on the Standards Track). Nico -- _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf