Hiya, On 07/12/15 16:44, Phillip Hallam-Baker wrote: > On Mon, Dec 7, 2015 at 6:30 AM, Stephen Farrell <stephen.farrell@xxxxxxxxx> > 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.