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. I clearly disagree. Otherwise, I would not have put any work into the draft. Russ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
