Re: WG Review: CURves, Deprecating and a Little more Encryption (curdle)

[tom p. <[e-mail]>]

----- Original Message -----
From: "Phillip Hallam-Baker" <[e-mail]>
To: "tom p." <[e-mail]>
Cc: "Harald Alvestrand" <[e-mail]>; "IETF Discussion Mailing
List" <[e-mail]>; "Stephen Farrell" <[e-mail]>
Sent: Wednesday, December 09, 2015 2:28 PM
> On Wed, Dec 9, 2015 at 5:43 AM, tom p. <[e-mail]> wrote:
>
> > ----- Original Message -----
> > From: "Stephen Farrell" <[e-mail]>
> > To: "Harald Alvestrand" <[e-mail]>; <[e-mail]>
> > 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.
>