Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 1 Nov 2014 19:40:38 +0000

Just a reminder that this WGLC is in progress and feedback is needed by Nov 3.

Please participate and indicate your support, or lack thereof, for this document.

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, October 26, 2014 6:11 PM
To: [email-masked]
Subject: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

Hi all,

This message starts the (short) DHC working group last call to advance "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-04, document as a Standards Track (Proposed Standard) RFC. The authors believe that this version is ready. We had a WGLC earlier (May 2014 for the -02 version) and there were some comments, so this is primarily to assure that those comments were addressed.

The draft is available here:

http://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6-04

Please send your comments by November 3rd, 2014. If you do not feel this document should advance, please state your reasons why.

There are no IPR claims reported at this time.

Tomek is the assigned shepherd for this document.

- Tomek & Bernie

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 2 Nov 2014 13:47:12 +0000

Hi Bernie,

Is there any reason this needs to be finalized before the IETF91 meeting? I am not
100% certain that the document meets my needs in its current form and was hoping
to have discussion on it at the end of my presentation.

Thanks - Fred
[email-masked]

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Saturday, November 01, 2014 12:41 PM
To: [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, October 26, 2014 6:11 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

Hi all,

- Tomek & Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 2 Nov 2014 15:58:13 +0000

Fred:

This document (and its predecessor) have had a long and rocky journey. It would be nice to finally wrap this up and move on.

If you have significant concerns or feel that functionality is not there that is needed (and couldn't be added later on by a follow-on document), please raise those issues now and on the WG Mailing List - there's little point in waiting until the WG session.

-          Bernie

From: Templin, Fred L [mailto:[email-masked]]
Sent: Sunday, November 02, 2014 8:47 AM
To: Bernie Volz (volz); [email-masked]
Subject: RE: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

Hi Bernie,

Thanks - Fred
[email-masked]<mailto:[email-masked]>

-          Bernie

Hi all,

- Tomek & Bernie

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 2 Nov 2014 21:32:42 +0000

Hi Bernie,

OK, I object to the removal of the client's ability to sign its messages with its own
private key (i.e., so that the server can verify the signature using the client's
public key). Let's talk about it at IETF91.

Thanks - Fred

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Sunday, November 02, 2014 7:58 AM
To: Templin, Fred L; [email-masked]
Subject: RE: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

Fred:

-          Bernie

From: Templin, Fred L [mailto:[email-masked]]
Sent: Sunday, November 02, 2014 8:47 AM
To: Bernie Volz (volz); [email-masked]<mailto:[email-masked]>
Subject: RE: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

Hi Bernie,

Thanks - Fred

-          Bernie

Hi all,

- Tomek & Bernie

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 3 Nov 2014 00:15:12 +0000

Hi, Fred,

This seems a misunderstanding of current draft. The current draft does have the client to sign its messages with its own private key. The certificate of client is actually from the public/private key pair of the client. The client sends public key to authorized CA, out of band normally. The returned certificate contains the original client public key. So, the certificate is still paired with the private key of the client. The message is signed by the client's private key. It is verified by the client's public key (containing within the certificate).

Best regards,

Sheng

________________________________
From: dhcwg [[email-masked]] on behalf of Templin, Fred L [[email-masked]]
Sent: 03 November 2014 5:32
To: Bernie Volz (volz); [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

Hi Bernie,

OK, I object to the removal of the client’s ability to sign its messages with its own
private key (i.e., so that the server can verify the signature using the client’s
public key). Let’s talk about it at IETF91.

Thanks – Fred

Fred:

If you have significant concerns or feel that functionality is not there that is needed (and couldn’t be added later on by a follow-on document), please raise those issues now and on the WG Mailing List – there’s little point in waiting until the WG session.

-          Bernie

Hi Bernie,

Thanks – Fred

-          Bernie

Hi all,

- Tomek & Bernie

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 3 Nov 2014 16:40:37 +0000

Hi Sheng,

I can accept that - thanks for clarifying!

Fred

From: Sheng Jiang [mailto:[email-masked]]
Sent: Sunday, November 02, 2014 4:15 PM
To: Templin, Fred L; Bernie Volz (volz); [email-masked]
Cc: Zhangdacheng
Subject: RE: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

Hi, Fred,

Best regards,

Sheng

Thanks - Fred

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Sunday, November 02, 2014 7:58 AM
To: Templin, Fred L; [email-masked]<mailto:[email-masked]>
Subject: RE: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

Fred:

-          Bernie

Hi Bernie,

Thanks - Fred

-          Bernie

Hi all,

- Tomek & Bernie

---

From: Francis Dupont <[email-masked]>
Date: Mon, 03 Nov 2014 23:13:44 +0100

I reviewed the draft-ietf-dhc-sedhcpv6-04.txt document and I am prepaping
a respond for the list...

Regards

[email-masked]

PS: I reviewed too the stateless document but found nothing important
to signal.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Nov 2014 00:04:45 +0100

draft-ietf-dhc-sedhcpv6-04.txt review:
 - 4 page 5: there is no server authorization. This could be an issue
  but in fact it is something which can't be supported by a booting
  client (i.e., its requires an access to the Internet which is not
  yet available).  So I agree we can give up or postpone it.

 - 4.2 page 6: the algo agility can be inter or intra message. The
 wording "various algorithms simultaneously" is ambiguous when
 it is clearly between messages (i.e., there is one algo used in a
 particular message so the agility applied to two or more different
 messages).

 - 5.2 page 8: add "public key" before certificate (because X.509
  defines attribute certificates too).

 - 5.4 page 10: "fixed-point number" and "in seconds" is not the
  best wording: the second unit applies to the integral part.
  I don't know if we should fix this before the IETF LC.

 - 6.1 page 11: the client must have a certificate ->
  a public key certificate and its corresponding private key.

 - 6.1 page 12: the mandatory algorithms -> one of the mandatory
  algorithms (BTW as there is only one mandatory algo this is not
  a visible change).

 - 6.1 page 12: the behavior on TimestampFail error could be better
  than to go to unsecured mode: the client can use timestamp options
  in messages received from the server to synchronize with it before
  retrying. Of course this requires these messages are validated so
  it can't be specified in a few word... BTW the MAY is still valid,
  it is just not the only option.

 - 6.2 page 13: IMHO the paragraph must be break just before
  "The message that fails authentication check MUST be"

 - 6.2 page 14: I have a question about to add a SHOULD for adding
  a timestamp option in TimestampFail error messages. IHMO there is
  an implicit recommendation to use TS option in responses to queries
  carrying a TS, even there is no TS requested in the ORO...

 - 7.1 page 16: i.e. -> i.e.,

 - 9 page 19: I believe we should remove the SHA-1 from the beginning
  i.e., now. And we have the opportunity to use more state of crypto,
  for instance better RSA signing than RSASSA-PKCS1-v1_5 or to jump
  to ECDSA. Note I propose to keep the current mandatory choice for
  legacy: we should get some advice from a cryptographer...

 - Authors' Addresses pages 22 and 23: RFC 7322 asks the country
  in postal addresses is the ISO IS 3166 two letter code (I believe
  it is an error as this is not what to use in a postal address but
  it seems RFC 7322 (the new RFC style guide) will be enforced before
  it will be fixed...).

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Nov 2014 00:26:31 +0100

In your previous mail you wrote:

>  OK, I object to the removal of the client's ability to sign its
>  messages with its own private key (i.e., so that the server can
>  verify the signature using the client's public key). Let's talk
>  about it at IETF91.

=> the certificate wording in the draft requires some improvements but
a client can sign its messages with its own private key (the server can
verify the signature using the client's public key certificate).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 04 Nov 2014 00:32:55 +0100

I forgot to summary my position about the I-D:
 - I support it for the IETF LC

 - I have no blocking concern (so I shan't object if the current version
  is sent for the IETF LC even IMHO it could be a bit improved before
  so in a new version)

 - I shall support any cryptographer who recommend to change the current
  proposed algo lists (removing weak algos and/or adding better algos).
  Of course it should be easier to get this in the (larger) IETF LC.

Thanks

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 4 Nov 2014 06:16:48 +0000

Hi, Francis,

Thanks for your careful review and support. We will address your comments with other comments during the WGLC and produce an updated version before submission for publication.

Best regards,

Sheng

>-----Original Message-----
>From: dhcwg [mailto:[email-masked]] On Behalf Of Francis Dupont
>Sent: Tuesday, November 04, 2014 7:05 AM
>To: Bernie Volz (volz)
>Cc: [email-masked]
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 10 Nov 2014 04:18:56 -1000

On 26/10/14 12:11, Bernie Volz (volz) wrote:
> This message starts the (short) DHC working group last call to advance
> "Secure DHCPv6", draft-ietf-dhc-sedhcpv6-04, document as a Standards
> Track (Proposed Standard) RFC. The authors believe that this version is
> ready. We had a WGLC earlier (May 2014 for the -02 version) and there
> were some comments, so this is primarily to assure that those comments
> were addressed.
>
Apologies for taking it so long to get this review done.

This is my shepherd's review of this draft.

I did review -04 version of this draft and I support this work moving
forward. I have quite a few comments, but they are easy to fix and
rather editorial in nature.

I rechecked my previous review comments (sent on May 30). Thank you for
addressing them. The only unaddressed comment is about key and cert
rollover. There's nothing to change in how the mechanism is working, but
perhaps you could add a section about rollovers. For clients moving to a
new certificate, it should be pretty easy - once the old one is about to
expire, the client gets a new cert and starts using it. The server will
verify the new signature and it will all work. Updating the server keys
will be trickier. From the client's perspective, probably another leap
of faith would be required. In fact, a server updating its keys would be
indistinguishable from a new rogue server pretending to be the
legitimate one. Anyway, this is something that should be discussed, but
I don't think there's anything you need to do here protocol wise.

The text in section 3 could be improved. It mentions that there are two
key management mechanisms. The first is mentioned immediately
("Firstly,..."), but the second one is mentioned 3 paragraphs further
down. How about this:

  For the hash key function, there are two key management
  mechanisms.  The first one is a key management done out of band,
  usually through some manual process. The second approach is to use
  Public Key Infrastructure (PKI).

  As an example of the first approach, operators can set up a key
  database for both servers and clients which the client obtains a key
  before running DHCPv6. Manual key distribution runs counter to the
  goal of minimizing the configuration data needed at each host.

The next paragraph mentions this: "[RFC3315] provides an additional
mechanism for preventing off-network timing attacks using the
Reconfigure message: the Reconfigure Key authentication method.
However, this method provides no message integrity or source integrity
check.". I disagree. It provides both, but the protection is very weak.

Section 4, first line on page 5. CA is mentioned for the first time, but
the name is explained. Please replace its first use with "Certificate
Authority (CA)".

Section 5.1: Please rename OPTION_PK_PARAMETER to OPTION_PUBLIC_KEY. It
will be more intuitive.

Section 5.2: Please rename OPTION_CERT_PARAMETER to OPTION_CERT.

Section 5.3:
"both signature and authentication option are presented" =>
"both signature and authentication option are present".

Section 5.5 should include a brief introductory text. Maybe the
following would be useful: "The following new status codes are defined.
See Section 5.4 of RFC3315 for details.".

Section 6.1 "The client MAY switch to other certificate if it has." =>
"The client MAY switch to other certificate if it has another one."

The following two sentences contradict each other "But it SHOULD NOT
retry with the same certificate.  It MAY retry with the same certificate
following normal retransmission routines defined in [RFC3315].". Better
way to express the intention would be: "If client decides to retransmit
using the same certificate after receiving AuthenticationFail, it MUST
NOT retransmit immediately and MUST follow normal retransmission
routines defined in RFC3315."

Section 6.2
"multiple Signature option is presented" =>
"multiple Signature options are present".

"If neither of the Signature, Public Key or Certificate options is
presented,". I'm not 100% sure on this one, so I ask a native speaker to
confirm it, but I think that neither means "not one or the other" and
can be used only if there are exactly two alternatives. So it would be
better to say:

"If none of the Signature, Public Key or Certificate options is
present,"

"A fast search index may be created for this list." This is an
implementation detail and I'm not sure if it should be placed in the
draft. But I won't insist if you want to keep it.

"It restores public keys from all trustworthy senders." =>
"It stores public keys from all trustworthy senders."

The text starting with "Furthermore, the node that supports the
verification of the Secure DHCPv6 messages MAY record the following
information:" mentions minbits explicitly, but maxbits implicitly. I
think it would be easier to say something like "The node MAY impose
additional constraints for the verification. For example, it may
impose limits on minimum and maximum key lengths."

Section 6.4:
"After the signature verification also successes" =>
"After the signature verification also succeeds"

Section 6.4 does not mention that the timestamps must be strictly
monotonously increasing. Right now, an attacker can capture a valid
packet and then replay it rapidly as long as the inequality holds.

Section 7. Your refer to the same feature as leap-of-faith, Leap of
Faith and mention its abbreviated form (LoF) multiple times, yet almost
never use LoF on its own. Please make this consistent throughout the
document. Oh, and section 7.1 mentions "Leaf of Faith".

"such as a network cafe" =>
"such as a network in a cafeteria".

Section 8 - I think it would be a good place for a discussion about
key/certs rollovers. See my comments at the beginning of this mail.

Sedhcpv6 deployment has privacy implications. You should discuss them,
even if very briefly. I'm not sure what's the best way to express it.
Maybe saying something that secure clients should not expect any privacy
as they reveal additional information in their certs? That's not a bad
thing, it's just client privacy and client authentication are in
practice mutually exclusive.

Section 9
"This document defines three new ..." =>
"This document defines four new ..." (also three => four) further down
the same paragraph.

Section 10
"IETF DHC working groups". There's only one DHC WG :)

Please replace reference to 5996 with 7296.

Ok, that's it. Even though the number of corrections is significant,
they are all editorial in nature. I strongly support this document
moving forward. Thank you for doing this work. I find it highly useful.

Tomek

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 10 Nov 2014 04:25:59 -1000

On 26/10/14 12:11, Bernie Volz (volz) wrote:
> Please send your comments by November 3rd, 2014. If you do not feel this
> document should advance, please state your reasons why.
Bernie and I discussed this work group last call and consider it
successful. There were couple issues raised, but they are mostly
editorial in nature. One more revision is needed and it will be ready to go.

Authors, please address the comments and upload -05.

Bernie & Tomek

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 10 Nov 2014 17:46:36 +0000

Hi, Tomek,

Thanks so much for careful review and detailed comments. We will integrate them into the new version.

Best regards,

Sheng
________________________________________
From: dhcwg [[email-masked]] on behalf of Tomek Mrugalski [[email-masked]]
Sent: 10 November 2014 22:18
To: Bernie Volz (volz); [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-sedhcpv6-04 - Respond by Nov 3, 2014

Section 5.3:

Section 6.2

Section 6.4:

Section 9

Section 10

Tomek

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 10 Nov 2014 17:49:38 +0000

>Authors, please address the comments and upload -05.

Hi, DHC Chairs,

Thanks for your hard work. We plan to update this document in two or three weeks after the IETF week.

Best regards,

Sheng
________________________________________
From: dhcwg [[email-masked]] on behalf of Tomek Mrugalski [[email-masked]]
Sent: 10 November 2014 22:25
To: Bernie Volz (volz); [email-masked]
Subject: [dhcwg] WGLC summary on draft-ietf-dhc-sedhcpv6-04: Passed

Bernie & Tomek