----- Original Message ----- From: "Phillip Hallam-Baker" <phill@xxxxxxxxxxxxxxx> To: "tom p." <daedulus@xxxxxxxxxxxxx> Cc: "Harald Alvestrand" <harald@xxxxxxxxxxxxx>; "IETF Discussion Mailing List" <ietf@xxxxxxxx>; "Stephen Farrell" <stephen.farrell@xxxxxxxxx> Sent: Wednesday, December 09, 2015 2:28 PM > 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. Phillip By divisive, I mean that the expertise, the knowledge, the skills will be divided. I see the SSH list as the best source of information on SSH, its use and development. Setting up another list to discuss such matters will divide that expertise; some will join the new list, others will not - the expertise will be divided and so weakened. Tom Petch > 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. >