On 06/30/2017 11:32 AM, Benjamin Kaduk wrote: > On 06/29/2017 03:53 PM, Eric Rescorla wrote: >> I have updated the PR to match people's comments. I would like to >> merge this soon, so please get any final comments in. > > I made a couple comments on the PR that are more appropriate for the > list, so I'll repeat them here and hopefully get replies from the > broader audience. > > > First off, I think we should MUST-level require servers to implement a > hard limit on the number of replays accepted. However, it doesn't > quite seem realistic to require "MUST use either [single-use tickets] > or [ClientHello recording]". My preference would be "MUST use either > [single-use tickets], [ClientHello recording], or equivalently strong > protection", but I don't know what level of support we have for such a > strong requirement. As an alternative, I will also put out "MUST > limit replays to at most the number of endpoints capable of accepting > connections for a given identity, and SHOULD provide even stronger > replay protections, such as [single-use tickets] or [ClientHello > recording]." I think we have general agreement that strong > anti-replay as described in the document is feasible for a > single-server deployment, and this last formulation is achievable in > multi-server environments by just giving each server its own local > per-server protection. (My main reason for wanting a MUST-level hard > cap is that I worry that millions/billions of replays will have really > nasty consequences in terms of DoS and side channel issues.) > > But, this has been quite a long thread spread out over multiple > forums/email subjects, so I've also probably forgotten some of the > arguments presented against having MUST-level strong anti-replay > requirements; I'd greatly appreciate if someone could repeat them here > for everyone's consideration.
Or are there no such arguments? The only one I remember is the implementation complexity for distributed systems, but if you can implement for a single-node system my compromise proposal is trivially implementable. -Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
