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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf