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

Kathleen Moriarty <> Mon, 24 August 2015 20:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 145BA1B3282 for <>; Mon, 24 Aug 2015 13:31:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hboupLdAIB8Y for <>; Mon, 24 Aug 2015 13:31:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4A6A1B3280 for <>; Mon, 24 Aug 2015 13:31:17 -0700 (PDT)
Received: by widdq5 with SMTP id dq5so61194875wid.1 for <>; Mon, 24 Aug 2015 13:31:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=N4jz8E2mQl0UazD1N/GqFMJqcHwxWUNuwl4N0Yzfkv0=; b=wmxNS0TDwjA2UvmKxx9HrtpL4FaJCFTifN2c4RMCWTzlSSTgk6u7mOhZKXj+x3VDQD tE9PPxNDT1KgQKV4j30sS1DWzXgyDENml4cZia2oeyRTgtn+pG9j+9Uv/yJzL+M/LQuL 9d+tB2sCLWlrr6QfilC+2nLzvMry/FwOKCuFXVRLLZXlnmeybhhSaOTmCBVzyZ2az8aR HhU63+j1N0BrfN8zUaHapiHHz1lO+y0lVnq/wmnymAKHKQkN6wGXIi0nTNYjZEvzJcZB VgdYa1OwrMGhok+dBDgQoyrjsF1ZAe9IgkzqPanrf8IViFu3NvVWtk4c4QmxJCBEMHnJ TKbg==
MIME-Version: 1.0
X-Received: by with SMTP id o5mr31982706wiv.36.1440448276617; Mon, 24 Aug 2015 13:31:16 -0700 (PDT)
Received: by with HTTP; Mon, 24 Aug 2015 13:31:16 -0700 (PDT)
In-Reply-To: <>
References: <> <> <20150727194020.GD15860@localhost> <> <> <> <>
Date: Mon, 24 Aug 2015 16:31:16 -0400
Message-ID: <>
From: Kathleen Moriarty <>
To: "" <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Subject: Re: [saag] AD review of draft-iab-crypto-alg-agility-06
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Aug 2015 20:31:20 -0000

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.


On Tue, Jul 28, 2015 at 1:30 AM, Viktor Dukhovni <>; 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


Best regards,