Re: [dhcwg] DHCP hackathon in Prague: SeDHCPv6

Bernie addressed the key issue.   I think Bernie's suggestion is fine, but sounds a lot like DTLS, which begs the question, why not just use DTLS?   And Francis, much as we might wish it otherwise, IPsec isn't actually a practical option as far as I can tell.  I have no idea how to use it for anything other than setting up a VPN on, e.g., Mac OS X.   If you have a resource to point to on that, I'd be interested to hear about it.

> On Jun 7, 2017, at 2:35 PM, Francis Dupont <Francis.Dupont@fdupont.fr> wrote:
> 
> In your previous mail you wrote:
> 
>>> => it is more than a fundamental issue: the idea to use RSA encryption
>>> is simply a deadly bad one...
>> 
>> Could you explain it in more detail?  Is it just about the particular
>> choice of algorithm (RSA), or is it about the use of asymmetric
>> (public-key)-based encryption to encrypt DHCPv6 messages in the first
>> place?  And why is it bad?
> 
> => in fact it is both because RSA is the only asymmetric algorithm
> which provides an accepted encryption feature.
> Now why it is bad (other than RSA has no future)? Just because it was
> designed to protect something short as a key for a symmetric encryption
> and *not* for a message with an unbound length.
> 
>> If it's the former, (depending on the reason) we might choose a better
>> algorithm as the default/mandatory.
> 
> => as I explained I am afraid there is no alternative which went further
> than conference papers...
> 
>> If it's the latter, we could revise the protocol so it will first
>> negotiate a symmetric session key using public-key based encryption
>> and use the session key for subsequent DHCPv6 message exchanges.  That
>> will be a quite substantial change from the current spec, but I guess
>> it's not impossible.
> 
> => if you go to a key agreement phase followed by symmetrical encryption
> I am afraid you are reinvented something which already exists so why
> not investigate current possible solutions and try to use them directly?
> 
>>> Perhaps we should drop it and restart from the beginning about
>>> address assignment security, for instance using opportunistic DNSSEC
> 
> => oops? I wrote DNSSEC? I wanted to mean IPsec.
> 
>>> with a client embedded first relay? At least it does not need to
>>> develop a new protocol...
> 
> Regards
> 
> Francis.Dupont@fdupont.fr
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg