Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random

[Simon Josefsson <[e-mail]>]

Paul Hoffman <[e-mail]> 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