Hiya, Thanks for writing this, I would support it being progressed if we conclude that it's feasible and not easily defeated.
My main concern is that a server playing a
draft-green-like game could just choose DH
values more cleverly and avoid detection.
E.g. if the DH values are derived via some
function so that public shares never recur,
or only rarely. (And while such derived DH
values would in a sense represent the server
borking its own crypto, that's basically what
draft-green suggested anyway, so one might
expect a DH borking adversary in such cases
to not care so much about the client's
security.)
I guess that testing would also be an issue
so it'd be great if someone was to try do
that to check if this might break things.
(Which'd be useful in any case if it found
some servers accidentally re-using.)
Other than that, some more minor comments:
It'd be good to describe in detail a way in
which one might efficiently retain the client
state required, e.g. via a bloom filter maybe?
(Assuming an occasional false positive isn't
too alarming;-)
It might also be good to outline how a survey
or CT-like mechanism (say logging some value
as a witness for the DH public) could be used
to detect this kind of badness even if common
TLS clients didn't deploy.
I think in 3.2 you need to be a bit more
precise about which DH values you mean, e.g.
if doing ESNI then clients will see the same
DH value from ESNIKeys a number of times. (So
I suspect you couldn't implement this at a
very low level in the crypto engine.)
"MUST avoid accidental" is an interesting
phrase:-)
Section 4 could probably do with some text
about how not to do this, e.g. keeping a list
of {servername,[DH values]} would be bad if
a client's disk were compromised.
Cheers,
S.
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
