Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

[Aaron Zauner <[e-mail]>]

Hi,

In the TLS case, RFC5288 defines the following IV construction (Section 3):

```
             struct {
                opaque salt[4];
                opaque nonce_explicit[8];
             } GCMNonce;


   The salt is the "implicit" part of the nonce and is not sent in the
   packet.  Instead, the salt is generated as part of the handshake
   process: it is either the client_write_IV (when the client is
   sending) or the server_write_IV (when the server is sending).  The
   salt length (SecurityParameters.fixed_iv_length) is 4 octets.
```

As you can see the salt is is implicitly derived from the *_write_IV. We have no influence on this part of the IV construction, whereas the `nonce_explicit` is generated by the implementer. I don't see a way how we could XOR some records and compromise confidentiality, we've checked, believe me. If somebody can come up with an attack though, that'd be nice.

On the catastrophic part: I'd like to keep it around. I don't think it deserves a name like a hurricane, but catastrophic is pretty spot on in this regard.

w.r.t. nonce/n-nonce: either we keep the parentheses with "number used once" around or we change it to n-once as suggested by Tony and beautifully pronounced by Adam Langley :)

Aaron