Minutes IETF98: curdle

Meeting Minutes CURves, Deprecating and a Little more Encryption (curdle) WG
Title Minutes IETF98: curdle
State Active
Other versions plain text
Last updated 2017-03-27

Meeting Minutes

   curdle minutes

administrivia, note well

most of this meeting is probably going to be asking people
to commit to reading the drafts.

oid assignment - request iana arc to replace oids in current
draft.  Symantec had donated a short arc but the contact
person disappeared.  Yoav will sync up with IPSec folks.
Prehash vs non-prehash: the consensus is to define only
non-prehash, and the draft needs to state that clearly.
Prehash needs to be removed as an algorithm identifier.
Tomi volunteered to review.

in wglc.

Not much to say - only one review so far.  Rich will get
someone to review from OpenSSL team.

in wglc.

There have been three reviews

in wglc.

good shape, almost ready for wglc, two reviews so far and
need more

pretty much ready.  Some changes submitted to the list.
Need more review, particularly for clarity of language.
Already widely deployed.

only adding a point or two.  Please say that you agree to move
this forward.

PHB: General ssh question: if you add a user key that isn't
understood, will the client fall over?  Answer: it tries
user keys until it reaches maximum failures

EKR: I'm surprised you're not using the ones we're
standardizing in TLS.  Rich: we're reflecting what's in the
deployed base.  DKG: Shouldn't use the same groups being
specified for TLS, although we should use defined groups
AGL: the draft is documenting reality, but why wouldn't you
want to use the same groups?  DKG: the rules for generating
strong groups are well-understood, but you might not want to
use them cross-domain.  These are also same groups used by
IKE.  Rich: will encourage discussion on the list, we'll
pollute IKE and TLS, too.  Tero: these are the groups being
used in IKE.  Might be premature for last call, needs

Any other business?
We have a request for a GSS update, next draft coming.

Russ: did we talk about draft-pkix?  Did we talk about
absent, null, or both?  the asn1 structure allows the
parameters field, when they converted to the newer syntax,
the editor dropped the word "optional" in the algorithm
identifier, so people added null as algo ID.  some
implementation insist on some parameter and Russ would
rather not.  Argument is pick one, not accept either one.
AGL: strongly supports that view - doesn't care which, but
pick one!  Jim: document has picked one.  It matters because
standard Java provider can't deal with it.  Tero: I think
Java just needs to fix it.  Absent breaks Java.  Hum:
choices are absent, null, or both.  response: Nobody
supports both, nobody supports null.  Consensus is for
absent.  Jim: That's what it says now.

Any other business?  No.

Last question about the use of PSS or PKSS in SSH .  we
would strongly like to move to pss.  Jim: shoot 1.5 in the
head.  Yoav: there's no weakness known in pkss 1.5.  if
there's no weakness, why add new stuff?  Tero: ipsec was
using 1.5 also but recommended pss is the one they should
use.  AGL: pss would be nice but isn't the world moving away
from rsa as a whole?  Stephen: is anyone in the room
implementing?  No - then we shouldn't decide.  Yoav: since
it's going into tls 1.3 everybody's going to be implementing
anyway.  Nobody has any strong feelings, but why add
something nobody's going to use?