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

Phillip Hallam-Baker <hallam@gmail.com> Sat, 21 November 2009 20:42 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 495A63A67AC; Sat, 21 Nov 2009 12:42:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1lIZWdBj+z7; Sat, 21 Nov 2009 12:42:40 -0800 (PST)
Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 87C823A682F; Sat, 21 Nov 2009 12:42:40 -0800 (PST)
Received: by ywh15 with SMTP id 15so4218858ywh.5 for <multiple recipients>; Sat, 21 Nov 2009 12:42:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zVqqxNyO6m1vrifW3LwZrbExMWyM/W1PqcyP8m/JV5w=; b=NQxMUh1uAnIucKOUPlCvvdKvzTJ2p65U6ospQuIZMIfYHz4KiTJ8oK37rEc1X+tpv0 hLnEKzoc2Z8xnjihjHXElTpEwfYm3/7PVha3+le18LbkJyRBBxjss7/pD1cnz0uRcaOW 9ILYJKLc8pB13+LLrfK7aYBSlT3kn0JnXMQh0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ZW0tdRdoTNLouMsnTRFSOKN8287f2KzttJuj5yNXftpbWXFloBjJTfvr0g4K6LSRt6 Mf45U1nlpjvp99Jw2POkpfNsL2ddJC4DMtvzp7ZwLzvY+EuopUqmt4x9W5+qcUDTGDJf F20RyuzmaA+d5IeRXrB8A/8JAMlXk2liGVB/0=
MIME-Version: 1.0
Received: by 10.91.18.24 with SMTP id v24mr4463679agi.61.1258836153936; Sat, 21 Nov 2009 12:42:33 -0800 (PST)
In-Reply-To: <988E4A1D-518B-467F-97A1-3087CE6D071A@cs.columbia.edu>
References: <D80EDFF2AD83E648BD1164257B9B0912082E2E08@TK5EX14MBXC115.redmond.corp.microsoft.com> <988E4A1D-518B-467F-97A1-3087CE6D071A@cs.columbia.edu>
Date: Sat, 21 Nov 2009 15:42:33 -0500
Message-ID: <a123a5d60911211242m73f8fa48xf5434919015b6bbc@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Steven Bellovin <smb@cs.columbia.edu>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Cc: "secdir@ietf.org" <secdir@ietf.org>, "fred@cisco.com" <fred@cisco.com>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [secdir] Secdir review of draft-baker-ietf-core-03.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Nov 2009 20:42:42 -0000

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 <smb@cs.columbia.edu> wrote:
>
> 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
>
>
>
>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> 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/