Re: [saag] OS features/requirements analysis

[Stephen Kent <[e-mail]>]

Viktor,

On 4/14/14 3:36 PM, Viktor Dukhovni wrote:
> ...
> My take is that we need a more precise definition of "mandatory".
>
>      - Mandatory to implement?
>      - Mandatory to prefer?
>      - Mandatory to use (negotiate)?
Good question in the current environment.
I'm old school IETF, so mandatory means mandatory to implement.
Preferences and decisions to use are local matters.
> At least with PFS, one might reasonably argue for the first two,
> but requiring PFS use seems rather contrary to the "opportunistic"
> mind-set of doing the best you can.  If the peer only offers RSA
> key transport, then that's what you go with.  The peer's configuration
> is then not marketable as fully "OS" enabled.
>
>> 3.  Opportunistic security SHOULD (?) make use of key agreement (vs. key
>> transport) and employ perfect forward secrecy (PFS).
> Here, I would strongly suggest that being "opportunistic" the SHOULD
> only covers "implementation" and "preference" for PFS, but does
> not imply any mandate to use PFS (or else refuse to encrypt? Really???).
Again, implementation.
>> 5.Detection of a man-in-the-middle (MiTM) attacks is a desired, but not
>> mandatory, feature.
>>
>> Rationale: If crypto-based authentication is successful, it provides
>> detection of a MiTM attack (subject to the veracity of the credentials
>> employed.) However, even if such authentication cannot be achieved, it may
>> still be possible to detect a MiTM.MiTM detection is considered a lower
>> priority than authentication, and is to be pursued only if the former
>> security service is not available (or fails). Again, if a MiTM is detected,
>> this event is NOT signaled to the user/application.
> The above is a bit too restrictive for "opportunistic DANE TLS",
> where one strives for downgrade resistance when possible, and may
> well signal authentication failure to the user/application.  Of
> course the application needs to elect this mode of operation
> (opportunistic with DANE).

I think this needs to be discussed in a general context, not just for
the cited example. A lot of folks seemed to feel strongly that the 
success or
failure of opportunistic security ought bot be made visible to users/apps.
Maybe they were thinking more about users than apps, and thus this feature
should be tempered with that in mind. There was also a brief discussion 
of whether
a server should be notified when a failure (authentication or MiTM 
detection)
occurs, vs. silent acceptance on behalf of a client.

Steve