Subject: Re: [pkix] WGLC for TAMP - going to EXPERIMENTAL ?

From: "Denis Pinkas"<[email-masked]>
Date: Mon, 2 Nov 2009 09:35:03 +0100

Russ,

The problem is not, as you say, that "there is more than one mechanism that can be used in protocol design" 
but that the two protocol proposals exhibit fairly different properties.

There are many limitations with the current proposed protocol and I am concerned to have such a protocol on the standards track : 
this would prevent the definition of another protocol that would not have the limitations of the proposed protocol.

One solution would be to continue the current draft without major changes, but to switch it to the EXPERIMENTAL category (or INFORMATIONAL).
In any case, the limitations of the current protocol should be clearly advertised upfront (and not burried in the text or not indicated at all).

Anyway, it is not too late to make the protocol more usable.

Denis
----- Message reçu ----- 
De : Russ Housley 
À : denis.pinkas 
Date : 2009-10-29, 15:21:13
Sujet : Re: [pkix] WGLC for TAMP

Denis:

So there is more than one mechanism that can be used in protocol design.  You seem to prefer a different one.  
Without WG consensus that a change is needed here, I am not willing to make such a large change at this stage in the protocol develpment.

Russ

The topic of sequence numbers is not directly related to the topic of handles.

Let us first address the case of sequence numbers which is the motivation to change the MUST into a SHOULD.

The protocol attempts to address replay protection. 

There are two basic techniques that can be used: 
  - nonces generated by the client, or 
  - challenges generated by the server. 

When using challenges, the advantage is that clients only need to maintain state information 
between the request of the challenge and its use.

When using nonces based on the time, the advantage of using a combination of time and random numbers, 
is that clients do not need to maintain any state information between commands. 
However a clock reasonably synchronized is needed. It is unclear why this approach has not been chosen.

A relatively small amount of memory is needed to remember the nonces that have been *successfully* received 
during a time period from 5 to 10 minutes. All hardware security modules have a clock that is loosely synchronized 
and thus which can be used.

The approach which has been chosen is to use sequence numbers. The disadvantage is that 
state information between commands need to be maintained. The current text uses a MUST. 
But what happens if the memory of the sequence numbers is lost, despite of the MUST condition ? 
There is the need to recover from such a situation.

I made the assumption that the sequence numbers were lost by the client despite of the MUST condition. 
I proposed a new command (Sequence Number Query) to solve the issue, since the current commands 
do not seem to solve it (unless you have an explanation to provide).

Secondly, let us address the topic of handles. Handles should always be defined by the server as the result 
of a command. This makes no restriction to the content that can be stored in a TAS and this allows the same 
public key to be used with different constraints or purposes, which the present approach does not allow.
 
This also allows concurrent management by different TAS managers without strong synchronization between them, 
which the present approach does not allow.
 
Denis

----- Message reçu ----- 

De : Russ Housley 

À : denis.pinkas 

Date : 2009-10-25, 23:09:13

Sujet : Re: [pkix] WGLC for TAMP

Denis:

What is the concern that you are trying to address by making sequence number tracking a SHOULD instead of a MUST?  

In you last message you raised this in the context of using the public key as a handle for the trust anchor, 

so I guess I missed this point in the thread of many nested replies.

Let us add a new
command that

would return all the handles as well as the sequence numbers for
each

handle. 

This command would be called: "Sequence Number Query".

The Sequence Number Query command will include a random number in
the

query for replay protection and will be UNSIGNED.

The response will always be signed and will include: the random
number

and pairs of : handles, sequence numbers. 

The first item in the list will always be for the trust anchor store.
The

others for trust anchor information (including the apex).

The Sequence Number Adjust Command then seems to be unnecessary. 

This would solve the loss of synchronisation between a recipient and
a

trust anchor store. 

In particular, this would allow to change the sentence contained in

section 6 which is:

The TAMP message
recipient

MUST maintain a database of the most recent sequence number 

from a successfully processed TAMP message from each trust
anchor.

into:

The TAMP message
recipient

SHOULD maintain a database of the most recent sequence number 

from a successfully processed TAMP message from each trust anchor
and

each trust anchor store. 

If synchronisation is lost, the recipient can use the Sequence
Number

Query command to get 

the right sequence

numbers.

In this way, section 8 can also be removed. This approach would

solve my concern when two managers manage the same TAS 

without strong

synchronization.

Russ

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

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 2 Nov 2009 07:02:12 -0500

Inline...

From: [email-masked] [mailto:[email-masked]] On Behalf Of Denis Pinkas
Sent: Monday, November 02, 2009 3:35 AM
To: pkix
Subject: Re: [pkix] WGLC for TAMP - going to EXPERIMENTAL ?

Russ,

[CW] I assume you are referring to your desire to allow duplication of public keys.  The fact that each TA must have a unique public key is stated in section 1.3.2.  This is about as upfront as the point could be made.

[CW] As someone who has implemented the TAF and TAMP specs, I think they represent a significant improvement over the status quo and enable a number of trust anchor management models.  

Denis

	----- Message reçu ----- 

	De : Russ Housley 

	À : denis.pinkas 

	Denis:

	Russ

	

	

	

	 
	 
	Denis

	----- Message reçu ----- 

	De : Russ Housley 

	À : denis.pinkas 

	Denis:

	

	Let us add a new
	command that

	handle. 

	 

	 

	 

	trust anchor store. 

	section 6 which is:

	The TAMP message
	recipient

	into:

	The TAMP message
	recipient

	 
	each trust anchor store. 

	Query command to get 
	 
	the right sequence
	 
	numbers.

	 
	without strong
	 
	synchronization.

	Russ