Hello On 12/17/20 2:19 AM, Christian Huitema wrote: >> >> What am I missing? > > In short, you are missing the tons of discussions that went into that > specification, and so will every other reader of the 180+ page QUIC specification. The document should stand on its own and be sufficiently clear on how to implement the protocol without shooting oneself in the foot. You call that "overspecification" ? Implementers should not be privvy to the tons of discussions that went into the process to write the final document. I will refrain from commenting on the different confusing paragraphs about connection IDs in the QUIC document because we are not reviewing that document here. I guess there is a separate thread for that somewhere. > taking into account the needs of a variety of > environments including for example server farms. You are also picking > out the Initial Connection ID out of context -- for protocol reasons, it > is not generated in the same way as other connection IDs.> > Again, you are providing a great example of why the IETF should not > publish this draft. > It is using an abstract generalization of > "identifiers" to draw broad recommendations that are at odds with actual > protocol development practice. You are reiterating the same arguments. First by insinuating that an "abstract generalization" is a bad thing, it is not. We generalize from empirical data, we abstract into a classification issues that have reocurred over 30+ years in different protocols and provide guidance to help current and future authors not incur in the same issues. Second, by singling out the QUIC document and generalizing from it as if that was how every other protocol is currently developed. I don't see any evidence to support such implicit claim. We can continue talking past each other for weeks. One saying that arbitrary generalizations are bad and pointing at QUIC as a example of how things are done right now, the other arguing that abstracting and generalizing from known similar problems not only is not bad but it is actually useful and repeating that generalizing from a single data point (QUIC) is a bad form of "abstract generalization". We will continue to talk past each other and get nowhere because evidently the intent of that line of debate is not to improve our draft to make it more effective but to prevent its publication. Everyone is entitled to an opinion and yours is that the draft should not be published but the arguments provided to support that opinion are simply not sound. There is no need to reiterate them, they are clear. > Endorsing these recommendation in a BCP > or even an informational RFC will be harmful, because it will cause > unnecessary discussions, just like the one we are having here. It will not cause any unnecessary discussion if protocol designers look at the transient IDs they are putting in their protocol, reflect on their impact on security & privacy and refine their design accordingly. If there is a discussion about why a given ID should or should not follow our guidance it would not be an unnecessary discussion. > > When I saw the first iterations of this work, my feeling was that > documenting a class of design failures was great, but trying to go from > there to design mandates was going too far. A couple years later, my > opinion has not change. An informational document documenting a series > of past attacks would be interesting and educational. The kind of rule > making proposed in the draft, on the other hand, would be mostly harmful. I am of the opinion that the most harmful would be to document a number of reocurring design failures of the past and then do nothing to prevent repeating those failures in the future. /ivan -- Iván Arce CTO - Security Analysis Quarkslab -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
