Paul Hoffman <paul(_dot_)hoffman(_at_)vpnc(_dot_)org> writes:
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.
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
course it should shut down, screaming. But lots of PNRG failures seem
undetectable to the implementation but possibly detectable to an
attacker. Remedying that was the motivation for these drafts. If that
problem is not of interest, or is considered to induce developers to
do a worse job, I can see why people would not want these drafts to
move forwards.
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 disagree with your description of people's objections. My impression
is that people actually have been arguing precisely that the draft does
not solve the problem you describe.
My main concern with the document is that the problem you describe isn't
sufficiently well explained in the document itself for implementers and
application protocol designers to understand when use of the extension
is warranted.
If the PRNG is broken, your draft does not solve the many other places
in TLS that requires a working PRNG to provide a secure protocol: key
generation, CBC IV, random record padding, etc. If you have 5 weak
links in a chain, making one of them stronger is not terribly relevant.
I sympathize with the goals of the draft, and I believe it would help in
theoretical proofs about entropy flows in secure protocols.
I don't believe implementing and enabling the draft would have any
overall positive effect on security on the Internet when all things are
considered, therefor I'm having a problem with it going on the standards
track.
/Simon
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf