Re: [Simple] Issue 1: End-to-End encryption

[Ben Campbell <ben at estacado.net>]

On Nov 8, 2005, at 1:51 PM, Burger, Eric wrote:

> So the text should read something like
>
> "The UAS SHOULD encrypt the IMDN, unless it doesn't feel like it."?

Something more like "SHOULD encrypt, unless it determines that the  
cost of doing so outweighs its need for privacy, or it just can't  
encrypt because it does not have the necessary cert". I know that is  
not very satisfying, but from a pragmatic position, lots of deployers  
are going to ignore this even if it says MUST.

> But seriously, who gets to chose?  I care about security.  I send a
> message, requesting an IMDN.  The UAS is lazy and doesn't care about
> security and sends a clear text IMDN.  I get pissed off.
>
> Conversely, I don't care about security, I send a message,  
> requesting an
> IMDN.  The UAS was written by someone in the Security Directorate, and
> uses strong encryption.  I have to spend cycles to decrypt the  
> message.
>
> On the other hand, I don't care about security and I somehow mark the
> message to be in plain text.  I send a message, requesting and IMDN.
> The UAS honors the request, which pisses off the UAS' user, because  
> now
> their information is in clear text.
>
> So, if we don't go the simple route of all IMDN's are encrypted, we
> should have:
>  o  A mechanism to let the sender insist on encrypted IMDN

Agreed.

>  o  A mechanism to let the sender insist on unencrypted IMDN
>  o  A mechanism to inform the sender if their request cannot be  
> honored

On the last two: Currently the UAS can refuse to send an IMDN for any  
reason, without explanation, right? Why is this different?

> -----Original Message-----
> From: Ben Campbell [mailto:ben at estacado.net]
> Sent: Tuesday, November 08, 2005 1:54 PM
> To: Burger, Eric
> Cc: Hisham Khartabil; simple at ietf.org
> Subject: Re: [Simple] Issue 1: End-to-End encryption
>
> I agree that these things should be SHOULD. I'd love them to be MUST,
> but I think that a MUST here will be summarily ignored by
> implementers, or just used as an excuse to ignore the spec.
>
> As far as explanatory text goes, I think we are covered if the
> security considerations describe the implications of not encrypting.
>
> On Nov 8, 2005, at 4:24 AM, Burger, Eric wrote:
>
> > SHOULD's require explanatory text for when you don't need to do
> > whatever
> > isn't a MUST.
> >
> > Text would be needed here.
> >
> > -----Original Message-----
> > From: Hisham Khartabil [mailto:hisham.khartabil at telio.no]
> > Sent: Monday, November 07, 2005 1:58 PM
> > To: Burger, Eric
> > Cc: simple at ietf.org
> > Subject: Re: [Simple] Issue 1: End-to-End encryption
> >
> > I would make it a SHOULD.
> >
> > Hisham
> >
> > On Nov 7, 2005, at 4:24 PM, Burger, Eric wrote:
> >
> > > The draft asserts that IMDN's MUST be end-to-end (S/MIME) signed at
> > the
> > > least, and preferably encrypted.  Is this OK with everyone?
> > >
> > > Pro:
> > > Only way to ensure end-to-end security
> > > Only way to have some modicum of privacy, especially when dealing
> > > with
> > > B2BUA's.
> > >
> > > Con:
> > > Is the key infrastructure extant to enable end-to-end encryption for
> > > EVERYONE?
> > > Some more processing at the sender and receiver.
> > >
> > > _______________________________________________
> > > Simple mailing list
> > > Simple at ietf.org
> > > https://www1.ietf.org/mailman/listinfo/simple
> >
> > _______________________________________________
> > Simple mailing list
> > Simple at ietf.org
> > https://www1.ietf.org/mailman/listinfo/simple


_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple