Subject: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-16.txt

From: [email-masked]
Date: Tue, 18 Oct 2016 20:40:49 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration of the IETF.

        Title           : Secure DHCPv6
        Authors         : Sheng Jiang
                          Lishan Li
                          Yong Cui
                          Tatuya Jinmei
                          Ted Lemon
                          Dacheng Zhang
	Filename        : draft-ietf-dhc-sedhcpv6-16.txt
	Pages           : 29
	Date            : 2016-10-18

Abstract:
   DHCPv6 includes no deployable security mechanism that can protect
   end-to-end communication between DHCP clients and servers.  This
   document describes a mechanism for using public key cryptography to
   provide such security.  The mechanism provides encryption in all
   cases, and can be used for authentication based on pre-sharing of
   authorized certificates.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-sedhcpv6/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-sedhcpv6-16

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 19 Oct 2016 14:44:43 +0000

BTW:

I haven’t looked into it myself, but I wonder whether having a
“compressed” certificate is possible (i.e., using the LZ or similar
compression (perhaps zlib) on the certificate)? Perhaps the certificates
are already in some kind of compressed format?

There’s also an interesting question whether compressing the entire DHCPv6
message before encrypting it has any value? That might also avoid the need
for a compressed certificate.

The cost to doing this (cpu and code) would likely be fairly minor, but it
could avoid generating (as many) fragments on the network.

- Bernie

On 10/19/16, 10:04 AM, "Bernie Volz (volz)" <[email-masked]> wrote:

>
>-----Original Message-----
>From: dhcwg [mailto:[email-masked]] On Behalf Of
>[email-masked]
>Sent: Tuesday, October 18, 2016 11:41 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [dhcwg] I-D Action: draft-ietf-dhc-sedhcpv6-16.txt
>
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Lishan Li <[email-masked]>
Date: Thu, 20 Oct 2016 00:13:46 +0800

The size of certificate is not very large.
The reason of changing one cert to multiple certs is that: Once the
AlgorithmNotSupported error status code, the server has to encrypt the
message with the mandatory encryption algorithm. So the certificate with
the mandatory algorithm should be contained. So the number of the contained
certificates is just a little.
Randy and Stephen have reviewed this draft and did't not propose this
problem. For this problem, maybe we can ask for their comments.

Best Regards,
Lishan