So let me start with I think there is great information in here and I think it should be published as a standards track RFC however I do think there are some issues with the relation with this draft and the realities of what would help improve security in deployment of SIP, HTTP, IMAP, XMPP etc.
There are many places where this draft makes choices to improve the security from many current practices. At face value this seems like a good thing but it's not always. The thing reducing the overall security available to users of TLS is not if certs use CN-ID or DNS-ID, it is that it's such a PITA to deploy a TLS server that people choose to not use TLS at all. Everywhere there is a trade off between making things marginally more secure, or making things cheaper and easer to deploy, I think we need to seriously consider the cheaper and easier approach. Yes, some things are just broken even if they are easy and obviously we can't do those. Let me give an example of this. I looked at the cert for the domains for the authors of this draft. www.cisco.com has 3 DNS names even though as fas as I can tell one of these are for something that would typically be used in a ftp URI and the other HTTP URI. This is because it makes it easier and cheaper for them to use TLS yet seems to go against the recommendation of this "BCP". Then I went over the www.paypal.com domain which uses, gasp, a CN-ID. Do we really believe that paypal is seriously compromising their security by using a CN instead of URI-ID? If so, how? I'm pretty sure the paypal guys know how to run a secure web server. With the exception of Microsoft small business server certificates (which are outrageously expensive by the way) it pretty hard to get SRV name certs. In making these recommendations, did the TLS WG consider the relative prices of various types of certificates? Lets say I had a certificate for the domain example.org because I was using it for email and it has a CN because I got it years ago. Now lets say I am going to go deploy a SIP service on example.org. My position is that best way to encourage the use of security on the internet is to just reuse the certificate I have. It cheap, it's easy, it secure enough even if it does make you feel a bit dirty. I think Jeff disagrees w ith me, we argued for years about this topic and my understanding is his position is that it would be better to say that all new deployments MUST not use a CN name because it's less secure. Give the prevalence of CN on the internet today, I think it is fine to tell people how DNS-ID is better but I don't think it's OK to tell them they should not use CN-ID and I definitely don't think it is OK to tell implementors they don't need to implement CN-ID. I encouraged Chris to write this draft long ago and what we had discussed at the time was forming a RFC with one or more boiler plate pieces of text that could be used in creation of the name matching section of new protocols that got developed. I was thinking of something similar to the way we use rfc 5226 for writing IANA consideration section. Instead we have a document that is creating a very complex situations about whats normative. This draft is a BCP level, and it says you have to do everything in PKIX and PKIX takes precedence. That is basically elevating PKIX to a BCP without appropriate process review. Next this draft contradicts the procedures in existing protocols and says that it does not apply to the existing protocols but that it would take precedence over any future updates of existing protocols that use TLS within the scope specified here. I do not believe you have the consensus of the people woking on SIP that the next time some specification is marked as an UPDATE to 3261, that implementations need to implement the procedures in this draft. Furthermore, I think that would be counter productive. I think you should make it clear this guidelines for designers of new protocol and people updating existing protocol and that these protocols could make their own choices but would want to take into account the information in this draft. When I read the sentence, "However, the best current practices described here can be referenced by future specifications, including updates to specifications for existing application protocols if the relevant technology communities agree to do so." I think that is exactly the right solution to the problem. However, that not a BCP, thats a standards track spec. Furthermore, I think this draft is going to have all the normal bugs etc of any other spec that defines algorithms and such it should proceed through the standards track process. If this draft is going to go as a BCP, that text contradicts what a BCP is and needs to come out and the rest of the draft be adjusted appropriately. My preference would be that this draft be standards track. Its writing exactly the same sort of normative algorithm text that we put in all kinds of other thing like SIP, HTTP, and even TLS. They are all standards track. This should be the same. Most RFCs today that use TLS have a page plus or minus that tells an implementer what they need to know about matching names in certs. This draft move that to 30 to 50 pages depending on how you count. Most implementers are just going to ignore this thus worsening the security situation. Think about why is the part implementers need to read 10x longer than existing deceptions - this just seems wrong. Now it's easy to blow off this type concern and say get over it, it's the same number of lines of code they need to write. But the problem is when an implementors goes to start doing this and encounters something that is 50 pages long, they instantly decide this is a big task and down it goes on the priority list of actually happening. The other problem is that even thous it is long, it is still very confusing on how to do things (such at URI). I'll provide more detailed examples of this later in this email. If the document was restructured to have all the normative text in one s hort simple description and the rest moved to an appendix, it would be much easier to get people to take this seriously and easier to review that it was correct. My final big issue is the use of normative language. Lets say there are two procedures A and B and we 100% consensus that B is better than A but we still have to support A for existing deployment reasons. To describe this, the text this draft would use is is MUST do A and SHOULD NOT do B. Now reading 2119 it is pretty clear that SHOULD NOT means you don't implement it unless there are real good reasons to implement it. So on the things were we agree A is preferred to B but you need both for backwards compatibility, this draft needs to say MUST implement A and MUST implement B but deployments are encouraged to use B as we are trying to move away from A. I think the whole document needs a careful read checking for this issue. You can insert the usual rant here about why SHOULD is a awful word in specs 90% of the time it used because implementer thinks it means "ignore rest of sentence". For example, section 5.4 discusses they this spec continues to mandate protocols MUST suppo rt CN yet this draft continually use "SHOULD NOT" when what it really means is MUST implement. This is going to confuse implementors of IETF specification and be ignored by operators. Given the goals of this spec it would be much better if it was clearly defining what IETF required implementers of protocols to do instead of confusing that with how we wish security was deployed. On to the nits. Take an applications like a web server. Is the preferred thing in a cert a DNS-ID or a URI-ID. My reading of the 3.3 is that URI-ID is preferred over DNS-ID yet the examples don't match that. I think point 3 in section 3.1 tries to explain this away but I don't understand that - clearly web browsers use a URI. The rules in section 3.1 don't make sense for a CA. How will the CA know if the cert I want is going to be used for a protocol that uses SRV? In section 3.2, in the imap example, you are saying that if I configure my imap server to mail.example.com and it presents a certificate with a DNS-ID of example.com that this is OK. That does not sound OK to me but I don't know how IMAP works. In the SIP example, the cert should have a SRV and DNS name too. As well as a CN if you actually want it to work in the real world. In section 4.2.1 you have a long discussion on how the information used must come from a way that can't be tampered with over the internet. I generally agree with this but would like to point out that protocols like LOST (see section 18 of rfc5222) specially do the opposite of this and actually match the cert agains the output of NAPTR process not the input to the NAPTR process. The example just seem plain wrong in some cases. Take for example section 4.2.2 where the SIP example has only a URI reference identifiers and no DNS yet the section right before this has said the list MUST include a DNS-ID. This text has been through how many reviews and Last Calls? The problem here is that this draft is too long to review for stuff like this. Even after the IESG is done reviewing it, statistics suggest it will still be littered with bugs like this and implementors will use the examples to guide them. If someone implements what is in the example, it will break in lots of sip deployments. There is a whole algorithm about matching various ID types, but the note about you ignore CN if you have other things is off in "Security Warning" very much out of any flow of the algorithm description then pointed out again in some other section. It's not wrong, but it's a bit weird from an implementer point of view. Many applications do need to deal with IP matching as well as domain names. The way this text is written here makes it harder to figure out how and where to mix that in. I'd rather see it just dealt with than instead of making it out of scope. Obviously it's not common on internet but it is common on private networks and walled gardens where many of the protocols were are talking about are deployed. Many of the "internet of things" people I work with have no intention of using DNS at all. I scoffed at multiple large service providers 10 years ago when they said they were not using DNS with SIP but many still use IPs. This sounds less insane when you consider the major OS don't ship with an asynchronous DNS library. I'm baffled on why checking the service name in a SRV record is a SHOULD not a MUST. Could you add text explain why and when one would not check it. If you were in a really good mood you could do that for all the SHOULDs. Actually, when I read section 4.5 carefully, I think it literally says that when using a URI, checking the domain name is a SHOULD not a MUST. Surely check the domain name matches is not a SHOULD level sort of thing. Section 5.4. I have no idea why it matters that some major OS does not support SNI. Even if that OS did support SNI, many many applications running on that OS and the others would not support SNI. It seems like it is the applications acting as TLS servers and clients that are the important thing, not the OS. How you process URI-ID needs work. I could not figure out how to implement given the text in the draft as is. Even ignoring the special tar pit the SIP guys dug for themselves with tel URL processing, just the normal sip, sips issues seems unclear. This seems like a long list of complaints delivered fairly late but, once again, I really do like much of the information in here and think it should be published as PS - it just would be significantly improved with a bit of a re-factored and clean up. If this had been run through the TLS working group, I would have caught all of this in the WG LC. This is a draft that, as a BCP, profoundly effects many of the protocols I work on including SIP but as far as I can tell has not done much to gather the consensus of the people working on protocol that this draft changes - I don't recall hearing about it until after it went to the IESG so I'm pretty un apologetic about providing these comments during IETF LC. In summary, I like the information in this but I think it still has many small things that need fixing and needs to be changed to get crisp about what implementors need to do and drop the confusing stuff about how we wish operators and CA might use certificates. I also feel strongly that the right way to look at this draft is, as that draft says "practices described here can be referenced by future specifications, including updates to specifications for existing application protocols if the relevant technology communities agree to do so" and that for that reason it has to be standards track not BCP. If it was not being written and pushed by two IESG members, I don't think we would even be discussing if it should be a BCP. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
