Re: Last Call: draft-hoffman-tls-additional-random-ext (Additional Random Extension to TLS) to Proposed Standard
The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Additional Random Extension to TLS ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-05-19. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-hoffman-tls-additional-random-ext-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19570&rfc_flag=0 The community consensus was pretty clear on this one. The document will not proceed. I'm going to move the status to dead. spt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
On Tue, April 27, 2010 3:23 am, Dean Anderson wrote: > On Mon, 26 Apr 2010, Nicolas Williams wrote: > >> On Mon, Apr 26, 2010 at 04:18:33PM -0500, Marsh Ray wrote: >> > Taking ietf@ietf.org off of CC list as this seems to be very TLS >> specific. >> >> This is an IETF LC, not a WG LC; IETF LC comments should be sent to >> i...@ietf.org. If anything, we might want to drop t...@ietf.org. > > I cannot post to IETF@IETF.org, for dishonest and apparently unlawful > reasons. I won the consensus call in the PR Action, but the consensus > was fraudulently reported. But the PR Action itself is not consistent > with the legal requirements to suspend member rights in a member > corporation: The law requires a vote of the membership, and that 51% of > the membership vote for the suspension/expulsion. There are other legal > issues (e.g. antitrust) involved with preventing corporations from > participating in a standards body, but I won't go into those here. > > However, fact remains that I cannot post to i...@ietf.org. All the more reason to drop t...@ietf.org! Dan. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
Marsh Ray wrote: http://tools.ietf.org/html/rfc2246 : 7.4.1.2. Client hello [...] random_bytes 28 bytes generated by a secure random number generator. Not pseudorandom, "generated by a secure random number generator". No, if you look at the implementation notes in RFC 5246, you will see that it really is meant to be pseudo-random: Appendix D. Implementation Notes D.1. Random Number Generation and Seeding TLS requires a cryptographically secure pseudorandom number generator (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs based on secure hash operations, most notably SHA-1, are acceptable, but cannot provide more security than the size of the random number generator state. A server especially would not want to use an RNG (over a PRNG) since an attacker could rob it of all its entropy by sending a flood of bogus ClientHellos. In my own implementation, the only place I use a true RNG is when a client generates an RSA premaster secret. (It may also get used in EDH when generating private keys, but that happens internal to OpenSSL, and I haven't looked at that code.) Mike ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
On 4/26/2010 4:36 PM, Nicolas Williams wrote: > On Mon, Apr 26, 2010 at 04:18:33PM -0500, Marsh Ray wrote: >> Taking ietf@ietf.org off of CC list as this seems to be very TLS specific. > > This is an IETF LC, not a WG LC; IETF LC comments should be sent to > i...@ietf.org. If anything, we might want to drop t...@ietf.org. That makes sense. > Thus ISTM that we should first consider either whether the client_random > and server_random fields are sufficient _assuming_ compliant [P]RNGs or > consider how draft-hoffman-tls-additional-random-ext can ameliorate TLS > implementations that have poor [P]RNGs. I think the current space in the protocol of 224-256 bits in each direction is sufficient. Well-known techniques exist for compressing whatever format of entropy is available into that space. > Ah! Perhaps what's happening here is that Paul intends for the > additional random inputs to be provided by the _application_, from > outside the TLS implementation. In that case an application could make > secure use of TLS even when the underlying TLS implementation has a poor > [P]RNG. That would make draft-hoffman-tls-additional-random-ext much > more interesting (combined with some editing I'd drop my objections). But that facility could be provided by the implementation API without any need to extend the TLS protocol. Indeed, OpenSSL provides a function to contribute entropy into its RNG. Thus I do not think draft-hoffman-tls-additional-random-ext should be advanced as a standard. - Marsh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
How is the sub-thread on RNGs and PRNGs relevant here? If nodes don't have good enough RNGs/PRNGs/seeds then draft-hoffman-tls-additional- random-ext won't help. If they do have good enough RNGs/PRNGs/seeds then the existing client and server randoms are good enough. Either way draft-hoffman-tls-additional-random-ext adds nothing. Or, what am I missing? (The RNG discussion is worth having, don't get me wrong, just not in this context.) Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
On Mon, Apr 26, 2010 at 04:18:33PM -0500, Marsh Ray wrote: > Taking ietf@ietf.org off of CC list as this seems to be very TLS specific. This is an IETF LC, not a WG LC; IETF LC comments should be sent to i...@ietf.org. If anything, we might want to drop t...@ietf.org. > On 4/26/2010 3:38 PM, Nicolas Williams wrote: > > How is the sub-thread on RNGs and PRNGs relevant here? > > The draft was said to strengthen some properties of the protocol, > particularly entropy in the RNG. In order to evaluate the draft, we need > to agree on what those properties are supposed to be and how they affect > the different protocol structures. By analogy to legal review, if we don't need to reach the issue, then we don't need to discuss it. RNG/PRNG matters either apply, in which case we can might in, or they don't. I believe it is correct to assert that we don't need to discuss [P]PRNGs in detail, or even at all if we agree that the existing TLS client_random and server_random fields are sufficient. Thus ISTM that we should first consider either whether the client_random and server_random fields are sufficient _assuming_ compliant [P]RNGs or consider how draft-hoffman-tls-additional-random-ext can ameliorate TLS implementations that have poor [P]RNGs. Ah! Perhaps what's happening here is that Paul intends for the additional random inputs to be provided by the _application_, from outside the TLS implementation. In that case an application could make secure use of TLS even when the underlying TLS implementation has a poor [P]RNG. That would make draft-hoffman-tls-additional-random-ext much more interesting (combined with some editing I'd drop my objections). Paul? Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
On Mon, Apr 26, 2010 at 05:10:35PM -0500, Marsh Ray wrote: > On 4/26/2010 4:36 PM, Nicolas Williams wrote: > > Ah! Perhaps what's happening here is that Paul intends for the > > additional random inputs to be provided by the _application_, from > > outside the TLS implementation. In that case an application could make > > secure use of TLS even when the underlying TLS implementation has a poor > > [P]RNG. That would make draft-hoffman-tls-additional-random-ext much > > more interesting (combined with some editing I'd drop my objections). > > But that facility could be provided by the implementation API without > any need to extend the TLS protocol. Indeed, OpenSSL provides a function > to contribute entropy into its RNG. There is a lot of inertia in installed base. If there are implementations that allow for arbitrary extensions then Paul would have acase. However, I suspect there are not; unless I'm missing something then I agree with this: > Thus I do not think draft-hoffman-tls-additional-random-ext should be > advanced as a standard. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
On Mon, Apr 26, 2010 at 12:12:36PM -0500, Marsh Ray wrote: > On 4/23/2010 12:12 PM, Nicolas Williams wrote: > > > > 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. > > Even though they are sent in-the-clear, the random data do serve the > same useful purpose as the existing [cs]_random data. This is true, but those are already plenty large enough. If the argument is that the client and server random from the TLS hellos are not large enough, then let's hear that argument. > Because they are unpredictable they make offline precomputation harder. > I think of it as adding entropy into offline computation, without adding > any to the online computation. The right term for this might be "confounding" (but then, it's a term I've only seen in use in the context of Kerberos). > I would think that the current 224-256 bits is enough to thwart offline > attacks. The attacker would need something proportional to 2**224 > storage to store the results of his precomputation, no? Right. > Assume attacker can knock off 2**42 using rainbow table techniques (he > has a 1024 unit cluster of CPUs which can each compute one result online > every clock at 4GHz). So he needs to store something like 2**182 results > from his precomputation. Assuming 1 bit per result, probably you'd need > more. Raw HDDs are the cheapest form of mass storage today at $75/TB > (10**12 bytes?). Such a system would cost > $ 57468582782470832188438013518137000.00 > today. Of course those costs are likely to decline over time. 2^182 bits of storage is not remotely a realistic number: it's about the number of atoms in the Solar system (if I have my math right). > > 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. Actually, I withdraw the above quoted comment: it's already the case that a hello can bear large extensions. > There is a danger with this proposal. In no way do I mean to suggest > that Paul has any unstated motivations here. > > One aspect of saying that a data area is random is saying that the RFCs > can impose no restrictions on it. Allowing arbitrary unstructured > "random" data in the protocol opens the door for private extensions to > be added by various parties. I also don't think that Paul intends that. > For example, it appears that 4 of the 32 bytes originally specified for > random data got repurposed for GMT leaving "this is GMT but the clock is > not required to be right" in the spec. > > Once a few more of these accumulate in the protocol without central > coordination we end up with incompatibilities that the IETF process can > no longer prevent. Yes, but since we do need nonces in our protocol, I think this is a risk we have to live with. What you are arguing for, IIUC, is that nonces shouldn't be extremely large, but just right -- I agree with this. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
On 4/23/2010 12:12 PM, Nicolas Williams wrote: > > 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. Even though they are sent in-the-clear, the random data do serve the same useful purpose as the existing [cs]_random data. (Mathemeticians and professional cryptographers should probably avert their eyes from the fast-and-loose reasoning which follows.) Because they are unpredictable they make offline precomputation harder. I think of it as adding entropy into offline computation, without adding any to the online computation. I would think that the current 224-256 bits is enough to thwart offline attacks. The attacker would need something proportional to 2**224 storage to store the results of his precomputation, no? Assume attacker can knock off 2**42 using rainbow table techniques (he has a 1024 unit cluster of CPUs which can each compute one result online every clock at 4GHz). So he needs to store something like 2**182 results from his precomputation. Assuming 1 bit per result, probably you'd need more. Raw HDDs are the cheapest form of mass storage today at $75/TB (10**12 bytes?). Such a system would cost $ 57468582782470832188438013518137000.00 today. Of course those costs are likely to decline over time. Again, this is the cost you impose on the attacker today by simply ensuring you use the current protocol as intended. > 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. There is a danger with this proposal. In no way do I mean to suggest that Paul has any unstated motivations here. One aspect of saying that a data area is random is saying that the RFCs can impose no restrictions on it. Allowing arbitrary unstructured "random" data in the protocol opens the door for private extensions to be added by various parties. For example, it appears that 4 of the 32 bytes originally specified for random data got repurposed for GMT leaving "this is GMT but the clock is not required to be right" in the spec. Once a few more of these accumulate in the protocol without central coordination we end up with incompatibilities that the IETF process can no longer prevent. - Marsh ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
Paul Hoffman writes: > At 12:51 AM +0200 4/22/10, Simon Josefsson wrote: >>In which environments is the extension useful? >> >>The only motivation in the document that I can find is this: >> >> In some application environments, it is desirable to have the client >> and/or the server be able to input more random material in the master >> key calculation than is allowed by the fixed-length Random value. >> >>I believe more justification than that is required for Proposed >>Standard. >> >>In particular, what I'd like to see is references to some application >>environments where the extension is desirable, and the rationale why it >>is desirable in that environment. >> >>Without a rationale for when the extension is useful, it is impossible >>for implementers to know when use of this extension is warranted or not. > > The environment I described in the earlier thread is TLS with > Diffie-Hellman. I thought that saying that was sufficient, but I guess > it wasn't. People shouldn't have to read the mailing list to understand the applicability, so please describe some environments in the document. > In Diffie-Hellman key establishment with static keys, even if the PRNG > of one side is bad, the resulting pre-master secret is still sound. > Neither side knows whether or not the PRNG of the other side is bad, so > each side wants to supply sufficient randomness for the master secret > even if the other side's PRNG is bad. If a side with a bad PRNG adds its > own input, it doesn't hurt the randomness of the result, but a side with > a good PRNG can bring up the amount of randomness. Are you saying that the 28 bytes of randomness provided in the client and server hello is not sufficient? > I did not want to list this as the justification because there may be > other reasons to use the extension, and I don't want readers to think > that this is the only one. For example, future types of TLS key > establishment might have similar properties as static-static > Diffie-Hellman. > > Does that help? This information certainly helps, but it belongs in the document. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
Paul Hoffman 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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
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. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-tls-additional-random-ext (Additional Random Extension to TLS) to Proposed Standard
The introduction of this I-D is very, very thin, and, more importantly, there's no applicability information. I have asked before and gotten no additional information. I've also suggested one use for this that the author rejected on the grounds, IIRC, that this extension is not intended for that use, though without addressing why the extension couldn't be used for that use. How are others to know whether this extension can be used for any one particular purpose if there's no applicability statement? Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
On Thu, Apr 22, 2010 at 4:29 PM, Paul Hoffman wrote: >>In which environments is the extension useful? >> >>The only motivation in the document that I can find is this: >> >> In some application environments, it is desirable to have the client >> and/or the server be able to input more random material in the master >> key calculation than is allowed by the fixed-length Random value. >> >>I believe more justification than that is required for Proposed >>Standard. >> >>In particular, what I'd like to see is references to some application >>environments where the extension is desirable, and the rationale why it >>is desirable in that environment. >> >>Without a rationale for when the extension is useful, it is impossible >>for implementers to know when use of this extension is warranted or not. > > The environment I described in the earlier thread is TLS with > Diffie-Hellman. I thought that saying that was sufficient, but I guess > it wasn't. > In Diffie-Hellman key establishment with static keys, even if the PRNG > of one side is bad, the resulting pre-master secret is still sound. > Neither side knows whether or not the PRNG of the other side is bad, so > each side wants to supply sufficient randomness for the master secret > even if the other side's PRNG is bad. If a side with a bad PRNG adds its > own input, it doesn't hurt the randomness of the result, but a side with > a good PRNG can bring up the amount of randomness. > I did not want to list this as the justification because there may be > other reasons to use the extension, and I don't want readers to think > that this is the only one. For example, future types of TLS key > establishment might have similar properties as static-static > Diffie-Hellman. Maybe or maybe not. I'd prefer extensions to TLS that solve existing issues or augment with new functionality. If there really an issue with TLS with static DH keys that is solved by this draft I can understand specifying it, or better I'd prefer solving them within the protocol and without any extensions to it. But if there no practical issue I see no point. In the end who's really getting affected by this proposal? regards, Nikos ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [TLS] Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
At 12:51 AM +0200 4/22/10, Simon Josefsson wrote: >In which environments is the extension useful? > >The only motivation in the document that I can find is this: > > In some application environments, it is desirable to have the client > and/or the server be able to input more random material in the master > key calculation than is allowed by the fixed-length Random value. > >I believe more justification than that is required for Proposed >Standard. > >In particular, what I'd like to see is references to some application >environments where the extension is desirable, and the rationale why it >is desirable in that environment. > >Without a rationale for when the extension is useful, it is impossible >for implementers to know when use of this extension is warranted or not. The environment I described in the earlier thread is TLS with Diffie-Hellman. I thought that saying that was sufficient, but I guess it wasn't. In Diffie-Hellman key establishment with static keys, even if the PRNG of one side is bad, the resulting pre-master secret is still sound. Neither side knows whether or not the PRNG of the other side is bad, so each side wants to supply sufficient randomness for the master secret even if the other side's PRNG is bad. If a side with a bad PRNG adds its own input, it doesn't hurt the randomness of the result, but a side with a good PRNG can bring up the amount of randomness. I did not want to list this as the justification because there may be other reasons to use the extension, and I don't want readers to think that this is the only one. For example, future types of TLS key establishment might have similar properties as static-static Diffie-Hellman. Does that help? --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
Paul Hoffman writes: > At 12:05 AM +0200 4/22/10, Martin Rex wrote: >>The IESG wrote: >>> >>> The IESG has received a request from an individual submitter to consider >>> the following document: >>> >>> - 'Additional Random Extension to TLS ' >>> as a Proposed Standard >> >> >>I'm somewhat confused to see a Last Call for this proposal. >> >>We had a discussion on this document on the TLS WG mailing list and >>determined that this proposal is completely unable to achieve >>the stated goal. This extension is completely bogus. > > You came to that conclusion; many other folks disagreed. You stated > that you thought it was not useful in some environments, namely with > RSA authentication where the client has a broken PRNG. If that is the > only environment you care about, then this extension is not > useful. TLS is used in many other environments, of course. In which environments is the extension useful? The only motivation in the document that I can find is this: In some application environments, it is desirable to have the client and/or the server be able to input more random material in the master key calculation than is allowed by the fixed-length Random value. I believe more justification than that is required for Proposed Standard. In particular, what I'd like to see is references to some application environments where the extension is desirable, and the rationale why it is desirable in that environment. Without a rationale for when the extension is useful, it is impossible for implementers to know when use of this extension is warranted or not. /Simon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
At 12:05 AM +0200 4/22/10, Martin Rex wrote: >The IESG wrote: >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> >> - 'Additional Random Extension to TLS ' >> as a Proposed Standard > > >I'm somewhat confused to see a Last Call for this proposal. > >We had a discussion on this document on the TLS WG mailing list and >determined that this proposal is completely unable to achieve >the stated goal. This extension is completely bogus. You came to that conclusion; many other folks disagreed. You stated that you thought it was not useful in some environments, namely with RSA authentication where the client has a broken PRNG. If that is the only environment you care about, then this extension is not useful. TLS is used in many other environments, of course. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hoffman-tls-additional-random-ext (Additional Random
The IESG wrote: > > The IESG has received a request from an individual submitter to consider > the following document: > > - 'Additional Random Extension to TLS ' > as a Proposed Standard I'm somewhat confused to see a Last Call for this proposal. We had a discussion on this document on the TLS WG mailing list and determined that this proposal is completely unable to achieve the stated goal. This extension is completely bogus. The accompanying document draft-hoffman-tls-master-secret-input-01.txt may have some useful purpose for some unspoken environments, but draft-hoffman-tls-additional-random-ext-01.txt is definitely NOT among those. -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
