Subject: [The IESG] Last Call: draft-mcgrew-auth-enc (An Interface and Algorithms for Authenticated Encryption) to Proposed Standard

From: Sam Hartman <[email-masked]>
Date: Fri, 15 Jun 2007 17:21:05 -0400

Folks, we should take a look at this and see if there are ways this could be used for us.

And in particular we should make sure that nothing in this draft is
both a problem for us and easy to fix.

Subject: Last Call: draft-mcgrew-auth-enc (An Interface and Algorithms for Authenticated Encryption) to Proposed Standard
From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Date: Thu, 31 May 2007 15:33:48 -0400
List-Id: ietf-announce.ietf.org

The IESG has received a request from an individual submitter to consider
the following document:

- 'An Interface and Algorithms for Authenticated Encryption '
   <draft-mcgrew-auth-enc-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-06-28. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-mcgrew-auth-enc-02.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15090&rfc_flag=0

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 18 Jun 2007 15:32:40 -0400

> both a problem for us and easy to fix.

I wonder if it wouldn't be useful for AEAD algorithms defined under this 
document to live in the same namespace as RFC3961 algorithms, rather than 
in a distinct namespace.  It seems like it would be fairly common to have 
algorithms for which both 3961 and AEAD operations could be defined, and 
that it would be useful for applications, possibly including extensions to 
Kerberos, to be able to negotiate use of an algorithm that provides either 
or both sets of operations using a single integer.

Note that RFC3961 and draft-mcgrew-auth-enc-02.txt currently slice up the 
namespace rather differently -- RFC3961 reserves negative numbers for 
private use, while the McGrew draft reserves 32768..65535 for private use 
and prohibits negative values entirely.  Perhaps more importantly, the 
registration policies differ -- RFC3961 requires Standards Action or Expert 
Review, while this draft sets the policy at Specification Required.

Comments?

---

From: Luke Howard <[email-masked]>
Date: Tue, 19 Jun 2007 13:04:02 +1000

>or both sets of operations using a single integer.

This makes more sense to me, can't we use RFC3961 with generic
composition?

-- Luke

--
www.padl.com | www.lukehoward.com

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 19 Jun 2007 10:42:49 -0500

> This makes more sense to me, can't we use RFC3961 with generic

RFC3961 does not cover AEAD modes nor generic composition, and RFC4120
doesn't either.  In particular we have a deep assumption that ciphertext
and integrity protection tags are separate octet strings, whereas
draft-mcgrew-auth-enc explicitly rejects such a separation.

Not that that would be insurmountable should we want to adopt AEAD using
the interfaces in draft-mcgrew-auth-enc (we can always split the output
of AEAD encryption at a suitable bounday and call one the ciphertext and
the other the MIC just so they can fit existing slots in the protocol).

Nor would I want draft-mcgrew-auth-enc to have to provide interfaces
that do make a distinction between ciphertext and tag.

Like Jeff I am concerned about having a multiplicity of namespaces for
cryptographic algorithm identifiers as that might promote confusion.
RFC authors will have to be careful not to mix up these numbers
(probably by using their symbolic names instead); implementors will have
to be even more careful (since, I imagine, protocols will use the
numeric identifiers on the wire rather than symbolic names, so keeping
the various distinct namespaces separate will matter).

But I'm not sure that we can unify these namespaces at this stage.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Jun 2007 12:49:50 -0400

So, if people conclude they want any of these comments sent to the IESG, they should actually do so this week.
Sending to the kerberos list does not count; comments need to go to [email-masked] or [email-masked]