Forbid TLS-level KeyUpdate in draft-ietf-quic-tls

[davidben]

Since QUIC uses its own mechanism, the spec should say the TLS-level KeyUpdate MUST NOT be sent and MUST be treated as a fatal error on receive.

Otherwise an implementation may forget about this and, when TLS sees a KeyUpdate, call some callback in some weird unexpected way and confuse things.

[mikkelfj]

There must be some form of key update otherwise GCM is not safe on long running connections.

[MikeBishop]

There is. TLS, section 6.

[davidben]

Right. Thus "[s]ince QUIC uses its own mechanism". :-)

Either way, the KeyUpdate message should be discussed in that text somewhere. If QUIC replaces it with its own mechanism, the spec text should forbid it. If QUIC makes TLS-level KeyUpdate somehow meaningful, it's got to actually specify what it does. QUIC handles record encryption and isn't ordered like TCP. The existing TLS KeyUpdate behavior doesn't apply.