Subject: [secdir] Secdir review of draft-baker-ietf-core-03.txt

From: Charlie Kaufman <[email-masked]>
Date: Sat, 21 Nov 2009 04:41:41 +0000

I am reviewing this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Others should treat these comments just like any other last call comments. Feel free to forward to any appropriate forum.

This document (proposed as an Informational RFC) summarizes the core protocols on which the Internet operates. It is specifically targeted at NIST in the context of the Smart Grid discussion. They are looking to "profile" a subset of the Internet Protocol Suite. Since the audience for this review is security focused, I'll talk about security first. But since I read it all, I'll include comments on the rest too. I would encourage others to read the document. It's both informative and could generate a lively discussion about what constitutes "the core".

As a truly informational document, this document has no security implications, though it does talk about security. It considers IPsec, TLS, and S/MIME to be the core security protocols. I would consider adding DNSSEC to that list, and possibly removing S/MIME, but these three are certainly a reasonable place to start.

Section 3.1 attempts to explain why it's natural for IPsec and TLS to both exist, and reminded me how much each has encroached onto the territory of the other making that task more difficult. I believe that the original distinction was that IPsec was designed to be implemented in operating systems or networking infrastructure in a way that was transparent to applications, while SSL was designed to be implemented in applications in a way that was transparent to operating systems and networking infrastructure. That's not a bits on the wire distinction, but I believe all the other differences derive from that. But TLS has now been extended to protect datagrams and IPsec to authenticate users with SecurID cards. I don't know which is the more natural fit for Smart Grid, but I doubt it's both.

Comments on the whole document:

Section 1 para 3: re: picking a subset of protocols rather than protocol subsets. This makes sense for "old" protocols, like TCP, that have few options. It doesn't for "new" protocols, like PKIX, which allow variation without end.

Section 2.1.3.1: The Internet Layer here is what you called the Network Layer on the previous page (I think). Fragmentation and reassembly is only part of this layer any more if you hold your head just right. I'm not sure "identifying" a datagram's source and destination is properly the roll of this layer. "Finding" the destination is more like it. This section describes the part of the IP layer implemented by endnodes. Most of IP is implemented (today) in intermediate nodes. Would OSPF be a core protocol, or do you assume these systems run atop an existing infrastructure?

Section 2.2.1: Physical security: It's worth mentioning that many systems assume physical security within some subnet (like a machine room or a corporate intranet) and reflect that in believing that source and destination IP addresses are authentic if they are both in a controlled range. One might question whether this is wise, but it is certainly common. Protocols often reflect assumptions about physical failures and attacks in the timeout/retry parameters they choose.

Section 2.2.2: The last paragraph seems to have fallen into this document from somewhere else. Does it belong elsewhere?

Section 2.3: DNS seems like a critical piece of making the Internet work. There might be applications that could live without it, but not many.

Section 2.3.1: DNS also supports limited slow mobility. A service can move and change IP address if everyone references it by DNS name.

Section 3.1.2: It's misleading to say that IPsec implemented between the routing and transport layer. That's true in transport mode, but in tunnel mode there is an IP header before and after the IPsec header (putting it in the middle of routing).

Section 3.1.2: In the RFC list RFC4304 is the right RFC to reference but it is not ISAKMP. RFC4309 specifies AES CCM mode, which I believe is not the most commonly used cryptographic algorithm.

Section 3.1.4: I'd be surprised if S/MIME was originally an extension to SMTP. Even when S/MIME was PEM, it was largely transport independent (and designed to pass over X.400, which was a contender in those days). S/MIME - and more generally CMS - is not really a networking protocol at all. It is designed to protect data at rest. I can take a CMS protected file and send the pile of bits to you by floppy disk or paper tape. Years later, if you can still read the media, you can still process it. It's a tough call whether it is an Internet Core Protocol. It's certainly an important IETF protocol.

Section 3.2: "the IPv6 space" -> "the size of the IPv6 address space"

Section 3.2: "in the near term." -> "in the near term if interoperability with existing IPv4-only systems is important."

Section 3.2.1.1: It's worth noting that IPv4 addresses are typically administratively assigned in blocks, which then get subdivided, and that they are commonly handed out individually to client nodes using DHCP but that servers typically need permanent IPv4 addresses so that other nodes can find them in DNS.

Section 3.2.1.3: Avoid a common confusion by explaining that reliable in this case means that retries are automatic and that failures are reliably detected. Reliable Multicast can't get the data there if the network is broken.

Section 3.2.2.1: IPv6 also hands out addresses administratively in blocks which are then subdivided. Autoconfiguration is only different from DHCP in that you're "guaranteed" not to run out.

Section 3.2.2.2: Mention that addresses are hierarchical when handed out administratively in order to keep routing tables from exploding in size.

Between section 3.2.3 and 3.3: This would be a good place to remind people of the "hourglass": many protocols above, many below, but a single IP in the middle. (Well IPv4 and IPv6, but that's "temporary").

Section 3.3.1, para 1: I would claim that UDP is a perfectly valid transport protocol. It only appears not to be because it is the native mode of IP and therefore seems natural. Running over X.25, TCP would seem like the null protocol and UDP would be interesting and novel.

Section 3.3.1, para 2: UDP has problems because it does not play well with others in terms of congestion backoff. Does it have problems other than that?

Section 3.4.1, para 1, line 6: "all" -> "allow"

Middle of page 22: "address/aport" -> "address/port"

---

From: Fred Baker <[email-masked]>
Date: Sat, 21 Nov 2009 22:08:50 +0900

Thanks. I'll review your comments next week when I'm at home :-)

On Nov 21, 2009, at 1:41 PM, Charlie Kaufman wrote:

> I am reviewing this document as part of the security directorate's  
> ongoing effort to review all IETF documents being processed by the  
> IESG.  These comments were written primarily for the benefit of the  
> security area directors.  Others should treat these comments just  
> like any other last call comments. Feel free to forward to any  
> appropriate forum.
>
> This document (proposed as an Informational RFC) summarizes the core  
> protocols on which the Internet operates. It is specifically  
> targeted at NIST in the context of the Smart Grid discussion. They  
> are looking to “profile” a subset of the Internet Protocol Suite.  
> Since the audience for this review is security focused, I’ll talk  
> about security first. But since I read it all, I’ll include comments  
> on the rest too. I would encourage others to read the document. It’s  
> both informative and could generate a lively discussion about what  
> constitutes “the core”.
>
> As a truly informational document, this document has no security  
> implications, though it does talk about security. It considers  
> IPsec, TLS, and S/MIME to be the core security protocols. I would  
> consider adding DNSSEC to that list, and possibly removing S/MIME,  
> but these three are certainly a reasonable place to start.
>
> Section 3.1 attempts to explain why it’s natural for IPsec and TLS  
> to both exist, and reminded me how much each has encroached onto the  
> territory of the other making that task more difficult. I believe  
> that the original distinction was that IPsec was designed to be  
> implemented in operating systems or networking infrastructure in a  
> way that was transparent to applications, while SSL was designed to  
> be implemented in applications in a way that was transparent to  
> operating systems and networking infrastructure. That’s not a bits  
> on the wire distinction, but I believe all the other differences  
> derive from that. But TLS has now been extended to protect datagrams  
> and IPsec to authenticate users with SecurID cards. I don’t know  
> which is the more natural fit for Smart Grid, but I doubt it’s both.
>
> Section 1 para 3: re: picking a subset of protocols rather than  
> protocol subsets. This makes sense for “old” protocols, like TCP,  
> that have few options. It doesn’t for “new” protocols, like PKIX,  
> which allow variation without end.
>
> Section 2.1.3.1: The Internet Layer here is what you called the  
> Network Layer on the previous page (I think). Fragmentation and  
> reassembly is only part of this layer any more if you hold your head  
> just right. I’m not sure “identifying” a datagram’s source and  
> destination is properly the roll of this layer. “Finding” the  
> destination is more like it. This section describes the part of the  
> IP layer implemented by endnodes. Most of IP is implemented (today)  
> in intermediate nodes. Would OSPF be a core protocol, or do you  
> assume these systems run atop an existing infrastructure?
>
> Section 2.2.1: Physical security: It’s worth mentioning that many  
> systems assume physical security within some subnet (like a machine  
> room or a corporate intranet) and reflect that in believing that  
> source and destination IP addresses are authentic if they are both  
> in a controlled range. One might question whether this is wise, but  
> it is certainly common. Protocols often reflect assumptions about  
> physical failures and attacks in the timeout/retry parameters they  
> choose.
>
> Section 2.2.2: The last paragraph seems to have fallen into this  
> document from somewhere else. Does it belong elsewhere?
>
> Section 2.3: DNS seems like a critical piece of making the Internet  
> work. There might be applications that could live without it, but  
> not many.
>
> Section 2.3.1: DNS also supports limited slow mobility. A service  
> can move and change IP address if everyone references it by DNS name.
>
> Section 3.1.2: It’s misleading to say that IPsec implemented between  
> the routing and transport layer. That’s true in transport mode, but  
> in tunnel mode there is an IP header before and after the IPsec  
> header (putting it in the middle of routing).
>
> Section 3.1.2: In the RFC list RFC4304 is the right RFC to reference  
> but it is not ISAKMP. RFC4309 specifies AES CCM mode, which I  
> believe is not the most commonly used cryptographic algorithm.
>
> Section 3.1.4: I’d be surprised if S/MIME was originally an  
> extension to SMTP. Even when S/MIME was PEM, it was largely  
> transport independent (and designed to pass over X.400, which was a  
> contender in those days). S/MIME – and more generally CMS – is not  
> really a networking protocol at all. It is designed to protect data  
> at rest. I can take a CMS protected file and send the pile of bits  
> to you by floppy disk or paper tape. Years later, if you can still  
> read the media, you can still process it. It’s a tough call whether  
> it is an Internet Core Protocol. It’s certainly an important IETF  
> protocol.
>
> Section 3.2: “the IPv6 space” -> “the size of the IPv6 address space”
>
> Section 3.2: “in the near term.” -> “in the near term if  
> interoperability with existing IPv4-only systems is important.”
>
> Section 3.2.1.1: It’s worth noting that IPv4 addresses are typically  
> administratively assigned in blocks, which then get subdivided, and  
> that they are commonly handed out individually to client nodes using  
> DHCP but that servers typically need permanent IPv4 addresses so  
> that other nodes can find them in DNS.
>
> Section 3.2.1.3: Avoid a common confusion by explaining that  
> reliable in this case means that retries are automatic and that  
> failures are reliably detected. Reliable Multicast can’t get the  
> data there if the network is broken.
>
> Section 3.2.2.1: IPv6 also hands out addresses administratively in  
> blocks which are then subdivided. Autoconfiguration is only  
> different from DHCP in that you’re “guaranteed” not to run out.
>
> Section 3.2.2.2: Mention that addresses are hierarchical when handed  
> out administratively in order to keep routing tables from exploding  
> in size.
>
> Between section 3.2.3 and 3.3: This would be a good place to remind  
> people of the “hourglass”: many protocols above, many below, but a  
> single IP in the middle. (Well IPv4 and IPv6, but that’s “temporary”).
>
> Section 3.3.1, para 1: I would claim that UDP is a perfectly valid  
> transport protocol. It only appears not to be because it is the  
> native mode of IP and therefore seems natural. Running over X.25,  
> TCP would seem like the null protocol and UDP would be interesting  
> and novel.
>
> Section 3.3.1, para 2: UDP has problems because it does not play  
> well with others in terms of congestion backoff. Does it have  
> problems other than that?
>
> Section 3.4.1, para 1, line 6: “all” -> “allow”
>
> Middle of page 22: “address/aport” -> “address/port”

---

From: Steven Bellovin <[email-masked]>
Date: Sat, 21 Nov 2009 12:03:04 -0500

On Nov 20, 2009, at 11:41 PM, Charlie Kaufman wrote:

>  
> Section 3.1.4: I’d be surprised if S/MIME was originally an extension to SMTP. Even when S/MIME was PEM, it was largely transport independent (and designed to pass over X.400, which was a contender in those days). S/MIME – and more generally CMS – is not really a networking protocol at all. It is designed to protect data at rest. I can take a CMS protected file and send the pile of bits to you by floppy disk or paper tape. Years later, if you can still read the media, you can still process it. It’s a tough call whether it is an Internet Core Protocol. It’s certainly an important IETF protocol.

That section is incorrect in several respects, in my opinion.  First, S/MIME doesn't protect "SMTP Mail", in my opinion, since to me "SMTP" is referring to the 821/2821/5321 parts of the protocol.  S/MIME is more for the 822/2822/5322 parts.  More precisely, S/MIME is a way to put in security at the MIME layer (references omitted), which in turn extend 822/2822/5322.  The distinction is important because HTTP uses MIME but not SMTP.  (It could have used S/MIME, but that's a separate wistful thread.)  Second, it's an interesting question if CMS should be mentioned separately -- you can't do S/MIME without CMS.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 21 Nov 2009 15:42:33 -0500

You can however do CMS without S/MIME.

I agree that we should regard S/MIME as an extension to MIME. But the
origin was really to take the RSA developed PKCS#7 technology and
apply it to MIME. There really isn't much of a link there to the PEM
work. The IETF attempt to resurrect PEM in MIME was MOSS.

The problem here is trying to cram everything into a layered model in
the OSI style. These attempts always fail because the IETF protocols
are not a layered architecture. It is much more like a web of modules
that expose interfaces to other co-operating modules. While there is a
rough conceptual organization according to the degree of abstraction,
this is not the only organization present and it is nowhere near as
rigid as in the OSI model.

The point about S/MIME being protection of data at rest is a critical
one. We do in fact have a security layer for SMTP - TLS. More mail is
secured using TLS than any other mail encryption protocol.

The point being that smart grid is not an opportunity for the IETF to
roll out the architecture that they would have liked to have developed
rather than the one that did develop. Some of the differences can be
explained by path dependence, but quite a few can be explained by the
market having made the better choice.

On Sat, Nov 21, 2009 at 12:03 PM, Steven Bellovin <[email-masked]> wrote:
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Fred Baker <[email-masked]>
Date: Sun, 22 Nov 2009 06:05:57 +0900

Hmm. I wonder of one of the directorate members would like to suggest  
better text for the section? I don't claim any expertise on that topic.

On Nov 22, 2009, at 5:42 AM, Phillip Hallam-Baker wrote:

>>> transport independent (and designed to pass over X.400, which was  
>>> a contender in those days). S/MIME – and more generally CMS – is  
>>> not really a networking protocol at all. It is designed to protect  
>>> data at rest. I can take a CMS protected file and send the pile of  
>>> bits to you by floppy disk or paper tape. Years later, if you can  
>>> still read the media, you can still process it. It’s a tough call  
>>> whether it is an Internet Core Protocol. It’s certainly an  
>>> important IETF protocol.
>>
>> That section is incorrect in several respects, in my opinion.   
>> First, S/MIME doesn't protect "SMTP Mail", in my opinion, since to  
>> me "SMTP" is referring to the 821/2821/5321 parts of the protocol.   
>> S/MIME is more for the 822/2822/5322 parts.  More precisely, S/MIME  
>> is a way to put in security at the MIME layer (references omitted),  
>> which in turn extend 822/2822/5322.  The distinction is important  
>> because HTTP uses MIME but not SMTP.  (It could have used S/MIME,  
>> but that's a separate wistful thread.)  Second, it's an interesting  
>> question if CMS should be mentioned separately -- you can't do S/ 
>> MIME without CMS.
>>
>>

---

From: Steven Bellovin <[email-masked]>
Date: Sat, 21 Nov 2009 17:13:28 -0500

> You can however do CMS without S/MIME.

Precisely my point.
> work. The IETF attempt to resurrect PEM in MIME was MOSS.
....
> one.

Right -- what should we recommend?

> We do in fact have a security layer for SMTP - TLS. More mail is

Yes, but not really relevant for this section.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 Nov 2009 10:11:22 -0800

At 6:05 AM +0900 11/22/09, Fred Baker wrote:
>Hmm. I wonder of one of the directorate members would like to suggest better text for the section? I don't claim any expertise on that topic.

3.1.4 Cryptographic Message Syntax (CMS)

The CMS [RFC3852] specification defines how to digitally sign,
digest, authenticate, and encrypt message content. It is commonly
used for email with S/MIME [RFC3851] and other message-based (as
compared to session-based) protocols.