Re: [Fed-Talk] PKI SIGNED E-MAIL
Re: [Fed-Talk] PKI SIGNED E-MAIL
- Subject: Re: [Fed-Talk] PKI SIGNED E-MAIL
- From: "Blumenthal, Uri - 0668 - MITLL" <email@hidden>
- Date: Mon, 07 Nov 2011 15:32:43 -0500
- Acceptlanguage: en-US
- Thread-topic: [Fed-Talk] PKI SIGNED E-MAIL
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