Skip to main content

Minutes IETF97: curdle
minutes-97-curdle-00

Meeting Minutes CURves, Deprecating and a Little more Encryption (curdle) WG
Date and time 2016-11-18 02:50
Title Minutes IETF97: curdle
State Active
Other versions plain text
Last updated 2016-12-08

minutes-97-curdle-00
IETF 97
Curdle, 17 Nov 2016 (Friday)
Minutes by Ben Kaduk
Chair Rich Salz (Daniel could not attend)

CMS drafts
curdle-cms-chacha20-poly1305 is publication requested.
cms-ecdh-new-curves and cms-eddsa-signatures need rev to align with PKIX
draft, then WGLC.  Quynh will review, Sean Turner has been volunteered WGLC
after Russ puts out new rev. No call for shepherd yet, but be warned that
it will come.

DNSSEC
curdle-dnskey-eddsa in WGLC.
Daniel is already assigned as shepherd

PKIX drafts
Daniel is also assigned as shepherd
Call for people who want to change "CAs MUST NOT use pre-hash EdDSA"
Quynh says that with a good hash, both options are secure; no strong opinion.
Tero reaffirms only one option as being very good; nothing else in the IETF
is using pre-hash, and we don't want to be the only one.
Jim has also not seen anyone use pre-hash.
Russ is maybe changing his mind; if we use *only* prehash then we get the
Init-Update-Final API back.
Strong hum to leave text as-written ("MUST NOT"); Rich to confirm consensus on
the list Russ says that the document should contain the "con" bullet.
(In security considerations or maybe elsewhere, as Kyle Rose points out.)

SSH drafts
curdle-rsa-sha2 ready for WGLC
Kyle Rose has reviewed
Chairs to ask for more reviewers on the list, then go to WGLC.

curdle-ssh-ext-info
curdle-ssh-kex-sha2
curdle-ssh-modp-dh-sha2
no one has read these;
Kyle asks whether the last one includes a way to choose groups to avoid
security issues. Try to start a discussion over the next couple weeks over
these three documents.  Make sure that there is not too much overlap and
things are split out in a good way.

IPSEC
Chairs had talked about maybe going through the RFCs and making an IANA
registry.

Contexts
TLS thought contexts were a good idea (6 months ago) TLS has worked around
their need for this. CFRG signature schemes still have a context field, but
general advice from many people is that we don't need them anymore.
Propsal: say that we don't use them, in particular, say "use an empty context"
whenever we use a signature algorithm that has a context input.
hum; 50-50 between yes and "need more information to decide"
no one says specific more information needed; just time to think about it.