Re: [tcpm] TCP-AO crypto, SHA-2 MAC_Length (was: "Re: SHA-2 auth draft on TCP-AO")

Gregory Lebovitz <gregory.ietf@gmail.com> Wed, 08 October 2014 20:04 UTC

Return-Path: <gregory.ietf@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC3E1A00B7 for <tcpm@ietfa.amsl.com>; Wed, 8 Oct 2014 13:04:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnx_cvyH2a-P for <tcpm@ietfa.amsl.com>; Wed, 8 Oct 2014 13:04:10 -0700 (PDT)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CC61A0095 for <tcpm@ietf.org>; Wed, 8 Oct 2014 13:04:10 -0700 (PDT)
Received: by mail-qg0-f44.google.com with SMTP id j5so7696584qga.3 for <tcpm@ietf.org>; Wed, 08 Oct 2014 13:04:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FSGIMu3Kmuf9YXyx8XoUD0Ap9mbKJMa62Mx293a7mb4=; b=cdP2tbJm0zsSm+k9T6X/Qa8ggVhN6n9s+8LqGdC2/7BN9sYiurwO3FwE4+alG+jNVx zBtVNnjiM1cZyI71b8cWzyeYJgPqeK3jaPbB1tu/lYiF3vu9zs7RNHvo+PlrlDLiueSy hSNVnXow+Y4NTCKpNlXaKKcpCpt0nUqUjB3u0Cg4/ryCxkPmxkQxCMUfodlpbA39kz2O w/7Zq2A7T6STnwOI88G05lKbspas4ITYFDViZk1cYSpP/IwTNNu0k4vmUnQP/aW9NjTH +e6ldFFjWroWQvmwTXXXLqfp9tBGwoPeTbHFBbOk0CiQbR8PJV8wBqDDPGTYGJ3IUjHe QocQ==
MIME-Version: 1.0
X-Received: by 10.224.79.67 with SMTP id o3mr7346312qak.103.1412798649405; Wed, 08 Oct 2014 13:04:09 -0700 (PDT)
Received: by 10.140.18.137 with HTTP; Wed, 8 Oct 2014 13:04:09 -0700 (PDT)
In-Reply-To: <542B42B9.8070605@isi.edu>
References: <CALG4KobLVfnpBWDbAyqxkJj5xw7+bTaURYvXJ0pdWtZ+1DOnJw@mail.gmail.com> <542B42B9.8070605@isi.edu>
Date: Wed, 08 Oct 2014 13:04:09 -0700
Message-ID: <CALG4Kob110-+k2fud-+g5pA1qwnTSqUeKBi8LQWqiU-WMEOpSQ@mail.gmail.com>
From: Gregory Lebovitz <gregory.ietf@gmail.com>
To: Joe Touch <touch@isi.edu>
Content-Type: multipart/alternative; boundary="047d7bdc9f78a317390504eed1cc"
Archived-At: http://mailarchive.ietf.org/arch/msg/tcpm/XhNOj9147_ltAxeNmk9T_R4mFIw
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] TCP-AO crypto, SHA-2 MAC_Length (was: "Re: SHA-2 auth draft on TCP-AO")
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Oct 2014 20:04:12 -0000

On Tue, Sep 30, 2014 at 4:54 PM, Joe Touch <touch@isi.edu> wrote:

>
>
> On 9/30/2014 4:19 PM, Gregory Lebovitz wrote:
> ...
> > GML>  we clearly didn't say "MUST be 96 bits, no more", but the last
> > sentence was meant to guide people toward a truncation of the MAC down
> > to 96-bits in order to fit nicely into the -AO option field.
>
> The -AO option supports any MAC length. The issue is conservation of TCP
> header option space and its interaction with other TCP options.
>

+1, good clarification


>
> > There was
> > security review and consensus that truncating a MAC output > 96 bits
> > would be fine.
>
> "fine" was determined at the time by both Security and Transport, i.e.,
> Security felt it was large enough for the desired protection and
> Transport felt it was small enough to "play nice" with other options.
>

+1
Gregory


>
> Joe
>



-- 
----
IETF related email from
Gregory M. Lebovitz