Hiya,
On 07/12/15 16:44, Phillip Hallam-Baker wrote:
On Mon, Dec 7, 2015 at 6:30 AM, Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
wrote:
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:-)
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. "
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.
* 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.
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.
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.
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.