The current design for binding between TLS handshake and RA session is built on a binder value generated using the TLS early exporter. The assumption, when the design was written up, was that this exporter covers the rolling hash of the handshake as it progresses, until the point where the (non-early) exporter becomes available.
Unfortunately, it seems the early exporter was specifically meant for 0-RTT and exclusively covers the ClientHello. This is insufficient for our needs, as it does not reflect the unique handshake from which it is extracted. We therefore need to propose a new design.
A solution could be to extend the key schedule to produce this binder from the master secret directly. This shouldn't be an issue given that the internals of the TLS library need to be updated for aTLS anyway.
The current design for binding between TLS handshake and RA session is built on a binder value generated using the TLS early exporter. The assumption, when the design was written up, was that this exporter covers the rolling hash of the handshake as it progresses, until the point where the (non-early) exporter becomes available.
Unfortunately, it seems the early exporter was specifically meant for 0-RTT and exclusively covers the ClientHello. This is insufficient for our needs, as it does not reflect the unique handshake from which it is extracted. We therefore need to propose a new design.
A solution could be to extend the key schedule to produce this binder from the master secret directly. This shouldn't be an issue given that the internals of the TLS library need to be updated for aTLS anyway.