On Mon, Dec 7, 2015 at 6:30 AM, Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote:
Hiya,
On 07/12/15 11:23, Harald Alvestrand wrote:
> I think there's a piece of backstory here I'm not getting....
>
> Den 04. des. 2015 18:05, skrev The IESG:
>> The protocols in scope are Secure Shell (SSH), DNSSEC, PKIX, CMS, XML
>> Digital Signatures and potentially Kerberos and JSON.
>
> Why is TLS not included?
>
> It seems likely that the answer is one of:
>
> 1) TLS is already up-to-date in the space this group is limited to
> 2) TLS work is being done in the TLS working group
The latter, and a bit of the former:-)
>
> In both cases, it would be nice to say so in the charter.
The charter text tries to do that generically but does mention
TLS specifically in this bit:
"Where there is an IETF working group or area group with expertise in
a relevant topic the CURDLE working group will defer to the
consensus of the more specific working group as to where work will
be done. For example, the TLS, OpenPGP and IPSECME WGs are actively
considering some of these topics. "
That being so, I suggest adding S/MIME to the scope:
* S/MIME has approximately the same number of public certs issued as there are registered OpenPGP keys.
* The number of government certs is probably the same again and they are more active.
* The current state of S/MIME crypto is 3DES.
Yes, S/MIME is built on CMS but there is a little bit more. In particular the only channel you have to advertise the algorithms supported is through the cert chain. There is mechanism described in RFC2633, RFC6277 and RFC6664 but how pervasive is deployment and do all the parts join up?
I don't want us to be in a position where we find we need just a little bit of glue to make the system work and these are out of scope.
A similar issue occurs in SSH. Right now, managing SSH keys is a real PITA because the configuration tools all use keys rather than fingerprints of keys. Even though they all present fingerprints to the user when connecting to a new server.
A lot of these fingerprints are based on SHA-1 and while it might well be the case that collision attacks don't really matter, having to explain that repeatedly is an ongoing cost. And further, we can't rip SHA-1 or MD5 out of the crypto libraries as long as that type of vestigial application persists.
I would like us to have a common format for presenting fingerprints of keys across applications and at minimum use that for both SSH and OpenPGP.
In general we should attempt to converge on a single set of algorithm choices for all IETF protocols unless there are really good reasons to do something different. In particular we should really try to make sure that OpenPGP and S/MIME can both use the same set of algorithms. Right now we have a situation where S/MIME has the deployment advantage. If people want to get more OpenPGP deployment they should try to eliminate all unnecessary differences between the two systems. Having them use a common set of crypto algorithms is a good start, at that point the only difference between the systems is key infrastructure and message format.
What is most frustrating about the current situation is that we have the same round of bikeshedding among the same set of people every time a new security WG starts. Introducing the new CFRG curves is a good opportunity to change that.
It probably makes sense to write the charter in such a way that the group can consider recommendations for any IETF protocol that doesn't have an active WG and any active WG can delegate the issue to them.
I can't see much chance CURDLE comes up with consensus for a set of algorithms that isn't acceptable to TLS. If that happened the WG has failed. So the TLS chairs might as well consider CURDLE to be a way to take default algorithm choices off their plate.