Only thing it wonder is why would you 'test' for the bug with only 1 byte of memory leaked? False negatives would be a lot smaller if you reversed it and send a 1-byte session id and have 31 bytes to test.
He says "By picking 31 bytes I ensured the sensitive information leakage would be negligible." but if you don't save/inspect other than verifying it's not 31x0, I don't see the problem?
As I understand it from RFC 5077, when a client sends a session id + session ticket, a conforming server will only ever send back exactly the session id the client sent, or no session id. If the client sends a 31 byte session id, and gets back a 32 byte session id, it knows the server must be sending back some extra data (which may or may not contain any information).
If the first 31 bytes are not the same, then the server is likely generating a new session id, which is a bug but probably not leaking any information.
If the first 31 bytes are the same, then either the server is padding the session id with zeros (which, while buggy, would not be an information leak) or the server is sending back some uncleared memory. These cases could be checked by seeing if the padding is zero (which would have at least a 0.4% false negative rate with just the one byte) but the zgrab test in the article doesn't bother distinguishing them and just assumes any extra data may be an information leak.
EDIT: Re-reading RFC 5077 again, I'm not certain that the server is prohibited from sending back a new session id. If it is allowed to then the second paragraph above doesn't indicate a bug, just a rejection of the session ticket.
The session ID isn't encrypted and that means that a passive observer can intercept the test traffic and gain information. Filippo decided to protect against that possibility.
He says "By picking 31 bytes I ensured the sensitive information leakage would be negligible." but if you don't save/inspect other than verifying it's not 31x0, I don't see the problem?