On Sat, Oct 10, 2020 at 09:13:51AM +0200, Achim Kraus wrote: > Hi Ben, > > > > > To be frank, I'm actually surprised that this is even seen as a matter for > > discussion. > > As developer, I'm surprised, that this discussion now spans a couple of > years, starting on summer 2018 with: > > https://github.com/tlswg/dtls-conn-id/issues/8
Well, we are not always happy about it (in fact, usually are unhappy), but writing protocol specifications does have a reputation for taking a long time due to repeated experiences. It's also the case that the spec isn't done until it's done, and that breaking changes to the spec are possible at any time before it's done. > There are many (proposed) changes since then. I already tried to point > to that with my e-mail answer from 4. September > > >> That order was also discussed a lot. > >> https://github.com/tlswg/dtls-conn-id/pull/29 > >> I would prefer, if this is not changed again without strong arguments! > > For me, "cryptographic hygiene", which breaks the API, are not strong > arguments. Sure, that's only my personal opinion. I'm not sure, if a new > code-point helps, nor that a new one is emitted for changing a draft (I > would not recommend to do so, draft is a draft). A codepoint should have a specific well-defined behavior. The current allocation of extension type 53 is explicitly marked as TEMPORARY and can+will age out if we get a new one for the new semantics; this is normal. > So let me try to find a end: > As developer, I see it's very important to come to a stable definition > of the MAC. If now the order of the cid/cid-length is changing the MAC > (again), and in half a year the next "cryptographic hygiene" campaign > removes the cid-length (because it's not on the header and some > (including me) don't see the benefit), then FMPOV this "process" just > demonstrates more weakness, than I appreciate. > > So: > If there is a guideline for constructing MACs, is that guideline > documented somewhere? > If the guideline is changing over the time, are these changes documented? Sure, there's pretty standard common-knowledge guidance, though I'm not sure it's documented anyplace particularly discoverable: - include in the MAC as much application/protocol context and protocol fields as you can without breaking operation of the procotol - ensure that the mapping from (set of protocol fields and values derived from application context) to (bytes given as input to the MAC function) is an injective mapping In some (many?) cases, there is not any additional contextual information available, and the protocol header itself has a deterministic/fixed-length encoding, so both points can be achieved by just using the protocol header/payload as it appears on the wire as MAC input. For better or for worse, the current construction in the -07 diverges significantly from the actual protocol header, so we have to do a bit of thinking to ensure that we are compliant to the guidelines (that I just described, so I assume you did not previously think about them in that formulation). For what it's worth, I am in a similar position as you in that I don't see a specific reason that including the CID length explicitly is *required*, since the CID itself would need to be using a self-delineating encoding in order for the packet to be parseable (if variable-length CIDs are used at all; a fixed-length CID is trivially delineated). I would be pretty okay with not having the separate length field if our MAC inputs more closely followed the record header (and, to be honest, I could accept not having it at all even with the current order of (other) fields in the MAC input, in the absence of specific reasoning why it's needed), though I prefer to keep an explicit length if we stay with something resembling the current formulation (that diverging from the record header as it appears on the wire), just to make it easier to reason about. I still, however, object to the construction in the -07 that puts the CID length after the CID -- there is no point in having the CID length if you need a self-delineating CID anyway [1], and its current location gives an aveue of malleability to an attacker. Leaving this kind of local malleability of MAC input in place seems irresponsible and is not in keeping with the quality expectations for the output of the TLS working group. (We should also check to make sure that we properly document the requirements on CID generation and parsing schemes, as you noted elsewhere.) > And I would really welcome, also based on the experience with the long > history of this discussion, if more can give their feedback about > changing the MAC again. Please, this year, not next :-). I believe that Joe's response supports my "don't leave areas of local malleability in place" stance. I guess maybe the discussion is migrating to the github issue, though, so I will try to watch there as well. Thanks, Ben [1] "need [...] anyway" here is perhaps most usefully thought of in the sense of inverting the (injective) map from (protocol parameters and context) to (input to the MAC function), since this needs to be possible for any valid MAC input in order for the injective property to hold. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
