Re: [Cfrg] Point validation in TLS 1.3

["Paterson, Kenny" <[e-mail]>]

Hi Dan,

Thanks for sharing your views.

I'd appreciate hearing from interested CFRG participants on whether
implementing this "MAY" would bring meaningful additional security benefit
for implementations or not.

Regards,

Kenny 


On 30/11/2016 18:19, "Dan Brown" <[e-mail]> wrote:

>Hi Eric and Kenny,
>
>Please consider adding a MAY for the redundant ("belts and suspenders")
>combination of point validation and Montgomery ladder (X25519).
> 
>Significant costs of this redundant combination are its being
>approximately 10% slower in each DH computation and its extra code.
>
>A small benefit of this redundant combination is its being potentially
>minutely securer (see * below).
>
>A user or an implementer should only want this combination when the extra
>cost is somehow negligible (for example, in comparison to other large
>costs) because the benefits are likely close to negligible.
>
>The user and implementer should be well-informed to make a useful
>decision.  The work of preparing a clear guidance in the RFC on cost
>(significant) and benefits (insignificant) might outweigh the benefit of
>having a MAY in the RFC.
>
>Best regards,
>
>	Dan
>
>(*) Here's how I think (for now) that directly rejecting twist-points on
>top of X25519 might minutely improve security:
>
>- a denial of service attack consisting of just sending random strings as
>points is better resisted,
>- a user of the implementation can be more confident that something fishy
>doesn't happen if twisted points are received (the user can delay
>inspecting the internal of the implementation and just examine its
>behavior),
>- validation is to be done on the public inputs received, before any
>secrets are used, which is generally safer (more robust against
>implementation bugs).
>
>Again, the gain in all cases is small (at best) because each threat
>thwarted can be tweaked easily to work around to the countermeasure.
>
>-----Original Message-----
>From: Cfrg [mailto:[e-mail]] On Behalf Of Paterson, Kenny
>Sent: Wednesday, November 30, 2016 6:27 AM
>To: Eric Rescorla <[e-mail]>; cfrg <[e-mail]>
>Subject: Re: [Cfrg] Point validation in TLS 1.3
>
>Hi Eric,
>
>Thanks for giving CFRG the chance to comment on this.
>
>From a technical perspective, this looks like an accurate translation of
>existing best practice to me.
>
>Any other comments from the group?
>
>Cheers
>
>Kenny 
>
>On 29/11/2016 22:52, "Cfrg on behalf of Eric Rescorla"
><[e-mail] on behalf of [e-mail]> wrote:
>
>>Hi CFRG folks,
>>
>>
>>Matt Green has submitted a pull request to require validation for ECDHE
>>(TLS 1.3 already requires it for FFDHE). We wanted to make sure the
>>CFRG was
>>
>>aware of this and see if there were objections.
>>
>>
>>PR is here:
>>https://github.com/tlswg/tls13-spec/pull/763
>>
>>
>>
>>Text:
>>For the curves secp256r1, secp384r1 and secp521r1, the appropriate
>>validation procedures are defined in Section 4.3.7 of {{X962}} and
>>alternatively in Section 5.6.2.6 of {{KEYAGREEMENT}}.  This process
>>consists of three steps: (1) verify that Y is not the point at infinity
>>(O), (2) verify that for Y = (x, y) both integers are in the correct
>>interval, (3) ensure that (x, y) is a correct solution to the elliptic
>>curve equation.  For these curves, implementers do not need to verify
>>membership in the correct subgroup.
>>
>>
>>For x25519 and x448, the contents of the public value are the byte
>>string inputs and outputs of the corresponding functions defined in
>>{{RFC7748}}, 32 bytes for x25519 and 56 bytes for x448. Peers SHOULD
>>use the approach specified in {{RFC7748}} to calculate the
>>Diffie-Hellman shared secret, and MUST check whether the computed
>>Diffie-Hellman shared secret is the all-zero value and abort if so, as
>>described in Section 6 of {{RFC7748}}. If implementers use an
>>alternative implementation of these elliptic curves, they should
>>perform the additional checks specified in Section 7 of {{RFC7748}}.
>>
>>
>>
>>Thanks in advance for your input,
>>-Ekr
>>
>>
>>
>>
>>
>>
>>
>>
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/cfrg