IETF Logo Mail Archive

Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis

Robert Moskowitz <rgm@htt-consult.com> Tue, 22 July 2014 14:45 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49C11B2886; Tue, 22 Jul 2014 07:45:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 JpNoynHeKD0q; Tue, 22 Jul 2014 07:45:17 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [IPv6:2607:f4b8:3:0:218:71ff:fe83:66b9]) by ietfa.amsl.com (Postfix) with ESMTP id 841321A02D0; Tue, 22 Jul 2014 07:45:17 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 5538D62AB3; Tue, 22 Jul 2014 14:45:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VouAOnm--U9; Tue, 22 Jul 2014 10:45:04 -0400 (EDT)
Received: from lx120e.htt-consult.com (dhcp-b32e.meeting.ietf.org [31.133.179.46]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 7194662C31; Tue, 22 Jul 2014 10:45:03 -0400 (EDT)
Message-ID: <53CE78ED.1030602@htt-consult.com>
Date: Tue, 22 Jul 2014 10:45:01 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ted Lemon <ted.lemon@nominum.com>, James Cloos <cloos@jhcloos.com>
References: <53BB798A.3080101@tomh.org> <m3lhs3dh5w.fsf@carbon.jhcloos.org> <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com>
In-Reply-To: <399ECC6D-CB3D-46F7-A9D7-7465608F1B77@nominum.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/VbXA_W1H9GZmxFtx5cFnkHoOkPc
Cc: hipsec@ietf.org, saag@ietf.org
Subject: Re: [Hipsec] [saag] NULL encryption mode in RFC 5202-bis
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jul 2014 14:45:21 -0000

On 07/22/2014 10:28 AM, Ted Lemon wrote:
> On Jul 8, 2014, at 11:06 AM, James Cloos <cloos@jhcloos.com> wrote:
>> If those doing IP over Amateur Radio are a use case, they require NULL.
> If Amateur Radio's prohibition on encryption is considered to be important in making decisions about crypto in protocols, then I think we are in a situation where we can't have crypto protocols that don't disallow downgrade attacks, because implementations always have to be willing to downgrade to no encryption if the other endpoint is an Amateur Radio station.
>
> So, by reductio ad absurdum, I claim that this isn't something the working group should consider as a deciding factor.   I think the same observation also applies to Michael's comment about debugging on stacks with limited trace capability.   If you need to disable encryption, you should have to do something fairly extraordinary to make that happen.

It is a switch to request integrity only. Or to only allow integrity 
only. Either party MUST be able to reject an integrity only negotiation.

v2.23.0 | Report a Bug | By Email