Re: [certid] Review of draft-saintandre-tls-server-id-check-12

I just realized that we never replied publicly. Jeff and I had a phone
chat with Cullen (and Alexey) about this before the holidays, and we
plan to submit a revised I-D this week. Cullen raised some very good
points, which we've attempted to address in the forthcoming version.

On 12/16/10 8:22 AM, Peter Saint-Andre wrote:
> Thanks for your comments. My co-author and I will need to confer before
> replying, and that might take a few days given the length of your review.
>
> Peter
>
> On 12/16/10 12:17 AM, Cullen Jennings wrote:
> > 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.

smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf