> On Mar 14, 2018, at 4:48 AM, Martin Thomson <martin.thom...@gmail.com> wrote:
>
> On Tue, Mar 13, 2018 at 9:49 PM, Russ Housley <hous...@vigilsec.com> wrote:
>> Nick Sullivan summarized
>> four concerns with that approach. See
>> https://mailarchive.ietf.org/arch/msg/tls/NJEsyOZ8S3m8fiGk3bJ_lDnL-dg
>>
>> draft-rhrd-... addresses all four of these concerns.
>
> This isn't quite right. One of the goals Nick outlined was
> "Decryption service only gets session keys, not master secret". The
> current design causes them to gain the handshake secrets, from which
> it is trivial to derive the master secret and other secrets [1]. This
> includes the resumption master secret and exporter secret.
>
> So aside from enabling MitM, this also enables session resumption by
> the decryption service, something that the security considerations
> neglects to include in its list. What, if anything, can be done with
> the exporter secret will need more thought.
>
> [1] draft-rescorla-tls13-semistatic-dh-00 and its OPTLS-based
> insertion of another DH exchange would prevent the decryption service
> from working for anything other than the handshake and 0-RTT.
You are right. It would be a significant improvement to narrow the portions of
the key schedule that are shared.
To avoid the issue with resumption that you raise, is seems that these entries
in the key schedule are needed:
client_early_traffic_secret
client_handshake_traffic_secret
server_handshake_traffic_secret
client_application_traffic_secret_0
server_application_traffic_secret_0
Russ
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
