Hi Elwyn- Inline and trimmed a bit.
... >> > Specifics: >> > On-the-wire format: ... >> >> EO# >> Your comments are around the on-wire format for PSC TLVs. It seems >> weird to specify the encoding *only* for TLVs and not for the rest of >> PSC ..... > The other parts of the PSC don't involve integers and so aren't > affected. > > The usual solution is to add a single statement to the effect that all > integer fields are encoded as unsigned integers in network bit order. > > Assuming things is always dangerous in standards. All true. OK, I'll add a such a statement. ... >> > Malformed messages check: >> > - Check values of fields prior to TLV Length are consistent with s4.2 of >> > RFC 6378. >> > - Check overall length of message matches value in TLV Length + 12. >> > - Check Sum of lengths of TLVs matches value in TLV Length. >> > - Check all TLV types received are recognized. >> > ... >> >> Is this level of detail really necessary? > > Doubtless that is a matter of opinion, but in my experience of code > inspection and functional specifications/standards, providing a > checklist while we are thinking about it can help to avoid the sort of > security doom that OpenSSL is coping with at the moment. > EO# OK. I'll add these cases and make clear that they are not the only ones. I don't want to make it too heavy as I'm wary of crossing that line between protocol spec and implementation spec. I will put something together today or tomorrow and get it out to this list for review. thanks! eric _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
