On Mon, 9 Dec 2013, Phillip Hallam-Baker wrote:
At any rate, I think the point is made sufficiently that NULL ciphers in legacy
suites do not represent a policy precedent against the
PERPASS work.
I think that calling something NULL ENCRYPTION is pretty clear. There
are clear testing and benchmark reasons to keep these. However, to bring
this back to perpass focus, it _is_ our job to ensure these proposals
are never picked automatically, or are ever part of a "default set" or
proposals that are valid.
Speaking for libreswan, we only allow it when configured specifically
using, eg esp=null-md5 and even then we issue a warning:
# ipsec auto --up westnet-eastnet-null
104 "westnet-eastnet-null" #1: STATE_MAIN_I1: initiate
003 "westnet-eastnet-null" #1: received Vendor ID payload [Dead Peer Detection]
003 "westnet-eastnet-null" #1: received Vendor ID payload [FRAGMENTATION]
106 "westnet-eastnet-null" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "westnet-eastnet-null" #1: STATE_MAIN_I3: sent MI3, expecting MR3
003 "westnet-eastnet-null" #1: received Vendor ID payload [CAN-IKEv2]
004 "westnet-eastnet-null" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_RSA_SIG cipher=aes_128 prf=oakley_sha group=modp2048}
117 "westnet-eastnet-null" #2: STATE_QUICK_I1: initiate
003 "westnet-eastnet-null" #2: You should NOT use insecure/broken ESP
algorithms [ESP_NULL (0)]!
004 "westnet-eastnet-null" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel
mode {ESP=>0xESPESP<0xESPESP xfrm=NULL_0-HMAC_MD5 NATOA =none NATD=none DPD=none}
That said, I think it is more much more important to ensure we get rid
of algorithms people still use not being aware their strength is as
good as NULL. We still cannot remove 1DES code from our tree because it
will break "legitimate" deployments. As an opensource vendor, we have
subverted these to be compile-time options (default off), and tell
vendors not to enable that compilation option.
As for whether we should move AH, Transport Mode, Compression,
Narrowing, MD5, and other IPsec ideas to historirc, that is probably
better discussed on the ipsecme list.
Paul
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
