Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

["Valery Smyslov" <[e-mail]>]

After re-reading the draft I think that I'm also a bit unhappy with the way 
the last table
(Section 4.2) is introduced. The draft says that this table is:

   Recommendation of Authentication Method described in [RFC7427]
   notation.

However, the values from this table are just examples in RFC7427.
Why exactly these algorithms were selected for recommendation?
What about others (EdDSA, GOST etc)? I understand that
the algorithms listed were probably most popular (at least some of them)
at the time RFC 7427 ws written. But why continue to maintain
this list, when it is just a list of examples in RFC7427?

Well, I understand that some recommendations should be given.
But probably only those signing algorithms that have non-MAY
status should be listed and a note should be added that
all others are MAY (that will refer to any unlisted signature
algorithm)?

What others think?

Regards,
Valery.



-----Original Message----- 
From: Tero Kivinen
Sent: Wednesday, April 6, 2016 7:17 PM
To: Valery Smyslov
Cc: [e-mail]
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-06.txt

Valery Smyslov writes:
> my comments mostly are addressed, thanks.
> The one still unaddressed is a strange comment "?SHOULD" in the last table
> (Section 4.2). What does it mean?

I think that is leftover from our internal discussions, i.e. whether
we should mark that ecdsa-with-sha512 as SHOULD instead of MAY.

I think MAY is fine, so unless people think we should pick that too
with SHOULD, I will remove that in next version. I do not think we
need to do it now, we can do the WGLC with the draft we have now, and
remove it after that.

Other thing I want people to think is whether we should say something
else about the AES key sizes, i.e. we now say MUST for 128-bit, MAY
for 256-bit and "192-bit keys can safely be ignored." One proposal
that was done was to change that MUST for 128-bit, SHOULD for 256-bit,
and perhaps even SHOULD NOT for 192-bit.
-- 
[e-mail]