On Mar 3, 2014, at 12:02 PM, Valery Smyslov sva...@gmail.com wrote:
The draft lists the following trasforms based on AES cipher:
AES-GCM
AES-CCM
AES-CTR
AES-128-CBC
AES-GMAC
AES-XCBC-MAC-96
All these transforms, except for AES-XCBC-MAC-96,
allows to be used with different key lengths
Hi Paul,
The draft lists the following trasforms based on AES cipher:
AES-GCM
AES-CCM
AES-CTR
AES-128-CBC
AES-GMAC
AES-XCBC-MAC-96
All these transforms, except for AES-XCBC-MAC-96,
allows to be used with different key lengths - 128, 192 and 256 bits.
It looks strange to me that,
On 03 Mar 2014, at 17:53 , Paul Wouters wrote:
On Mon, 3 Mar 2014, RJ Atkinson wrote:
ESP-NULL offers the same protection as AH, ...
This sentence above is not true. ESP-NULL and AH provide
different security properties to the IP-layer.
AH protects all IP options, whereas ESP
On Tue, 4 Mar 2014, RJ Atkinson wrote:
What meaning has protecting those bits? Endpoint A and B protect
something by cryptography, but any router in the middle can't trust
those signatures anyway. So I don't see how AH is different from
ESPinUDP where you set those options in the UDP header.
.
- Original Message -
From: Yaron Sheffer yaronf.i...@gmail.com
To: ipsec ipsec@ietf.org
Sent: Tuesday, February 25, 2014 10:48 PM
Subject: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
Hi, this is to start a 2-week working group last call on the revised
Algorithm
Valery Smyslov writes:
The draft lists the following trasforms based on AES cipher:
AES-GCM
AES-CCM
AES-CTR
AES-128-CBC
AES-GMAC
AES-XCBC-MAC-96
All these transforms, except for AES-XCBC-MAC-96,
allows to be used with different key lengths - 128, 192 and 256 bits.
It looks strange to
On Mon, 3 Mar 2014, Tero Kivinen wrote:
Hmm... actually we should most like use the same names we use in the
IANA registry. For example we have 3 different types of AES-GCM:
18 AES-GCM with a 8 octet ICV[RFC4106] [RFC5282]
19 AES-GCM with a 12 octet ICV [RFC4106] [RFC5282]
20
On Mon, 3 Mar 2014, RJ Atkinson wrote:
ESP-NULL offers the same protection as AH, ...
This sentence above is not true. ESP-NULL and AH provide
different security properties to the IP-layer.
AH protects all IP options, whereas ESP cannot protect any
IP options that appear prior to
HI Tero,
Hmm... actually we should most like use the same names we use in the
IANA registry.
Agree, this would make things more clear.
I think the best is to say that in general with AES encryption (GCM,
CBC, CCM etc) we assume the key length is 128-bits. (i.e. the
And don't forget
Yaron Sheffer writes:
+1 on making single-DES CBC a MUST NOT.
Agree on that. (And I still need to read the whole document, I am way
too much behind with my IPsecME WG draft reading).
--
kivi...@iki.fi
___
IPsec mailing list
IPsec@ietf.org
(Hats off)
+1 on making single-DES CBC a MUST NOT.
Yaron
Why is DES-CBC a SHOULD NOT+ instead of a MUST NOT? Is there any sane
modern IKE daemon that allows 1DES (or modp768)
The WG has never voiced a MUST NOT for this before. I'm fine with making that
change if no one objects.
On Wed, 26 Feb 2014, Valery Smyslov wrote:
It is for systems that don't implement AH. We should probably say this
explicitly in section 3.
I don't think it is limited for those systems only.
You may implement AH, but yon cannot use it
everywhere, as it is not compatible with NATs.
And
Paul,
On Feb 25, 2014, at 8:48 PM, Yaron Sheffer yaronf.i...@gmail.com
wrote:
Hi, this is to start a 2-week working group last call on the revised
Algorithm Implementation Requirements
document, ending March 11. The draft is at:
http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01.
Paul,
On Wed, 26 Feb 2014, Valery Smyslov wrote:
It is for systems that don't implement AH. We should probably say
this explicitly in section 3.
I don't think it is limited for those systems only.
You may implement AH, but yon cannot use it
everywhere, as it is not compatible with NATs.
And
Hi, this is to start a 2-week working group last call on the revised
Algorithm Implementation Requirements document, ending March 11. The
draft is at:
http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should
have last called the draft a while ago, and I apologize for the delay.
On Feb 25, 2014, at 8:48 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
Hi, this is to start a 2-week working group last call on the revised
Algorithm Implementation Requirements
document, ending March 11. The draft is at:
On Feb 25, 2014, at 3:09 PM, Paul Wouters p...@cypherpunks.ca wrote:
On Feb 25, 2014, at 8:48 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:
Hi, this is to start a 2-week working group last call on the revised
Algorithm Implementation Requirements
document, ending March 11. The
Hi Paul,
It lists NULL ESP as a MUST. Wasn't this a MUST a leftover from the old
crypto export restrictions? While I think NULL ESP is a good debugging
tool, and a good replacement for AH in general, I don't think this is
really a MUST item (unless you would actually advise people to migrate
18 matches
Mail list logo
