Re: [saag] AD review of draft-iab-crypto-alg-agility-06

After reading through this thread again, I don't think we have clear
consensus to match statements being made in this draft in section 2.9:

2.9.  Opportunistic Security

   Despite the guidance in Section 2.4, opportunistic security [RFC7435]
   SHOULD also be considered, especially at the time a protocol
   implementation is deployed and configured.  Using algorithms that are
   weak against advanced attackers but sufficient against others is a
   way to make pervasive surveillance significantly more difficult.  As
   a result, algorithms that would not be acceptable in many negotiated
   situations are acceptable for opportunistic security.  Similarly,
   weaker algorithms and shorter key sizes are also acceptable for
   opportunistic security.  That said, the use of strong algorithms is
   always preferable.

Maybe I'm in the rough, but I read through many varying opinions in
this thread, with contributors each having their own caveat to the
general statement, yet we have general statements in the OS RFC and
this draft.

The first sentence in this section counters what Viktor is saying was
intended in the OS RFC (per this thread), that this provision should
only apply to legacy systems.  When protocols are designed,
appropriate crypto should be specified.  Then it is better to use
outdated rather than nothing later on in deployment cycles.  Others
added in additional caveats to the general statement, so I don't think
we really have consensus on this set of points.

I'm personally okay with the concept that using deprecated algorithms
is better than nothing, but I'd rather it be clear that this choice is
not in compliance with current recommendations otherwise we will never
be able to complete transitions.  As such, I'd rather it not be part
of how we discuss OS since it only appears as a couple sentences in
the overall RFC.  As with S/MIME, this would just be a hold out due to
upgrade complications with older implementations - it's ok, but not
okay as part of OS giving it an excuse to stick around longer.

If others think I'm in the rough, it would be good to know.

Thanks,
Kathleen

On Tue, Jul 28, 2015 at 1:30 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> On Tue, Jul 28, 2015 at 04:54:58AM +0000, Christian Huitema wrote:
>
>> OS is by definition prone to MITM attacks, including downgrade attacks.
>
> [ Yes, when not authenticated.  There's also downgrade-resistant OS, via
>   e.g. DANE, but not widely deployed at present. ]
>
>> Just negotiating any which algorithm key that comes out of the channel is
>> too dangerous for my taste. If we do OS we should also enable a form of
>> MITM detection, maybe channel binding. It will not be used in all OS
>> connections, but using it in some connections in an unpredictable should
>> be enough to detect and deter mass deployment of MITM.
>
> I agree this is desirable, but it is rather difficult to make MiTM
> detection practical in many cases, e.g. email.  Sure one could log
> channel-unique tags on both sides, but who's going to ever compare
> them?
>
> One might propagate the tags along the forward-path in new trace
> headers, but those would need to be signed by the previous-hop MTA,
> at which point, we're no longer talking about unauthenticated
> opportunistic TLS.
>
> The trick is finding a way to make it possible and worthwhile for
> a sufficient fraction of participants to add the requsiite checks.
> This can work for interactive protocols (humans on phone verbally
> verify matching channel-ids), but is rather difficult for
> store-and-forward.
>
> For SMTP transport at least, DANE looks like a more promising
> counter-measure to active attacks.
>
> --
>         VIktor.
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag

-- 

Best regards,
Kathleen