On Wed, Dec 9, 2015 at 5:43 AM, tom p. <daedulus@xxxxxxxxxxxxx> wrote:
----- Original Message -----
From: "Stephen Farrell" <stephen.farrell@xxxxxxxxx>
To: "Harald Alvestrand" <harald@xxxxxxxxxxxxx>; <ietf@xxxxxxxx>
Sent: Monday, December 07, 2015 11:30 AM
>
> 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:-)
There is also an active SSH list (albeit only about 5 message p.d.
lately which would barely be noticed on the TLS list:-( and Simon has
posted a message to the curdle list identifying some of that work; and
you yourself have posted to it so you know about it!
Conversely, I do not see most of those active on the SSH yet taking part
in curdle (nor do I see any mention of curdle on the SSH list).
Setting up this WG to look at SSH would seem divisive and unlikely to
gain any meaningful momentum.
I do think that the Security Area should be reaching out far more to
other areas to pro-actively provide guidance but do not think that this
proposal has got it quite right.
I don't think anything can be read into the lack of mention of CURDLE to date. Even I wasn't aware of the proposed WG and it is something I have proposed at least once a year for the past five. All the lack of discussion shows is that the people weren't part of whatever discussions happened at Yokohama. Quite probably they didn't attend which is probably the reason I didn't find out.
It is rather strange you would suggest that a proposal to establish consistent support for a set of algorithms across all the active IETF security protocols is 'divisive'. This is an engineering organization with a mission, not a social club and our mission is to serve the users of the Internet, not ourselves.
From the point of view of a SSH user, what I care about is that the algorithm choices are secure and wherever possible consistent with the choices made elsewhere. I really don't care what they are but I do care that they are exactly the same everywhere. Because that is what standards are all about.
Standards are a set of choices that don't matter. If the choice of SMTP choice mattered to the end user then the end user would need to make the choice. The reason we can tell everyone it is 25 is precisely the fact that all that matters is that someone chooses.
A protocol Working Group is the wrong place to choose crypto algorithms. The IETF doesn't have permanent Working Groups for a start. If the plan is to have a WG do a piece of work and shut down in 24 months, it can't have the job of maintaining crypto.
The bigger problem is that a WG has less of a voice than the IETF as a whole and that matters when it comes to influencing platform providers. At the moment, nobody implements CFRG signature and there are many toolkits that don't do AES-GCM. Most toolkits are actually written to support one specific application and then repurposed. So the set of algorithms you can use is effectively the intersection of TLS and PGP.
Having one set of crypto that every IETF protocol uses means that we can tell the platform developers what we want and be very likely to get it. This is the way to bring the long threads on GitHub on choices of new algorithms to be supported in .NET Core to a conclusion.
The risk of setting up a WG like CURDLE is that it becomes a forum for choosing between people's new and (they think) wonderful crypto algorithms. Which is why every time I have suggested choosing algorithms from the set already in use. The scope should certainly be expanded to include SHA3 but needs to be restrictive because otherwise the effort will become a forum for custom crypto.