The current draft [1] says:

    Other than this recommended check, implementations do
    not need to ensure that the public keys they receive
    are legitimate: this is not necessary for security
    with Curve25519.

However, Thai Duong (of BEAST fame, among other things) wrote that TLS 1.2
and below do seem to benefit from public key validation in "Why not
validate Curve25519 public keys could be harmful" [2]. Watson Ladd had also
pointed out many times on this list that TLS is one protocol where
contributory behavior is required.

DJB himself had also pointed out did point out that some protocols do
require public key validation with Curve25519 "to ensure 'contributory'
behavior" in [3]. Thus, the statement in draft-ietf-tls-curve25519-01 that
"this is not necessary for security with Curve25519" in the current draft
is clearly overly general and misleading.

In particular, I noticed that the text in draft-ietf-tls-curve25519-01
section 2.3 focuses a lot on attacks that reveal the private key. However,
what about other attacks? In particular, I think that, at the very least,
the relevance or irrelevance to TLS of the key dictation attack that Thai
brought up, and the need or non-need for checking that the agreed value is
zero (basically the same thing), should be mentioned in the draft's
security considerations.

[1] https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3
[2]
http://vnhacker.blogspot.com/2015/09/why-not-validating-curve25519-public.html
[3] http://cr.yp.to/ecdh.html#validate

Cheers,
Brian
-- 
https://briansmith.org/
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to