Subject: [Hipsec] WGLC: draft-ietf-hip-cert-06

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 5 Dec 2010 17:51:10 +0200

Folks,

we hereby start the WGLC on the following draft. This WGLC will end on
December 20th.

https://datatracker.ietf.org/doc/draft-ietf-hip-cert/

Please, send your comments to this list.

Thanks,

Gonzalo
HIP co-chair

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 16 Dec 2010 21:07:50 +0200

Hi,

note that you still have a few days to send your comments if you have some.

Cheers,

Gonzalo

On 05/12/2010 5:51 PM, Gonzalo Camarillo wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec
>

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 19 Dec 2010 20:01:32 -0800

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> Sent: Sunday, December 05, 2010 7:51 AM
> To: HIP
> Subject: [Hipsec] WGLC: draft-ietf-hip-cert-06
>
> Folks,
>

Gonzalo, I reread this draft and feel that it is ready to publish, modulo the resolution of a couple of comments below.

At the top of page 6, I believe that the line
    Subject: CN=hit-of-issuer
should read
    Subject: CN=hit-of-subject

In section 8, the second paragraph recommends to not use grouping or hash and URL encodings when HIP aware middleboxes are anticipated to be on the path.  First of all, it is not really clear how a HIP host may know about these boxes except via side information.  If the HIP host does know about them, then presumably it could also know (via side information) whether they can support grouping and hash formats, and the host could act accordingly.  Second, it is not clear whether the use of these options by a well-behaved host would make these devices more prone to attacks, or whether it is rather the use of these options by other malicious hosts that is the real problem.  It seems to me that it may be better to defer this issue to a future HIP-aware middlebox draft, where it could be specified, for instance, how a middlebox that does not want to support these formats may signal to a host that it requires "full credentials" to proceed.  So, I would like to suggest for your consideration to remove this paragraph.

- Tom

---

From: Samu Varjonen <[email-masked]>
Date: Mon, 20 Dec 2010 12:53:34 +0200

>      Subject: CN=hit-of-subject

OK, fixed

> In section 8, the second paragraph recommends to not use grouping or hash and URL encodings when HIP aware middleboxes are anticipated to be on the path.  First of all, it is not really clear how a HIP host may know about these boxes except via side information.  If the HIP host does know about them, then presumably it could also know (via side information) whether they can support grouping and hash formats, and the host could act accordingly.  Second, it is not clear whether the use of these options by a well-behaved host would make these devices more prone to attacks, or whether it is rather the use of these options by other malicious hosts that is the real problem.  It seems to me that it may be better to defer this issue to a future HIP-aware middlebox draft, where it could be specified, for instance, how a middlebox that does not want to support these formats may signal to a host that it requires "full credentials" to proceed.  So, I would like to suggest for your cons
id
>   eration to remove this paragraph.
>

I agree with the comment and agree on leaving the subject to a future draft on 
HIP-aware middleboxes. Anyone against the removal of the paragraph? If not 
consider it removed.