Re: Agenda, security, and monitoring

I looked at the specifications recently. There is certainly support for
concealing the RFC822 From and To headers and the Subject line. There are
two sets of metadata to consider:

1) The SMTP routing data (RFC821)
2) The Message headers (RFC822)

There are two sets of issues, one is what the specifications say, the other
is what the implementations do.

S/MIME does support concealing the RFC 822 header data because it is not
used in routing. Only the RFC821 data is used for routing. The RFC822
header data is only used by the email client to decide how to respond.

I have successfully routed several SMTP messages with no RFC822 routing
data at all. I plan testing support for 'full wrap' as described in the
specs but not for a while. To give a useful answer would require a look at
each and every email client including older versions.


The problem then is not how to achieve this particular capability in the
specification, it is how to make use of it in a way that does not cause
unpleasant user experiences when people have non-compliant software.

People with Outlook 2007 (say) who are happy with it are unlikely to want
to spend $350 to upgrade so that they don't get mysterious encrypted
messages that don't have sender names or subject lines.

On Mon, Feb 3, 2014 at 10:28 AM, Stephen Kent <kent(_at_)bbn(_dot_)com> wrote:

> I think the S/MIME tripe wrapping feature may already provide a way to
> conceal
> header info not needed to delivery.
>
> Steve
>
>  On 2/1/2014 6:44 PM, Stephen Farrell wrote:
> > > If someone wanted to propose using PGP or S/MIME (aka CMS) formats
> > > to provide closer-to-end-to-end confidentiality protection for email
> > > messages that covered most headers in a way that might get deployment
> > > then I think that would not match your description. I do suspect
> > > that that is not likely to happen.
> > 1.  Very much not likely.
> >
> > 2.  It's unrelated to the parts of such a service that appear to be the
> > major barriers to large-scale use
> >
> > 3.  It's the wrong level of design discussion, at this stage.
> >
> >
> >  If OTOH, we spent a lot of time debating email message origin
> > > authentication then I fully agree with you that we'd just be
> > > distracting ourselves pointlessly.
> > +1
> >
> > d/

-- 
Website: http://hallambaker.com/