Re: [Curdle] draft-ietf-curdle-ssh-modp-dh-sha2 & draft-ietf-curdle-ssh-kex-sha2

[Tero Kivinen <[e-mail]>]

Mark D. Baushke writes:
> > Also, is there need to update other algorithms, i.e. encryption
> > algorithms, MAC algorithms, Public key names, comperssion algorithms
> > etc? Are the implementation requirements for them up to date (I do not
> > know, as I have no idea which of them are now mandatory to implement,
> > and which are not).
> 
> Good question. I am not sure if they are all being managed by the Curdle
> Group or not....

Curdle charter says:

CURDLE - CURves, Deprecating and a Little more Encryption

The CURDLE working group is chartered to add a small set of
cryptographic mechanisms to some IETF protocols, and to make
implementation requirements including deprecation of old algorithms
where there is IETF consensus to do so. ...
...
The protocols the WG intends to work on are Secure Shell (SSH), ...
...
The CURDLE working group will be handling changes to protocols and
registries some of which include what are now considered outdated
algorithm options, and may propose deprecation of such algorithms. ... 
...

so it seems to fit well to curdle charter, if we deprecate and collect
mandatory to implement ciphers to one document. 

> I am not sure that they all belong in one document or not. It seems
> like it might be better for each section to have its own document
> specifying the MUST/SHOULD/MAY/SHOULD NOT advise...

In IPsecME we did collect all IKEv2 related requirements to one
document, and all ESP/AH related requirements to another document. The
reason we have two documents is, because the requirements are
different. In IKEv2 it is ok to specify ENCR_AES_CBC as MUST, as it is
low speed link and performance is not primary goal. In ESP we also
make ENCR_AES_GCM_16 as MUST as it is needed for high performance
gateways.

I would suggest we collect all "Algorithm Implementation Requirements
and Usage Guidance for ssh" in one document here too.

In draft-ietf-ipsecme-rfc4307bis-12 for IKEv2 we even specified the
mandatory to implement authentication methods, and recommended key
lengths (see section 4.1.1). We also provide little bit of background
reasoning for the MUST/SHOULD/MUST NOT/SHOULD NOT algorithms.
-- 
[e-mail]