Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th

Lishan Li <lilishan48@gmail.com> Fri, 21 April 2017 08:26 UTC

Return-Path: <lilishan48@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7689B1288B8; Fri, 21 Apr 2017 01:26:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8IRN4U42FqI6; Fri, 21 Apr 2017 01:26:46 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 A9F2E129440; Fri, 21 Apr 2017 01:26:17 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id y33so64445375qta.2; Fri, 21 Apr 2017 01:26:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QWKIHdudejqgyxkcdtojXY3x8kuf/dRZ1QFwvEtPz3Q=; b=E5rsgV+x62zFDVR7bEDUZECIK7n7PRiV0Edq1xTCL4vf4EjTLlch/I0UWnSau0NWlm tvy+wCdK2VSenILDzuQ5wFdnmB83jNMdDaPS0UdmTLQBiqIRNbYzQ1HRhzTvjElmLuVb V7zeUw7wh1iYQMqMsId9E+cVPQtX7BtkRRdnQ/wRUZIOJ0leRZ3EzVEoadgxJrAaLuI8 nsBCvoyxk1/dma5JiHbWIQCBFJTHTCaEWScTcpM1d/BPZF6WRrdQtvrMmKN6yq/+WFqm 6J7s2sRXoSddVqhUoT4RwgdX8lfQpNQYqBZtdmN4IvVaRCqO3JAnXOWbyb2aSbgmMst+ KVjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QWKIHdudejqgyxkcdtojXY3x8kuf/dRZ1QFwvEtPz3Q=; b=h0eMotX0YoV/jJowHLcWBMOeh/2xxFu8j9geZv4oBKztBCt/ibfqKEqpL3yKoicDdY +j6Ls3+xTHpO5X1GMhQYkEPvbLTaCl7smYysys/wtr5bbKlkZlH77uQwm4MWVhsbl4Ov bkikawJG/wbAwxVr7jo70vuHgtwvZAymxTAqykWwVqfCZUp+TbUzTFJk8kPsN7lJpxHQ JMmULolPJckAdO4xclqopglnSaHtYor9wf5DhqogWS85yq8n3WlTVokzAK/akxREYTta fPkyG+A1OIOssY+mV3QsWp59+1BQv3+u0wbmDfKGyZe9HWgCJeM6NZ+tNvUo2RzERSoK UPUw==
X-Gm-Message-State: AN3rC/7uUgig+7mdcISZYvLYLHaY6+l31jbWxsacA9wFx8t/BDJi0Ic/ x7ORDZ1KlOYfvtKujUy6sn1Ihu7G/w==
X-Received: by 10.237.34.22 with SMTP id n22mr11699171qtc.164.1492763176824; Fri, 21 Apr 2017 01:26:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.58.71 with HTTP; Fri, 21 Apr 2017 01:26:16 -0700 (PDT)
In-Reply-To: <a53a101c-6eb9-b212-4359-e2e06e7c125b@gmail.com>
References: <e08be0f6-f1b4-4f57-6cdf-ddd546f8b793@gmail.com> <ddd19ddb52084e9cbdbc035d07888c28@XCH15-06-08.nw.nos.boeing.com> <a53a101c-6eb9-b212-4359-e2e06e7c125b@gmail.com>
From: Lishan Li <lilishan48@gmail.com>
Date: Fri, 21 Apr 2017 16:26:16 +0800
Message-ID: <CAJ3w4NcJTBd=tJ9=tEqOvA9e7pPyz1D0DNN7QDbdNp_dZ2hh6Q@mail.gmail.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Cc: "Templin, Fred L" <Fred.L.Templin@boeing.com>, dhcwg <dhcwg@ietf.org>, draft-ietf-dhc-sedhcpv6 authors <draft-ietf-dhc-sedhcpv6@ietf.org>
Content-Type: multipart/alternative; boundary=001a113e49b8e37764054da9020b
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/VVQt08PeUu3lU44aDkvqHj-RrF0>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-sedhcpv6-21 - Respond by March 29th
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Apr 2017 08:26:49 -0000

Hi, Tomek,

Thanks a lot for the valuable comments. Sorry for the late reply. For some
general issue, I will start a new session for discussion. For the other
easy issues, please see inline.

Best Regards,
Lishan

2017-03-31 2:00 GMT+08:00 Tomek Mrugalski <tomasz.mrugalski@gmail.com>;:

> I have reviewed the draft and in my opinion -21 is in great overall
> shape. The text reads so much better, the concept is clearly explained
> early and the whole text fits together well. I do have many comments,
> but great majority of them are clarifications and editorial corrections.
> Good work, authors!
>
> Ok, let's start with easy ones.
>
> idnits. There are a number of idnits errors and warnings: 3 errors (**),
> 0 flaws (~~), 8 warnings (==), 5 comments (--).. Please fix them. Ping
> me off the list if you need a little help with idnits tool.
>
> This draft defines a set of recommendations for secure environment. It
> is not expected to be used by all DHCP implementations is every
> deployment, just those who are interested in improved security. In
> certain way it is very similar to anonymity profile. Anonymity profile
> defined set or rules that are not expected to be used by all DHCP
> implementations in every deployment, just those who are interested in
> improved privacy. So maybe it should be called Security Profile for
> DHCPv6? I think this approach does not change anything from technical
> perspective, but simply frames the solution better. Described that way
> it may also be easier to accept to people who may afraid we want to
> force everyone to encrypt everything everywhere. It's just a suggestion
> to consider, I don't insist on it if authors or the WG disagree.


> I like section 5, especially 5.1 and 5.2 a lot. It's a great two-page
> intro to the concept.
>
[Lishan]: Ted rewrite the text of Section 5.1 and 5.2. So it is clear
and easy to read.

>
> Section 6: Is Advertise protected as well? I think it definitely should
> be to the maximum extent possible. Once the initial info-request/reply
> is completed, the next step for the client is to send Solicit wrapped in
> Encryption-Query. The server will reply with Advertise wrapped in
> Encryption-Response. At this stage the received Advertise can be
> validated. Maybe not all of the checks are possible yet for Advertise,
> because of not all necessary information is available yet (e.g. there's
> not possible to do the increasing number check as this is the first
> packet coming back and the client doesn't have previous value to check
> it against), but some checks are definitely applicable (e.g. drop
> because signature is missing, multiple signatures or certificate missing).
>
[LS]: The increasing-number option is first sent by the Reply message.
And the client checks it. If the client does not store it, then we assume
that the initial value is zero, then the check will success.

>
> Unless there's a good reason to not do it, the rules described in on
> page 9 should apply to both Advertise and Reply.
>
> "beat out a busy "real" server" => "beat out a busy legitimate server"
>
> There is this text: "The Certificate option MUST be constructed as
> explained in Section 10.1.2.", but I don't see any "client MUST send
> Certificate option". It's also not shown on Figure 1. Yet, the server
> section says that incoming messages without Certificate option are to be
> dropped. This should be clarified.
>
[LS]: Will clarify it.

>
> It's a matter of preference, but I think Section 6 is too long and
> should be split into several sub-sections. When someone references it
> ("see Section 6"), it's difficult to find what specific parts of the
> text is being pointed out to.
>
[LS]: Agree.

>
> "the subsequent encrypted DHCPv6 message sent from the client can also
> contain the Increasing-number option to defend against replay attack.".
> Is there a reason why "can" is used, not SHOULD or even MUST?
>
[LS]: Increasing-number is optional. change "can" to "SHOULD".

>
> "If the transaction-id is 0, the client also try to decrypt it." Two
> comments about this. First, what is the client supposed to decrypt - the
> transaction-id field or the whole message? Second, what should the
> client do if it's not 0?
>
[LS]: The client will not check the transaction-id. For all the
transaction-id,
the client will try to decrypt it.

>
> "In this document, it is assumed that the client will not have multiple
> DHCPv6 sessions with different DHCPv6 servers using different key pairs
> and only one key pair is used for the encrypted DHCPv6 configuration
> process." That's a good text, but it doesn't belong in the place where
> it is now. It should be moved to separate paragraph or even separate
> section. You may also consider adding something like "Secure DHCPv6 can
> maintain multiple DHCPv6 sessions, but such scenario is not considered
> here for clarity reasons."
>
[LS]: Agree.

>
> "The encryption text SHOULD...". What is encryption text? Did you mean
> encrypted message or the message to be encrypted?
>
[LS]: I mean the encrypted text. Will explain it more clear.

>
> nit: "as explain in [RFC5652]" => "as explained in [RFC5652]"
>
> "After the decryption, it handles the message as per 3315". I'm not a
> security expert by any stretch of that word, so excuse my naive
> question. Anyway, can you always detect that the decryption was a
> success or failure? Some decryption techniques will produce output, even
> when the key is incorrect, but the output will be an almost random
> garbage. Can the mechanism defined in RFC5652 always reliably conclude
> the decoding operation was success/failure? If not, I'm afraid that
> asking clients and server to decode random garbage will break some
> implementations.
>
[LS]: I also don't know much about it. For the general security issues,
will consult Randy Bush or Stephen Farrall for their guidance.

>
> If the decryption algorithm cannot give definite success/fail answer,
> there's a solution I have in mind. You may add a magic cookie (a well
> known value of perhaps 4 bytes) at the beginning before encrypting the
> actual message and encrypt (cookie,message) tuple. Then the first check
> after decryption the receiver would do is to check if the first 4 bytes
> match the cookie value. If not, then throw away the whole packet without
> trying to parse any of it. I discussed the concept with Bernie and he's
> in favour of it. Also discussed with Jinmei and he's against it. Sten
> posted his comment against it, but I'm not sure if Bernie's description
> of the concept was accurate enough. Any other thoughts on this?
>
[LS]: I think it is a general secure issue. And we can consult some
security
expert.

>
> "switch to other DHCPv6 server if it has another one." => "switch to
> other DHCPv6 server if available."
>
> The text uses "one and only one" several times. You may consider
> replacing it with "exactly one". It reads easier that way, but I admit
> it's a matter of preference, so it's just a suggestion.
>
> "The DHCPv6 server drops the message that is not for it, thus not paying
> cost to decrypt messages."
> => "The DHCPv6 server drops the message if the value of Server
> Identifier option does not match its own, thus not paying the cost of
> message decryption."
>
> "If the server cannot find the corresponding private key of the key tag
> or the corresponding private key of the key tag is invalid for
> decryption, then the server drops the received message." Shouldn't the
> server send back AuthenticationFail status? The benefit is that the
> client could try again and use a different certificate.
>
[LS]: In these scenarios, decryption fails. In this way, the server cannot
recognize which client. And it is difficult for the server to send the
AuthenticationFail
status code.

>
> "For the signature failure, the server SHOULD send an encrypted Reply
> message with an UnspecFail (value 1, [RFC3315]) error status code to
> the client." Why use UnspecFail, if there's SingatureFail code for it?
>
> General comment: "cert" should be replaced with "certificate". Even
> though everyone understands this jargon, it should be avoided in formal
> documents.
>
> Section 9.1:
> nit: "The server should keep a record of the increasing number forever."
> Nothing is eternal, so I don't like the word forever. It would be better
> to say the server must be able to retain the increasing number across
> restarts.
>
> Remove "And " at the beginning of two sentences in first paragraph.
>
> Section 9.2:
> Thanks a lot for including the code. It's very helpful. However, please
> update the comments that mention RDATA, DNSKEY RR and RDLENGTH. That way
> fewer people will realized where it was borrowed from :)
>
> Nit: some of the values to be assigned by IANA are boilerplated as
> TBD[number] and some as TBA[number]. Typically it's TBD[number].
>
> Section 10.1.1
>
> The text describing EA-id List could use an update. First, it's not
> clear what EA stands for (it is explained further down, but requires a
> bit of hopping around the text). I would replace "EA-id: The format of
> the EA-id List field is shown in Figure 3." with "EA-id List: Contains a
> list of supported Encryption Algorithm identifiers. The format of the
> EA-id List field is shown in Figure 3." Similar text should be added for
> SHA-id List ("Contains a list of supported Signature/Hash Algorithm
> pairs.").
>
> [LS]: Bernie has given the same comments. Will modify it.

> Nit: I'm not sure, but it looks like you put the whole description of
> EA-id into the Figure 3. It's better to have it as text outside of
> Figure. That's probably also one of the reasons why idnits is unhappy.
>
> 10.1.2
> "The Certificate option carries the certificate of the client/server,
> which is contained in the Reply message." This is confusing. I could
> easily misinterpret this as "server is supposed to send client
> certificate in Reply message" or even "Client can send Reply message
> with a certificate". It would be better to say "The Certificate option
> carries the certificate of the sender. It can be included by the client
> (see Section 6) and by the server (see Section 7)." Also, see my earlier
> comment about Section 6 not explicitly saying if/when the Certificate
> option is to be sent.
>
> Sections 10.1.*
> As a convenience to the reader, I would add a text similar to "The
> Algorithm option is sent by the client, as described in Section 6.".
> Similar texts should be added in other sections that describe the
> options. It can be confusing to understand who sends what, so such
> pointers are useful in my opinion. This applies to all sections that
> describe options.
>
> Section 10.2
> "share the following format:" => "share the standard format of DHCPv6
> messages:".
>
> Section 11
> "There are some mandatory algorithm for encryption algorithm in this
> document.  It may be at some point that the mandatory algorithm is no
> longer safe to use." => "There are some mandatory algorithms specified
> in this document.  It may be at some point that the mandatory algorithm
> is no longer safe to use. To mitigate this problem, an extension
> mechanism was defined that allows usage of new encryption, signing and
> hash algorithms."
>
> Another problem that should be mentioned is that secure traffic cannot
> be snooped by the relay agents. This is of crucial importance for
> networks that use PD and use relay snooping. It would be even more
> appropriate to create separate section called Deployment Considerations
> for it. If the RAAN draft is resurrected before sedhcpv6 reaches IESG
> (it should), adding text similar to "This issue will be addressed in
> future IETF work and add reference to
> draft-ietf-dhc-dhcpv6-agentopt-delegate).
>
[LS]: After the IETF meeting, we will add the reference of it.

>
> Another possible topic for discussion in deployment considerations would
> be how to do Rebind. My understanding is that it would work as long as
> both servers would use the same certificates. This explanation is buried
> deep in section 5.4, but it's probably useful to mention it explicitly
> (or have a pointer to 5.4) if you decide to create deployment
> considerations section.
>
[LS]: Will have a pointer to 5.4

>
> Section 12
> Do you (that's a broad question to the WG, not just authors) think it
> would be useful to add extra column to the new registries, specifying
> whether the protocol is mandatory, optional or deprecated? We would
> start with one mandatory in each registry and all other entries being
> optional. When new protocols are defined in the future and flaws in
> existing ones are discovered, we could publish short documents to easily
> update the current state of affairs. It would also correlate well with
> the text you have in section 11.
>
[LS]: Agree.

>
> I agree with Jinmei-san that the Confirm message problem is something
> that should be tackled. I don't have any ready to use solution for you,
> but going in the direction that Jinmei suggested (doing separate
> inf-request/reply to discover available servers) seems the best way.
>
[LS]: Will discuss it in another session.

>
> Finally, to answer my own question I think dhc-dhcpv6-agentopt-delegate
> should be resurrected right now, so sedhcpv6 could reference to it, when
> it discusses the issue with snooping. This is something I hope to
> discuss in couple hours during meeting.
>
>
> Thanks again,
Lishan