Re: [TLS] Consensus for AEAD IV

[Brian Smith <[e-mail]>]

Michael StJohns <[e-mail]> wrote:

> So what you're suggesting is requiring each cipher mode that uses TLS have
> both the generic - pass in the IV etc - and the TLS specific - pass in a
> handle to material that has to be retained within the HSM and managed in
> some way to make sure that you delete when your done?
>

No, it isn't TLS-specific. As others noted, SSH can use it too. And, future
protocols can use it as well. Regardless of the particulars if the TLS
discussion, the pass-in-the-IV approach is terrible because the module
cannot guarantee the uniqueness of the IVs. So, actually, everybody should
be using the
pass-in-the-handle-to-material-that-can-be-*PROPERLY*-maintained-by-the-module
approach. The FIPS 140 implementation guidance agrees, as far as I
understand it.


> You're actually going to make it impossible to use TLS1.3 with generic
> hardware modules.
>

No, one can still create a generic module that doesn't know anything about
TLS, that can provide this type of interface. And, one should do so.


> There is no reason to treat the 96 bit quantity as secret and no one else
> does.
>

Others already refuted the "no one else does." As for there being "no
reason to treat the 96 bit quantity as secret," there's also no reason to
make it public. The working group already decided when there is no
compelling reason to make a handshake value public, then it should be made
private. (The charter says "Develop a mode that encrypts as much of the
handshake as is possible to reduce the amount of observable data to both
passive and active attackers.")

Further, I believe you actually mean "there is no *known* reason" to treat
the IV as secret. That doesn't mean there aren't *unknown* reasons for
doing so.


> TLS should use generic interfaces rather than inventing stuff that can't.
>

Again, this can use a generic interface. It can't use the generic
interfaces that are currently exposed by certain crypto modules, but that's
a problem with those crypto modules' interfaces, not with what is being
proposed here.

Cheers,
Brian