On 07/07/17 22:38, Russ Housley wrote: > Stephen: > >>>> You didn't refer to 2804 and the standards track. As an author >>>> do you really think this can be on the standards track and yet >>>> not obsolete 2804? >>> >>> Yes. >> >> We disagree. >> >>> Section 3 of RFC 2804 offers pretty clear definition of >>> wiretapping, and that is not what is going on here. In this >>> situation, all of the parties are part of the same organization, >>> under common key management. >> >> That is one possible deployment. There is nothing in this proposal >> that limits it's use to that. >> >>> The server must explicitly accept and use the centrally managed >>> (EC)DH key, so that party is completely aware and, in fact, >>> enabling the other parties to decrypt the traffic. >> >> Yes, and the server could equally be compelled to do that, in which >> case this technology would clearly be a standard form of >> wiretapping. >> >> Claiming that is not the case would be incredible so I have no idea >> how you maintain that this isn't in conflict with 2804. > > That does not follow the definition in Section 3 of RFC 2804.
And also: I'm sorry to have to say it, but I consider that attempted weasel wording around the clear intent of 2804. The clear and real effect if your wiretapping proposal were standardised by the IETF would be that we'd be standardising ways in which TLS servers can be compelled into breaking TLS - it'd be a standard wiretapping API that'd be insisted upon in many places and would mean significantly degrading TLS (only *the* most important security protocol we maintain) and the community's perception of the IETF. It's all a shockingly bad idea. S PS: You might say that purely static DH can be detected by the TLS client, but once we give in on this it'll be inevitable that variants are derived that aren't detectable by the TLS client. > If one > of the parties is "compelled" to install the centrally managed (EC)DH > key, then the server is aware. If you consider the server to be the > sending party, then this situation does not meet number 1 in the > definition. If you consider the server to be the receiving party, > then this situation does not meet number 2 in the definition. > > To save everyone from looking it up, RFC 2804 says: > > Wiretapping is what occurs when information passed across the > Internet from one party to one or more other parties is delivered to > a third party: > > 1. Without the sending party knowing about the third party > > 2. Without any of the recipient parties knowing about the delivery > to the third party > > 3. When the normal expectation of the sender is that the transmitted > information will only be seen by the recipient parties or parties > obliged to keep the information in confidence > > 4. When the third party acts deliberately to target the transmission > of the first party, either because he is of interest, or because the > second party's reception is of interest. > > The term "party", as used here, can refer to one person, a group of > persons, or equipment acting on behalf of persons; the term "party" > is used for brevity. > > Of course, many wiretaps will be bidirectional, monitoring traffic > sent by two or more parties to each other. > > Thus, for instance, monitoring public newsgroups is not wiretapping > (condition 3 violated), random monitoring of a large population is > not wiretapping (condition 4 violated), a recipient passing on > private email is not wiretapping (condition 2 violated). > > Russ >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
