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

From: Harald Alvestrand <[email-masked]>
Date: Mon, 7 Dec 2015 12:23:47 +0100

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

In both cases, it would be nice to say so in the charter.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Dec 2015 11:30:26 +0000

Hiya,

> 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. "

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Dec 2015 11:44:37 -0500

>    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.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Dec 2015 17:38:33 +0000

Hiya,

> That being so, I suggest adding S/MIME to the scope:

CMS is in scope and noted as such. If more drafts are needed though
then folks would need to write those soonish, assuming we end up with
consensus for a short-lived WG.

> across applications and at minimum use that for both SSH and OpenPGP.

I would also like that but a) I don't think it's for curdle and b) while
it'd be good, we (IETF) never seem to quite manage to avoid doing those
in protocol-specific ways.

The reason I don't think it fits curdle is that it's not only a
crypto algorithm - the hash input is the real issue there and that's
not in scope as far as I can see.

But if many folks wanted it, I'm sure they'd speak up now.

> default algorithm choices off their plate.

Sure, if the TLS folks wanted the work to happen in the curdle WG
that'd be no problem. I don't believe that is actually the case
though, at least for TLS codepoints. (The PKI stuff needed for TLS
does fit curdle for sure.)

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Dec 2015 15:53:21 -0500

> consensus for a short-lived WG.

Fair enough. I just want to make sure that this is inclusive.

One other related question is XML Encryption. given that all that is needed
to define code points in XML Encryption is to generate a URL, I suggest
that there be some sort of statement in the charter that allows that to
happen, whether through a liaison with W3C or just doing it.

> in protocol-specific ways.

How about if I write up my UDF proposal as an independent submission or AD
sponsored draft or whatever and at least we can say that we tried.

> not in scope as far as I can see.

In UDF I push that off to the MIME types registry. Whatever you want to
hash, you define a MIME type for it.

> does fit curdle for sure.)

TLS can certainly decide which of the 50+ possible permutations of the
algorithms that they want to identify suites for.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 7 Dec 2015 16:05:40 -0500

On Mon, Dec 7, 2015 at 3:53 PM, Phillip Hallam-Baker <[email-masked]>
wrote:

> ...
> One other related question is XML Encryption. given that all that is
> needed to define code points in XML Encryption is to generate a URL, I
> suggest that there be some sort of statement in the charter that allows
> that to happen, whether through a liaison with W3C or just doing it.
>

Just as a side note,  I currently
maintain draft-eastlake-rfc6931bis-xmlsec-uris as a place where XML
Security URIs can be accumulated.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 7 Dec 2015 21:39:43 +0000

> Security URIs can be accumulated.

Please check out the curdle list archive. I raised that and I think
it's in hand though we need to make a decision as to what's best,
including considering what W3C want.

S.

---

From: tom p. <[email-masked]>
Date: Wed, 9 Dec 2015 10:43:42 +0000

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Harald Alvestrand" <[email-masked]>; <[email-masked]>
Sent: Monday, December 07, 2015 11:30 AM
> 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.

Tom Petch

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Dec 2015 11:10:44 +0000

> in curdle (nor do I see any mention of curdle on the SSH list).

Good point. I'll do that now.

> gain any meaningful momentum.

I don't get what you mean. AFAIK, there's no current proposal to
re-form an SSH working group. There is some chat on the list along
those lines but I didn't interpret that as indicating that folks
want to do a new WG. (If they did, I'd be happy to assist in
getting that done.)

> proposal has got it quite right.

Again, I'm not sure what you mean, can you clarify?

Ta,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Dec 2015 09:28:55 -0500

> 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.

---

From: tom p. <[email-masked]>
Date: Wed, 9 Dec 2015 17:17:48 +0000

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "tom p." <[email-masked]>; "Harald Alvestrand"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, December 09, 2015 11:10 AM
> Again, I'm not sure what you mean, can you clarify?

Stephen

RC4 would be a case in point.  The TLS WG decided it was unsafe and made
its feelings known with 'draft-ietf-tls-prohibiting-rc4'.  What it did
not do, AFAICT, was think through the consequences so we still have RFC
4642  with a MUST implement RC4.  It is known and will be fixed, but
would have been done so with less demands on the IETF had this
dependency been picked up earlier.  (I did check the RFC for the
applications I deal with, and
their form of words was not affected by this deprecation). But last
month,
I saw a WG Last Call of an I-D saying

SHOULD support  TLS_RSA_WITH_RC4_128_SHA

so it seems like the message has not reached the places it needs to.

Compression is another.  The TLS WG (my main source of information on
security matters) has removed it from TLS 1.3 because of a security
exposure but again, I saw it offered in an I-D and have seen no
general statement about whether or when it is considered safe or not.

Hashing is yet another.  As you have seen, the SSH list is debating the
use
of SHA-2 and referencing SHA-3.  The TLS WG has made SHA-1 SHOULD NOT.
Previously, the weakness of MD5 was IMO not well handled - it had a
weakness but it was a while before an I-D spelled out when it was and
when it was not safe.  SHA-1 needs something similar (unless you think
that RFC6194 does this:-(.

Truncated MAC is another good source of confusion.  Is SHA-384 better
than SHA-512 and if so, when? Could do with an I-D here.  And so on.

I have said before that security (like transport) is arcane and what I
mean is that I believe that WGs in other areas need help, in a way that
they do not in much of the rest of the subject material of an I-D, more
clear, current guidelines as to what is ok for the applications being
specified (which is likely a somewhat lesser level of security than NSA
would specify!).

Tom Petch

> >>   "Where there is an IETF working group or area group with
expertise
> > in

---

From: tom p. <[email-masked]>
Date: Wed, 9 Dec 2015 17:08:15 +0000

----- Original Message -----
From: "Phillip Hallam-Baker" <[email-masked]>
To: "tom p." <[email-masked]>
Cc: "Harald Alvestrand" <[email-masked]>; "IETF Discussion Mailing
List" <[email-masked]>; "Stephen Farrell" <[email-masked]>
Sent: Wednesday, December 09, 2015 2:28 PM
> > > >> The protocols in scope are Secure Shell (SSH), DNSSEC, PKIX,
CMS,
> > XML

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: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Dec 2015 15:30:14 -0500

> will not - the expertise will be divided and so weakened.

The only action item I see here is to make sure that the proposal is
forwarded to the SSH list.

Right now, the biggest pains in using SSH are that there are three
different private key formats and authorized_keys has the whole key rather
than a fingerprint. So cut and paste really doesn't work very easily.

Those are both problems that I for one think are most likely to be fixed if
these 'experts' get some outside perspective.

I really could not care less what the format that they had chosen is. But
having to juggle three when one would have been enough only makes the whole
process less reliable and less user friendly.

---

From: David Morris <[email-masked]>
Date: Wed, 9 Dec 2015 14:23:22 -0800 (PST)

On Wed, 9 Dec 2015, Phillip Hallam-Baker wrote:

>
> I really could not care less what the format that they had chosen is. But having to juggle three
> when one would have been enough only makes the whole process less reliable and less user friendly.

It has always seemed to me that these variant formats I've encountered are
a 'feature' of product implementation rather than the space the IETF normally
standardizes. I'm not suggesting that one format isn't desireable, just
wondering where the agreement should be reached.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 10 Dec 2015 00:15:57 +0000

> than a fingerprint. So cut and paste really doesn't work very easily.

... and, while we are discussing this...

My biggest SSH complaint is a usability nit which causes security issues.
It may be an implementation / convention issue - I keep meaning to file a
bug, but instead I'll just kvetch here...

In my .ssh directory there some keys. As an example, the RSA key I use for
IETF NOC stuff:
-r--------   1 wkumari  staff   1675 Mar 13  2015 id_rsa_ietf_noc
-r--------   1 wkumari  staff    385 Mar 13  2015 id_rsa_ietf_noc.pub

I want to be able to use this key to login to routers and servers, so I
need to share the public key with folk / copy it to a server so I can
append it to an authorized_keys file / etc.

So, how do I do that?
Well, chances are I'm in a rush, so I do:
echo ~/.ssh/id_rsa_ie<tab tab> | email $someone
or
scp ~/.ssh/id_rsa_ie<tab> server.meeting.ietf.org:~/tmp

and, I've just emailed / copied off my *private* key.
The issue here is that the private key has no extension (and the public one
does), and so tab completion helpfully completes to the private key.
This could be easily solved by making private keys be called
id_rsa_ietf_noc.priv or something.

I guess I should really go file a bug, somewhere...

>
> Those are both problems that I for one think are most likely to be fixed
> if these 'experts' get some outside perspective.
>

Yah.

> process less reliable and less user friendly.

Fully agree. And, making tab completion not complete to the private key
would also be a user friendliness win...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Dec 2015 23:06:16 -0500

> wondering where the agreement should be reached.
Which is why I would prefer the discussion to happen among SSH users and
not the developers talking to themselves or following their own whims. If
there is a standard, most people will follow it.

At least two of the three private key formats are variants of IETF
specifications. They all use the IETF public key format.

Given that we do everything in JSON these days and we will be defining JSON
formats for use with JOSE, I expect we define a private key format.

Of course, the private key format should be encrypted and bound to a
particular host so it can't be mistakenly emailed. Windows has done that
for 20 years now. It doesn't stop a hacker extracting the key if a hard
drive is lost or a backup disclosed. But it is not nothing. OSX has the
keychain mechanism which is 15 years old or so.

I would very much like to see a similar feature added into Linux and I
would like to see every app use that type of capability. Managing crypto
keys should be an O/S level concern. That makes it much easier to make use
of hardware based crypto devices with a range of applications. But a
necessary first step to make that all happen is consistent data formats.