Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-07

["Zimmer, Vincent" <[e-mail]>]

Yes.   There are a plurality of security considerations possibly.   Given the state of DHCP security and our attempt to have some behavior parity with IPV4 netboot, we were not intending exhaustive treatment of this subject area.

You are correct Thomas that HTTP-S was added based upon the suggestion of a Lucent engineer during IETF74 dhc session in SF as a possibility.   

>From the UEFI perspective, we prefer the following approach as described in the draft:

   or that the boot loader
   implementation implement a mechanism for signing boot images and a
   configurable signing key in memory, so that if a malicious image is
   provided, it can be detected and rejected.

to address issues of a DHCP hijacking or other MITM attacks.

Vincent


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Thomas Huth
Sent: Sunday, December 27, 2009 3:14 AM
To: Alfred Hönes; [e-mail]
Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-netboot-07

Hello Alfred!

Sorry for the late reply, but I got a lot of holiday stress
recently ... ;-)

Alfred Hönes <[e-mail]> wrote on 22/12/2009 14:47:56:

> (1) Major issue:
>   Confusion about URIs, IRIs, and URLs, and appropriate charsets.
>
> The draft is inconsistent in the use of "URL" vs. "URI".
> If it really wants to use URIs, it should use the more modern
> term, and not "URL".

Actually we really mean URL, not URI, since IMHO it does not make too much
sense to boot from a URN.

> Per STD 66 (RFC 3986) URIs per definition are tied to the US-ASCII
> charset.  You specify UTF-8 for the "boot-file-url" field.

That's also what I've originally thought and we had this in an older
version of our draft, but Ted Lemon told us to use UTF-8 instead:

http://www.ietf.org/mail-archive/web/dhcwg/current/msg10165.html

Ted, any comments on this?

> That does not make sense.  Even if you have an IRI (represented in
> UTF-8), it would have to be converted to US-ASCII, according to
> RFC 3987, before it can be handed out as a URI (or "URL").
> If you really want to use IRIs instead (PS so far, subject to
> revision), you can stay with UTF-8, but **please** refrain from
> calling them "URL", and rename all fields and code point identifiers
> to clearly say so.

I think we should not use IRIs here. I guess most firmware implementations
do not have a full blown i18n implementation and if I've got RFC3987 right,
HTTP also does not work well with IRIs:

"On the other hand, in the HTTP protocol [RFC2616], the Request URI is
defined
 as a URI, which means that direct use of IRIs is not allowed in HTTP
requests."

So I think we should stay with URLs in our draft.,

> (2)  Issue: Unrealistic text in Security Considerations
>
> Section 7, in its last paragraph, contains an allusion to HTTPs usage.
> Is that, realistically, an option in a Boot ROM environment???
> Serious use of HTTPS includes certificate and certificate path
> validation, online CRL lookup, or OCSP or SCVP usage, etc.
> Where should the necessary trust anchors come from at the Boot ROM
> level?

I think this is just a matter of firmware implementation. If somebody has
really need for this, it can be implemented in firmware, too.>
And IIRC, HTTPS for booting has been suggested by someone at the IETF 74
meeting in San Francisco, so there seems to be real interest in this topic
(I wasn't there at that meeting, so maybe one of the attendees can say
something about this? Vincent?)

> (3) General textual issue: length field descriptions
>
> There seems to be textual confusion between the length of a field
> and the (overall) length of a DHCP option, with much verbiage added
> with the apparent intent to clarify the (IMO) improper terms used.
> The length field of a DHCPv6 Option generally specifies the length
> ot the option value.  If the option value consists of a single data
> field, the shortmost and most precise phrase possible would be to
> simply say so for the length.  Using positive language enumerating
> what is included seems to be much more clear and preferable over
> using "subtractive" notion.

Ok... I thought some explicit words might help here to make it easier to
read, but if people prefer it more condensed, that's fine for me, too. So
has anybody else any thoughts on this?

> (4)  more editorial nits
>
[...]

Ok, thanks for spotting these! I will correct them with the next update.


Mit freundlichen Grüßen / Kind regards,
   Thomas Huth
                                                                           
    IBM Deutschland                 Vorsitzender des Aufsichtsrats:        
    Research & Development GmbH     Martin Jetter                          
    Schönaicher Str. 220            Geschäftsführung: Dirk Wittkopp        
    71032 Böblingen                 Sitz der Gesellschaft: Böblingen       
    Tel.: [phone]          Registergericht: Amtsgericht           
                                    Stuttgart, HRB 243294                  
                                                                           


_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg