Re: [Cfrg] request for review of IPsec ESP and AH Usage Guidance

[David McGrew <[e-mail]>]

Hi Yoav,

thanks for sharing your thoughts, more inline:

On Tue, 2013-07-02 at 15:18 +0000, Yoav Nir wrote:
> On Jul 2, 2013, at 5:31 PM, David McGrew <[e-mail]> wrote:
> 
> > Hello CFRG,
> > 
> > Yaron, Paul, Wajdi, and I are interested in your input on the "Usage
> > Guidance" section in "Cryptographic Algorithm Implementation
> > Requirements and Usage Guidance for Encapsulating Security Payload
> (ESP)
> > and Authentication Header (AH)".   This is an active standards-track
> > draft in the IPsec working group, which updates the ESP and AH
> algorithm
> > requirements (RFC 4835).  The usage guidance section is new, and it
> > offers advice on how to use ESP and AH to achieve cryptographic
> security
> > goals.  
> > 
> > Quick link:
> >
> http://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/?include_text=1
> > 
> > thanks,
> > 
> 
> Hi David.
> 
> You've heard these before, but I'll repeat them since you're asking
> for comments on this list.
> 
> - I'm concerned that the only encryption algorithm is AES. 

this is a valid concern, but in my opinion, it is a long-term concern,
not a short-term one.   That is, we should think about AES alternatives,
but we likely have enough time that we can use an orderly process like
the one we described in  
http://tools.ietf.org/html/draft-mcgrew-standby-cipher-00  

> Yes, I see that TripleDES-CBC as a MAY, but that is by now the past.
> AES-128-CBC is 9 times the speed of 3DES (on an Intel platform without
> AES-NI based on "openssl speed"), and with AES-NI the ratio is likely
> to jump to 20. 

So Triple-AES should be acceptable to everyone.  (Just joking!)

> With GCM it's even more pronounced. So 3DES cannot be a reasonable
> alternative to AES. I think we should have some alternative that is at
> least at the SHOULD level.
> 

So, I agree that thinking about alternatives is a reasonable use of our
time.   

As an aside, I feel like we have been forced into a situation where we
are focusing on block cipher designs (AES vs. Camellia vs. SEED ....)
which is quite out of touch with modern crypto design, where the focus
is on higher-level constructs like authenticated encryption.  For
instance, the current activity in crypto design competitions is the
CAESER authenticated encryption "contest":
http://competitions.cr.yp.to/caesar-call-3.html     

> - I'm not sure what the point is of the MAY level. We MAY implement
> anything: SEED, Camellia, GOST. That doesn't help with
> interoperability

This is a valid point.   It would be reasonable to strip out all of the
"MAY implement" algorithms.   The reason for including them in the draft
is the fact that RFC 4835 and its predecessors (on which this draft is
based) specified some MAY implement algorithms, and also we felt like it
would be good to describe the status of "demoted" algorithms like
AES-CTR [RFC3686] in the draft, since they were mentioned in the earlier
version.   I am fine with removing the MAYs, as long as it reflects the
consensus of the working group (I don't want to have to change it back
later if there is a chorus of objection ;-)

> 
> - I'm not sure about AES-GMAC for ESP authentication. Is there a
> reason why someone would prefer to use AES-CBC or AES-CTR with
> AES-GMAC rather than AES-GCM? 

I don't think so.  

> Also, the HMAC-SHA256 algorithm has gained popularity recently
> (meaning that a lot of customers are asking for it). It runs
> significantly slower than HMAC-SHA1,

Yeah, and it looks even slower next to GMAC.

>  but people have stopped reading at "SHA-1 is no longer secure".
> Still, they're not asking for GMAC, they're asking for SHA-256. So I
> think a document where the goal is interoperability should focus on
> what is becoming the de-facto standard as long as it's secure enough.

Well, interoperability is one major consideration, but security and
efficiency are others.  My opinion: let's not take something that is
available, but is not needed, and turn it into a requirement.  Probably
others have an opinion, and this would be a topic for ipsecme.   

David

> 
> Yoav
> 
>