Re: [Dots] Eric Rescorla's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT)
Eric Rescorla <ekr@rtfm.com> Fri, 22 February 2019 13:41 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEA8128766 for <dots@ietfa.amsl.com>; Fri, 22 Feb 2019 05:41:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 TzGEPdQxiexi for <dots@ietfa.amsl.com>; Fri, 22 Feb 2019 05:41:53 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59B7130ED8 for <dots@ietf.org>; Fri, 22 Feb 2019 05:41:49 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id q11so1749034lfd.3 for <dots@ietf.org>; Fri, 22 Feb 2019 05:41:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6R0egXVGyhbRm7SBkgqsh/D9HbNAOvOAeKQtkHkM7K4=; b=Yob9e1ZZ5uwaLRvxKrmr4D8Uk3/ZZhox+dF3QuxvVkA7pe7+BlSWcmLmRE2PushDr1 l1op1Xv801hoUAvvP/iyC9TLks43tbuufeUmZ/sxXQ1QD4VQr6kjNXPOgw/gpUptX99p y49sGeZfxHEfn2i/7y/1TDcCdr/RYkFp7U4yRlLIYFabtqjyIgN9BN4qGVMGwQ/Lhl++ Ffb4d95Me5V9SOaNdhelc0Y5/RJMIOIVKizn38CmB6TKjDBuYdOeDfYV49EXAie6ORKy wYU2macz317OiqFtDPQD/LJrKm3o5kkV0mieEsJOaNJoHASgjPSm/48ssLr5y4omofBs 0YCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6R0egXVGyhbRm7SBkgqsh/D9HbNAOvOAeKQtkHkM7K4=; b=ASXRq0STGLnGHYEBbLMCFs2iYL8mJc6VcYHIg0NMjzyqeJ+7uFEaVvttu5MgAyIHp0 0/6piagHyF0HUqqaTE8yaBpPBYjStjsiaYLyi/mzxRrNGPdiYohITVMr8kdSUZFHFcxS iULqrgAbbtxDSwShM4Ojd3+yvnC2nc896GtZvMPL5CjTnaox/QFE/rgJ44IcB8cg68y4 Z6KL512ktdpnY6eScUJKmImcIsyRkrdyhl69NgyDzFgntdL2NA5OjQaEodkNiKNRjO1y CfXVOSLAzihh3OxWTRsIoklwWRX+3fEwrd6gWvbS3etjZqBmJdPJ74hrensNJZBXxtZd TiyQ==
X-Gm-Message-State: AHQUAuaiYytGSci6u9p4ojuk0V1c7rCYZItxZPbU20QWSNnWIJxlcczF rduWLiPmHXLWgQjHUpfzg6/CzcaqpAWF4ke0WYRFow==
X-Google-Smtp-Source: AHgI3IZsbF7rnpVO4/spoXtgnkZDLBU3ySS0MkQZOksGz25nZ3abGOgd2lWY3TfrIorpQdBV8LfTaBcPm+RwhnfUotg=
X-Received: by 2002:ac2:51bc:: with SMTP id f28mr2669064lfk.123.1550842907533; Fri, 22 Feb 2019 05:41:47 -0800 (PST)
MIME-Version: 1.0
References: <155076138334.8654.4433425046363509880.idtracker@ietfa.amsl.com> <BYAPR16MB27907AFCEC70695076EFD2B9EA7F0@BYAPR16MB2790.namprd16.prod.outlook.com>
In-Reply-To: <BYAPR16MB27907AFCEC70695076EFD2B9EA7F0@BYAPR16MB2790.namprd16.prod.outlook.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 22 Feb 2019 05:41:10 -0800
Message-ID: <CABcZeBOAYzwf1SzdEJWwGgd3z3t+nGeJ1i4GW58OOwoDtLCn5w@mail.gmail.com>
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@mcafee.com>
Cc: The IESG <iesg@ietf.org>, "dots-chairs@ietf.org" <dots-chairs@ietf.org>, "frank.xialiang@huawei.com" <frank.xialiang@huawei.com>, "draft-ietf-dots-requirements@ietf.org" <draft-ietf-dots-requirements@ietf.org>, "dots@ietf.org" <dots@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009b3d0d05827bc010"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/_UEUxCKf2TA9axzi9WpjjEF6-5g>
Subject: Re: [Dots] Eric Rescorla's Discuss on draft-ietf-dots-requirements-18: (with DISCUSS and COMMENT)
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Feb 2019 13:41:57 -0000
On Fri, Feb 22, 2019 at 3:41 AM Konda, Tirumaleswar Reddy < TirumaleswarReddy_Konda@mcafee.com> wrote: > Hi Eric, > > Please see inline > > > -----Original Message----- > > From: Eric Rescorla <ekr@rtfm.com> > > Sent: Thursday, February 21, 2019 8:33 PM > > To: The IESG <iesg@ietf.org> > > Cc: dots-chairs@ietf.org; frank.xialiang@huawei.com; Liang Xia > > <frank.xialiang@huawei.com>; draft-ietf-dots-requirements@ietf.org; > > dots@ietf.org > > Subject: Eric Rescorla's Discuss on draft-ietf-dots-requirements-18: > (with > > DISCUSS and COMMENT) > > > > This email originated from outside of the organization. Do not click > links or > > open attachments unless you recognize the sender and know the content is > safe. > > > > Eric Rescorla has entered the following ballot position for > > draft-ietf-dots-requirements-18: Discuss > > > > When responding, please keep the subject line intact and reply to all > email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dots-requirements/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Rich version of this review at: > > https://mozphab-ietf.devsvcdev.mozaws.net/D3543 > > > > > > I only had a short time to read this, but I find myself confused about > the > > COMSEC requirements here. > > > > There is no COMSEC requirement for the signaling channel in S 2.2. > > DATA-002 requires a secure COMSEC protocol for the data channel. > > Both signal and data channel require confidentiality and have the same > data privacy and integrity requirements. > Great. That seems appropriate. > > SEC-001 and SEC-002 require "peer mutual authentication" and "message > > confidentiality, integrity, and authentication" according to "industry > best > > practices". This doesn't seem to be a requirement which I can verify or > > evaluate. If "industry best practices" were to use raw TCP, would such an > > implementation be conformant. > > > > I think what needs to be required here is cryptographic authentication > of both > > sides and of the messages on both channels. > > Yes, both the protocols using (D)TLS to mutually authenticate both sides > and the messages on both channels are encrypted. > > > Generally I would prefer to require > > confidentiality on both, but I could maybe see an argument for why that > wasn't > > needed. > > Removed DATA-002 and updated security requirements to discuss > confidentiality for both DOTS protocols. > > SEC-003 Data privacy and integrity: Transmissions over the DOTS > protocols are likely to contain operationally or privacy-sensitive > information or instructions from the remote DOTS agent. Theft, > modification, or replay of message transmissions could lead to > information leaks or malicious transactions on behalf of the > sending agent (see Section 4 below). Consequently data sent over > the DOTS protocols MUST be encrypted using secure transports > (like TLS and DTLS). DOTS servers MUST enable means to prevent > leaking > operationally or privacy-sensitive data. Although administrative > entities participating in DOTS may detail what data may be > revealed to third-party DOTS agents, such considerations are not > in scope for this document. > This looks good. Note that if you are using DTLS, you may need to opt-in to the anti-replay service, as it is optional. > > > > DETAIL > > S 2.2. > > > free to attempt abbreviated security negotiation methods > supported > > > by the protocol, such as DTLS session resumption, but MUST be > > > prepared to negotiate new security state with the redirection > > > target DOTS server. The authentication domain of the > redirection > > > target DOTS server MUST be the same as the authentication > domain > > > of the redirecting DOTS server. > > > > what is an "authentication domain"? > > We are trying to say both the redirecting and redirected target DOTS > server belong to the same administrative domain. > > Modified the last line as follows: > The redirection DOTS server and redirecting DOTS server MUST belong to the > same administrative domain. > How do I interpret this as the redirected party? Does it have to be the same identity in the certificate? Something else? > > S 2.4. > > > SEC-002 Message Confidentiality, Integrity and Authenticity: DOTS > > > protocols MUST take steps to protect the confidentiality, > > > integrity and authenticity of messages sent between client and > > > server. While specific transport- and message-level security > > > options are not specified, the protocols MUST follow current > > > industry best practices for encryption and message > authentication. > > > > This is not a verifiable conformance requirement > > When the requirements draft is initially drafted, the WG wanted to select > the current IETF best practices for encryption and message authentication > of DOTS messages. The DOTS WG has decided to use (D)TLS for signal channel > and TLS for data channel. I can modify the text to say "current IETF best > practices for encryption and message authentication" for both SEC-001 and > SEC-002. > If it 's (D)TLS, then I think you want to cite RFC 7525 here > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > S 2.1. > > > proprietary DDoS defenses. Future extensions MUST be backward > > > compatible. Implementations of older protocol versions MUST > > > ignore optional information added to DOTS messages as part of > > > newer protocol versions. Implementations of older protocol > > > versions MUST reject mandatory information added to DOTS > messages > > > as part of newer protocol versions. > > > > MUST reject the information or MUST reject the messages. > > Conventionally, it's the latter. > > Yes, modified the line as follows: > Implementations of older protocol versions MUST reject DOTS messages > carrying mandatory information as part of newer protocol versions. > Thanks. > > > > > > S 2.2. > > > discussed in [I-D.ietf-intarea-frag-fragile]. If the PMTU > cannot > > > be discovered, DOTS agents MUST assume a PMTU of 1280 bytes for > > > IPv6. If IPv4 support on legacy or otherwise unusual networks > is > > > a consideration and the PMTU is unknown, DOTS implementations > MAY > > > rely on a PMTU of 576 bytes for IPv4 datagrams, as discussed in > > > [RFC0791] and [RFC1122]. > > > > I'm having trouble reading this text. You say above "MUST assume" and > "MAY > > rely" here. Are you saying "send no more than 576" or "you can assume > you can > > send at least 576 and we're not saying anything about the upper bound" > > I have replaced the above lines with the text suggested by Suresh. > OK. > > > > > > S 2.2. > > > active DOTS client has not requested mitigation, in order to > > > control load. > > > > > > Following mutual authentication, a signal channel MUST be > > > considered active until a DOTS agent explicitly ends the > session. > > > During peace time, signal channel MUST be considered active > > > until > > > > "peace time" is probably not the right word here. After all, my country > might > > be at peace but still subject to a DoS attack > > Added the following term to avoid confusion : > Peacetime: In DDoS, ‘peacetime’ refers to the period during which the > target network is not under DDoS attack. > If you must, but I think this is might be considered a little in bad taste by people who are involved in actual wars. -Ekr > Cheers, > -Tiru > > > > >
- [Dots] Eric Rescorla's Discuss on draft-ietf-dots… Eric Rescorla
- Re: [Dots] Eric Rescorla's Discuss on draft-ietf-… Konda, Tirumaleswar Reddy
- Re: [Dots] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [Dots] Eric Rescorla's Discuss on draft-ietf-… Andrew Mortensen
- Re: [Dots] Eric Rescorla's Discuss on draft-ietf-… Konda, Tirumaleswar Reddy
- Re: [Dots] Eric Rescorla's Discuss on draft-ietf-… Konda, Tirumaleswar Reddy
- Re: [Dots] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [Dots] Eric Rescorla's Discuss on draft-ietf-… Benjamin Kaduk