On Wed, Nov 23, 2016 at 7:31 PM, Martin Thomson <[email protected]> wrote:
> OK, let's be clear: I don't agree that the level of paranoia > surrounding 0-RTT is warranted. Do you disagree that the three specific example security issues provided are realistic, representative and impactful? If so, what would persuade you to change your mind? > I'm of the belief that end-to-end > replay is a property we should be building in to protocols, not just > something a transport layer does for you. On the web, that's what > happens, and it contributes greatly to overall reliability. > The proposal here I think promotes that view; if anything, it nudges protocols/applications to actually support end-to-end replay. > The reaction to perceived problems in 0-RTT is disproportionate. You are asking for a license to replay here at some arbitrary layer of the > stack. That's not principled, it's just on the basis that you don't > like 0-RTT and want to innoculate other people's software against the > ill effects it might create. The problems of 0-RTT are disproportionately under-estimated. I've provided what I think are three concrete and realistic security issues. If we disagree on those, let's draw that out, because my motivation is to mitigate those new issues that are introduced by TLS1.3. > What I object to here is the externalizing that this represents. Now if I > have the audacity to > deploy 0-RTT, I have to tolerate some amount of extra trash traffic > from legitimate clients? > I think there is a far worse externalization if we don't do this. Consider the operations who choose not (or don't know) to add good replay protection. They will iterate more quickly and more cheaply than the diligent providers who are cautious to add the effective measures, which are expensive and difficult to get right. That is a perverse incentive, and ultimately users would pay the price. I have the same gut reaction against sending duplicate data and having a sort of "tax on everyone" for the sake of safety as you, it's icky, but I haven't been able to think of another mitigation for the problems that would be as effective. -- Colm
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
