Re: [Fed-Talk] PKI SIGNED E-MAIL
Re: [Fed-Talk] PKI SIGNED E-MAIL
- Subject: Re: [Fed-Talk] PKI SIGNED E-MAIL
- From: Matthew Linton <email@hidden>
- Date: Mon, 07 Nov 2011 12:44:22 -0800
The kind of user decision I want to disallow is to disallow the user
from overriding control in a specific environment where that control is
a trust escrow provided by an OPS style office. That's a far cry from
"Treat the user like..." anything, and it's disingenuous of you to imply
anything otherwise. You cannot sum up a persons' entire operational
perspective from their single opinion on a technical issue. Well, you
can, but it's professionally disrespectful.
The discussion began talking about international and extended character
sets at some point. This isn't just a discussion over allowing users to
determine upper/lowercase distinctions in a signature match for a name
lookup, it's about a lot of other characters.
Allowing the user to trust that "email@hidden" must be the
same as "joe.bloggs@..." by character (remember, Upper and lower are
separate characters) seems like a perfectly logical decision, until you
extend that by necessity to including "joe.bloggs@..." and
"jöe.bloggs@..." -- those may very well be two distinctly different people.
In a control-oriented system (which enterprise email encryption
certificate management often implies) this could be a very bad idea.
==========================
Matt Linton, GCIH, EZ2C
IT Security Operations Lead
NASA Ames Research Center
650-380-4281 (mobile)
On 11/7/11 12:32 PM, Blumenthal, Uri - 0668 - MITLL wrote:
Yes there's a wide range of attitudes - but the kind of user decisions you want to disallow puts the attitude you propose right in the middle of "treat the user like...". In your approach the user is neither empowered/trusted nor responsible (which is equally bad).
I'm sorry that I couldn't convince you. You and your examples aren't convincing to me.
--
Regards,
Uri Blumenthal Voice: (781) 981-1638
Cyber Systems and Technology Fax: (781) 981-0186
MIT Lincoln Laboratory Cell: (339) 223-5363
244 Wood Street Email:<email@hidden>
Lexington, MA 02420-9185
Web: http://www.ll.mit.edu/CST/
MIT LL Root CA:
<https://www.ll.mit.edu/labcertificateauthority.html>
DSN: 478-5980 ask Lincoln ext.1638
----- Original Message -----
From: Matthew Linton [mailto:email@hidden]
Sent: Monday, November 07, 2011 03:10 PM
To: Blumenthal, Uri - 0668 - MITLL
Cc: Fed Talk<email@hidden>
Subject: Re: [Fed-Talk] PKI SIGNED E-MAIL
Uri - I think there's a wide range of attitudes between "There are some
critical decisions that users should not have the option to override"
and "Treat the user like an idiot". Your straw man isn't helpful, and
isn't convincing me.
==========================
Matt Linton, GCIH, EZ2C
IT Security Operations Lead
NASA Ames Research Center
650-380-4281 (mobile)
On 11/7/11 11:41 AM, Blumenthal, Uri - 0668 - MITLL wrote:
On 11/7/11 14:35 , "Matthew Linton"<email@hidden> wrote:
I should point out here that, for security, there are a number of things
we don't WANT left in the hands of the user. For things like email
signatures, which are often by definition authoritative declarations of
trust by third party escrows of said trust, I don't think it should be
left up to the user to override those declarations.
Treat the user as an idiot - and sooner or later he'll conform to that.
If a user is allowed the choice to trust "loose matches" of
username-to-cert combinations, I expect to see spoofed encrypted
messages very shortly in the vein of 'email@hidden' ->
'email@hidden'
How is "email@hidden" vs "email@hidden" in any way similar to
"email@hidden" vs "email@hidden"?
(Yeah, if we allow users to think and make decisions, the whole world
would turn upside down. Well then, enjoy the status quo.)
One of our major problems with security right now is that users are all
too willing to 'trust' and permanently store declarations made by their
email clients and by received emails. :P
I don't concur.
On 11/7/11 11:30 AM, Blumenthal, Uri - 0668 - MITLL wrote:
A usable Mail Agent must leave the final decision in the hands of the
user. I.e. if a user decides that email sent by email@hidden and signed
by email@hidden is "kosher", the Mail agent must allow the user to
(permanently) set this exception for the given address-cert pair.
RFC is not a suicide pact. The final and ultimate goal is to
interoperate,
not to demonstrate who's "holier than thou".
<rant>
For example (and side-tracking), Apple may be 10 times right in its
assessment of usefulness (or lack of) of FIPS certification for software
modules. But if Apple doesn't initiate Lion crypto FIPS certification
process FileVault 2 won't be allowed in Fed agencies, other solutions
(like WInMagic SecureDoc) would be forced, and finally when it becomes
obvious that both choices (use SecureDoc and miss out on OS security
updates, or stay current on OS patches and lack FIPS-certified FDE) are
bad users will be pushed away from Mac towards Win (mostly) and Linux
desktops. In our Lab there's already a blanket prohibition on purchasing
equipment that can run only Lion (hopefully it will be lifted). Does
Apple
Care?
</rant>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Fed-talk mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden