Subject: [Ietf-krb-wg] OTP and implicit tagging [IMPORTANT; implementors please respond]

From: Nico Williams <[email-masked]>
Date: Wed, 7 Dec 2011 15:52:40 -0600

draft-ietf-krb-wg-otp-preauth-21 uses IMPLICIT TAGS in its module
definition, and it ends up using implicit tags on types imported from
Kerberos and PKIX.

The use of implicit tags is somewhat problematic for several
implementors -- it is certainly not traditional for Kerberos!-- though
it's likely that in the end all can adjust.  However, while
investigating this I realized that there's a very subtle case that is
likely to be missed by inexperienced implementors: the case where an
implicit tag is used on a defined type.

For example these two definitions of SomeType are equivalent, but some
might easily treat them differently:

SomeInt ::= INTEGER
SomeType ::= [0] IMPLICIT SomeInt

vs.

SomeType ::= [0] IMPLICIT INTEGER

I know of at least one ASN.1 compiler that doesn't support the first
of the above.  That compiler cannot cope with the module in this I-D.
I've not checked other compilers.

This is a very subtle case that's likely to be very easy for
implementors to handle incorrectly.

There's a sub-case of this where the outermost tag of the defined type
and the implicit tag that replaces it are not the same size.  I
mention this in case anyone thinks that a trivial approach to the
above case is to encode the defined type and then replace its
outermost tag: if the tag being replaced is larger than the tag
replacing it then the size computation for the required buffer may be
too small and result in overflow, and in the flip case an
implementation might require a memmove() in order to be able to start
an encoded type at an address that can be free()ed (for example).

The most expedient solution to this problem may be to simply drop the
IMPLICIT TAGS from the module in the I-D.  It may be too late for this
if there are implementations in the wild (but it's not too late
process-wise: with WG and AD/IESG approval this change could be made
in AUTH48).  It would be useful to hear from implementors ASAP,
*before* the RFC issues, before it's too late to make this change
should we be inclined to agree to make it.

If we stick with implicit tags we'll get some significant future
benefit: the ability to use implicit tags as implementors add support
for them.  We should not ignore the value in that, though we might
still decide to drop implicit tags.  The fact that we did not notice
these problems until now, and that these problems are real indicates
that there is value in being conservative and sticking with what we
know works: for Kerberos that would be explicit tags.

We could have found out about this issue much later, and thus be much
sadder.  Consider this post a seasonal gift of joy then!  :)

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 12 Dec 2011 16:00:42 -0500

Nico, it's not clear to me if you are proposing that we change the
approved OTP draft to remove implicit.  It is technically possible to do
that now,, although the rfc-editor is being very speedy these days. We
may have little time.

I'd need to see strong interest from a couple of people to even open the
issue.  If the chairs do see that interest we'll ask our AD how to
proceed in terms of gaging whether we have enough support to make the
change.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Dec 2011 15:07:34 -0600

> that now,, although the rfc-editor is being very speedy these days. We

I am not yet proposing any change.  I'm asking whether there are any
implementors today who either have shipped or plan to ship soon, and I
am asking whether they got the document's use of implicit tags right.

Suppose two implementors are about to ship and one of them failed to
notice the use of implicit tags while the other got it right.

> proceed in terms of gaging whether we have enough support to make the

I think we first need answers to the question I asked.

Nico

---

From: Tom Yu <[email-masked]>
Date: Mon, 12 Dec 2011 16:16:26 -0500

> proceed in terms of gaging whether we have enough support to make the

We should delay the document if there's a good chance that an
implementor has shipped or is near shipping some code that materially
conflicts with the specification.  Certainly "IMPLICIT TAGS" was a
surprise to us, and it's conceivable that other implementors missed
it.

Nico's comments about implicit tagging of imported types are also a
concern, of course.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Dec 2011 15:16:27 -0600

In case it wasn't clear, the first issue is: are there any
implementors who have shipped or are intending to ship soon, and do
they differ in their handling of the document's ASN.1 such that they
will fail to interop, or do they all differ in the same way from the
document such that we should update the document to reflect reality?

Getting answers to the above question is critical to avoiding interop failures.

If we get no answers then I intend to propose that we change the
document to use explicit tags instead of implicit tags.

Given that today is the 12th of December I'm guessing we won't get
answers until after the new year; hopefully the I-D won't get
published before then (I'm guessing there's very little risk of that).
 But please don't wait to answer if you can answer now.

Nico