Subject: [saag] a few new algs and a bunch of deprecation

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Nov 2015 04:42:37 +0000

Hiya,

At the secdir lunch this week in Yokohama we spoke about needing
a bit of organisation around adding new curves and about deprecating
some old algs (e.g. sha1).

There's a scattered set of stuff that'll need doing some of which
is in progress (e.g. drafts allocating OIDs for new curves so they
can appear in certificates), others of which may not yet be.

One possibility would be to try do this as a WG with a charter
that tightly defines which new things can be added but allows
for deprecating anything that should be deprecated.

The putative WG here would not I think tackle items where we have
a current WG active, e.g. TLS can handle defining codepoints for TLS.

As a separate but related thing, Alexey said he'd create a cfrg
wiki page where folks could add the names of drafts that are
defining things related to new curves. That might feed into the
positive parts of chartering.

FWIW, if this is something people support and find useful, Kathleen
and I are happy to help it happen. Next step would likely be to
start a mailing list for this and see if there's enough energy to
get stuff going. (If there is, I doubt a BoF would be needed.)

Thoughts?

S.

---

From: ianG <[email-masked]>
Date: Fri, 6 Nov 2015 02:17:41 +0000

> for deprecating anything that should be deprecated.

Add it to the charter of each WG?  OK.

My strawman thought of the last week was that every Security section in 
every future RFC should have a rollover / deprecation plan added to it. 
Bring the question of 2025 back to now - how does the designer of the 
protocol today think this should happen in 2025?

As I say, just a strawman, light your matches and throw...

> positive parts of chartering.

I'd not suggest passing "control" of new stuff across to CFRG or drafts, 
etc.  I would still leave control of the cipher suite with the designer 
(editor?) of the protocol.  This is the person best able to make the 
compromise call at the moment, and impose it on the next 20 years of users.

> get stuff going. (If there is, I doubt a BoF would be needed.)

Mammoth task :)  Won't get started unless it's started...

iang

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 Nov 2015 02:19:22 +0000

> Add it to the charter of each WG?  OK.

No that's not what I meant. We have protocols for which there
is no current WG.

S.

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 06 Nov 2015 11:15:48 +0100

> for deprecating anything that should be deprecated.

I believe fleshing out more details would help to establish wether this
is a good idea or not.

To be concrete, I perceive this to be about adding support for
Curve25519 key-agreement, Ed25519 digital signatures, and
ChaCha20-Poly1305 integrity-protected encryption.  Since the CFRG also
chose Curve448 we ought to include X448/Ed448, although before the CFRG
decision I saw close to zero demand from implementers so it will be
pushing things down people's throats and will lead to agility complexity
concerns but I believe we are okay with that (it would be boring if we
had no protocol weaknesses to fix).

The protocols that would be relevant are SSH (no active WG), PKIX (no
active WG), and DNSSEC (no DNS protocol-related active WG).  I believe
OpenPGP, TLS, IPSEC have active WGs that is working on this.  For JSON
there is a proposal but no public WG discussion.  The Kerberos community
have not been active in pursuing modern crypto.

Regarding deprecating SHA1, what is there really to be done?  What RFCs
needs updating?

Does it make sense to have a WG to take on SSH, PKIX and DNSSEC protocol
work?

Personally I feel the difficulty for each of the proposals have been
protocol-specific and not crypto-specific so that any cross-polination
between the work that we may get to see is not likely to motivate the
cost of setting up a new WG.  However, I do not know what was discussed
at the secdir lunch so I may be missing context.

/Simon

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 Nov 2015 10:41:00 +0000

Hi Simon,

> I believe fleshing out more details would help to establish wether this

Thanks for that. (Been a busy week and I didn't get around
to it.)

> have not been active in pursuing modern crypto.

Kerberos has the kitten wg as well so is fine.

> Regarding deprecating SHA1, what is there really to be done?  What RFCs

That'd need to be fleshed out during chartering or in the wg. I
personally think it'd be fine to deprecate any old crypto where
there's rough consensus (in the wg and IETF-wide) for that. And
adding the above algs to any protocol would also seem ok.

> Does it make sense to have a WG to take on SSH, PKIX and DNSSEC protocol

The main reason (for me at least) is that processing a whole bunch
of AD sponsored documents may take longer. Handling more than one
of those at a time is tricky and each last call takes a month in
the best case, longer if there's any controversy. And if there were
a wg I'd hope someone would have had time to check around and see
if there're any other places that need updates.

> at the secdir lunch so I may be missing context.

Setting up a wg like this isn't costly once there's a few folks
willing to chair/edit and enough to credibly review.

Cheers,
S.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 6 Nov 2015 10:23:37 -0500

> have not been active in pursuing modern crypto.

OpenSSH has already deployed Curve25519, and written a description of how
to do it. PKIX I believe is being dealt with in TLS by some people, but I
don't know. Fundamentally if vendors want to change the work will be done,
and if they don't the work is useless.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 7 Nov 2015 01:09:26 -0500 (EST)

> > have not been active in pursuing modern crypto.

I'm not sure if you're referring to the people who still haven't switched
off of single-DES (yes, really!  Quite a few of them!), or a lack of
interest in post-AES/sha1.

> Kerberos has the kitten wg as well so is fine.

On the face of it, maybe.  There is a draft proposing AES/SHA2 enctypes,
which got some attention, but the WG is a bit low on energy in general.
Some extra folks helping pull in, e.g., ChaChaa20-Poly1305 would be quite
welcome.  The elephant in the room is that if Microsoft doesn't implement
a new enctype for AD, it is unlikely to see widespread adoption.

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Nov 2015 10:22:19 +0000

(First, I'd really appreciate if folks could give feedback on the
general idea here and say if they'd help with some of the work.
Without that, we're gonna have a long waiting list for AD-sponsored
things for the next quite a few months.)

More below on Kerberos...

> a new enctype for AD, it is unlikely to see widespread adoption.

True.

One option we could explore is where the putative WG (where there may
be energy for a bit) could, with the agreement of the kitten WG (in
this case) do some of the work and we could do WGLC in both the
putative new WG and in this case kitten.

We'd likely want to do something like that with dnsop in any case
when it comes to anything touching on the DNS.

Cheers,
S.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Nov 2015 13:50:45 +0100

> interest in post-AES/sha1.

With "modern crypto" I refer to crypto designed for the classical
requirements that have good implementation characteristics such as high
performance and amenable to some flavor of side-channel protection.  AES
has okay performance (compared with for example 3DES), but not
particulary nice side-channel properties, and is often used in insecure
modes (non-AEAD).  So in the "modern crypto" category, I would not count
AESand would include ChaCha20-Poly1305, Curve25519, and Ed25519.  If
anyone has a better term than "modern crypto" that would be useful.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Nov 2015 13:54:16 +0100

> things for the next quite a few months.)

If it would actually speed up the publication process (something I'm not
convinced of, but my viewpoint may be limited) I'm happy to help with
draft/charter reviews, draft editing, and proto-writeups.

/Simon

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Nov 2015 15:54:46 +0200

> On 10 Nov 2015, at 2:54 PM, Simon Josefsson <[email-masked]> wrote:
> 

Me too. 

I think recent evidence has shown that having an algorithm document from CFRG makes the protocol WG process much easier. Having RFC 7539 meant that the drafts for IPsecME and TLS were accepted quickly, were kept short and proceeded through last calls (so far only IPsec) with no hand-wringing over “how do we know if this is a good idea or secure”.  I think the Curves documents are doing the same.

But if we start writing kitten documents, I’m afraid we’re going to run into people who tell us, “no, no, no, you don’t understand Kerberos. This is all wrong.” So I’m not sure this will solve more problems that it creates.

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Nov 2015 13:54:58 +0000

> draft/charter reviews, draft editing, and proto-writeups.

Thanks Simon. With 6-8 drafts (if we have that many) a WG would
speed up the process and would also remove potential doubts about
IETF consensus I think.

Cheers,
S.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 10 Nov 2015 16:00:01 +0200

> On 10 Nov 2015, at 3:54 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

Are there any candidate drafts now?

Yoav

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 10 Nov 2015 15:33:49 +0100

> Are there any candidate drafts now?

The IPSECME WG have accepted a document on key agreement.  The TLS WG
(which spawned the CFRG discussion) accepted key agreement, and the
latest WG document RFC 4492bis discuss signatures although I don't
recall any consensus call about adding that. The OpenPGP WG have EdDSA
signatures. The further non-WG documents I can recall now include:

SSH
---

ed25519 sign
https://tools.ietf.org/html/draft-bjh21-ssh-ed25519-02

curve25519+curve448 kex:
https://tools.ietf.org/html/draft-josefsson-ssh-curves-00

missing: ed448

PKIX
----

Curve25519+Curve448 namedCurve:
https://tools.ietf.org/html/draft-josefsson-pkix-newcurves

EdDSA Ed25519(ph) and Ed448(ph)
https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04

DNS
---

Ed25519:
https://tools.ietf.org/html/draft-sury-dnskey-ed25519-03

Ed448:
https://tools.ietf.org/html/draft-sury-dnskey-ed448-00

JSON
----

There is an unpublished proposal floating around.

/Simon

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 11 Nov 2015 14:00:22 -0500

I do think having this in a WG would be helpful to get the right set
of eyes on drafts that may span several areas.

A draft that was just posted to the JOSE list could possibly be done
in this new group:
https://mailarchive.ietf.org/arch/msg/jose/fADOQ-T_fWySMnRbe5QkTqPX7-E

Kathleen

-- 

Best regards,
Kathleen