Subject: [tcpm] tcp-auth-opt issue: reserved keyID value

From: Joe Touch <[email-masked]>
Date: Wed, 30 Jul 2008 15:58:06 -0700

Ran suggested that some implementations would benefit from reserving a
keyID as invalid (e.g., keyID 0):

This assists the efficiency of some implementations.

This also adds an additional requirement (e.g., keyID 0 MUST not be
used) which must be validated during conformance testing.

Comments on additional pros and cons would be useful. Examples of how
this might impact implementation efficiency would be particularly useful
(esp. if not encumbered)

_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Adam Langley" <[email-masked]>
Date: Wed, 30 Jul 2008 16:13:49 -0700

> this might impact implementation efficiency would be particularly useful

I can only say that I found no problems handling a KeyID of 0. I'd be
interested to know what problems other suspect their might be with it.

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Wed, 30 Jul 2008 16:20:13 -0700

Adam Langley wrote:
| On Wed, Jul 30, 2008 at 3:58 PM, Joe Touch <[email-masked]> wrote:
|> Comments on additional pros and cons would be useful. Examples of how
|> this might impact implementation efficiency would be particularly useful
|> (esp. if not encumbered)
|
| I can only say that I found no problems handling a KeyID of 0. I'd be
| interested to know what problems other suspect their might be with it.

FWIW, this was not noted as a problem; the issue was that having a
reserved value could make an implementation much more efficient.

<individual hat on>
I would like to hear some corroboration of this utility, preferably with
a public demonstration of its value, since it otherwise adds an
arbitrary rule to the mechanism.
<individual hat off>
_______________________________________________
tcpm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcpm