RE: [IPsec] Re: Last call comments for draft-lepinski-dh-groups-01

[Tero Kivinen <[e-mail]>]

Scott Fluhrer writes:
> > With regards to our IKE implementation, we default to RFC 
> > 4753 for groups 19/20/21 as initiator and use the other 
> > format for the other curves.
> > 
> > Perhaps it should explicitly state this fact ("MUST"?) in 
> > ecc-groups-10-WGLC-0.
> 
> That, at least to me, would seems to be reasonable.

As we do have one specified way how to format for the KE and shared
secrets defined as RFC (RFC4753), I see no point of using any other
format now. I think the draft-ietf-ipsec-ike-ecc-groups-10.txt should
be fixed to use the same format too, and not to define new formats.

If we want to add support for point compression, I see that only way
to do that is to add duplicate numbers for those elliptic curves one
with point compression and another without. We cannot really negotiate
the support for point compression as KE payload is already used in the
first packet we send from initiator to the responder. With separate
group numbers we could get interoperability by using
INVALID_KE_PAYLOAD notification with one extra round trip.

On the other hand if I have understood correctly the benefit from
point compression is saving less than 64 bytes from the final payload.
The first packet is 28 bytes of header + 44 bytes of SA payload (one
exact alogorithm set) + 8 (KE payload header len) + KE payload len +
36 (32 byte nonce payload) + 2 * 28 (2 * NAT detection payloads) = 172
bytes + KE data length. I.e using 512 bit elliptic curve that makes
the first packet 300 bytes without point compressioon and 236 bytes
with point compression. Both will still keep the packet length way
below the threshold that would start causing fragmentation and so on.
Bandwidth saving concerns for packets which are sent once for every 8
hours or so is not really meaningful.

> > As I noted in a previous e-mail, (non)-interoperability 
> > extends to the shared secret. In the other standards, as well 
> > as the current draft-lepinski-dh-groups-01, the shared secret 
> > is the x-coordinate. This is not the case with RFC 4753 which 
> > includes both x and y. Compare the shared-secret of the 
> > 256-bit curve in draft-lepinski-dh-groups-01 page
> > 21 and rfc 4753 page 9.
> > 
> > draft-lepinski-dh-groups-01 should also describe the format 
> > of the shared secret.

The current text in draft-lepinski-dh-groups-01.txt says you use
formatting specified in the RFC2409. It does not really say anything
about IKEv2. RFC4306 does not specify how to use it with elliptic
curves. RFC2409 says we only send and use x (no mention of padding,
and only has EC2N groups). RFC4753 says we use both x and y (padded
and concatenated, and only has ECP groups).

Draft-lepinski-dh-groups-01.txt should be updated to refer to RFC4753
for IKEv2 case and use that formatting specified there.

The test vectors should be provided in format where both x and y of
the secret is given (even if some protocols referenced there do use
only x of it). There is no need to have exact payload encodings as is
done in RFC4753 as this draft defines groups for other use than IKEv2
too, but it would be useful to have both girx and giry and perhaps
g^ir too (using RFC4753 terminology to refer those values here).
-- 
[e-mail]


_______________________________________________
IPsec mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipsec