On Wed, Dec 9, 2015 at 5:43 AM, tom p. <daedulus(_at_)btconnect(_dot_)com>
wrote:
----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Harald Alvestrand" <harald(_at_)alvestrand(_dot_)no>;
<ietf(_at_)ietf(_dot_)org>
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.