The latest version of this draft resolved all my concerns. Thanks to everyone
that put in all the time and effort.
Cullen
On Dec 16, 2010, at 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 t
o 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
with 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
short 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 sup
port 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf