Subject: [Gen-art] Gen-ART review of draft-ietf-manet-ibs-03

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Oct 2014 19:35:55 -0700

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-manet-ibs-03
Reviewer: Martin Thomson
Review Date: 2014-10-23
IETF LC End Date: 2014-10-27
IESG Telechat date: (if known)

Summary: Ready with questions.

The language is quite clear and precise.  I did find that
comprehension required a non-trivial amount of digging into other
documents, but nothing was particularly hard to find.

This has a downref to 6507 (I see this in the shepherd writeup).

Questions:
The security considerations notes that the trusted authority has
access to private keys.  That would seem to defeat much of the benefit
of using asymmetric crypto here.  Why is this considered acceptable in
this context?  (I'd have thought it to be unacceptable in any context
when superior alternatives exist.)

The document mentions revocation, but does not seem to specify
anything.  If that is intentional, shouldn't the draft be more forward
about that?  (I only skimmed 6507 and the other docs, so I apologize
if I missed something.

Nits:
S4.1: duplicate "in in"

S5: It's probably not necessary to amend the reserved codepoints in
the registry: that rots quickly.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 24 Oct 2014 09:17:26 +0000

Martin

Thanks you for your comments.

There are various contexts where an authority having access to the keys is acceptable - I will just refer to the company I work for as working in a possible field (as do several other MANET participants). If this were being offered as the only way to do things, I agree that would not be acceptable, but instead it's there as an option for those people (and the WG feedback indicated there were a number) for whom this is a suitable solution, with other options also supported. (Which to use in your network is a management issue. A draft on MANET management is in the system somewhere, it should - I haven't checked if it currently does - mention this.)

I am also not aware of a solution that overcomes this problem without introducing different limitations, so it is a question of tradeoffs. This is one point in that tradeoff space. If anyone has a clearly superior solution that both avoids the need to trust an authority, and without introducing other limitations, then there are many of us in the ad hoc network community (and elsewhere, as just one example, to improve on 6507) who would like to see it. Note that all of the previously specified options (in RFC 7182) rely on keys shared by all participants, which is clearly weaker in some regards (but acceptable to many, hence also a valid option).

Revocation is enabled by this, but we are not, I believe, in a position to specify that. It would, in any applications I'm aware of, be necessary to either include a trusted (to revoke, at least) authority in the fielded network (which defeats part of the point here) or rely on an out-of-band process to, for example, distribute a blacklist of identities. There is also the option to incorporate time (in some manner) into identity and let identities expire without renewal - not as good as revocation, but with some value. But I believe this to be beyond the scope of this draft. In particular it cannot simply be fitted into this framework, as it raises new questions about how to trust the revocation. (Revocation is not discussed in 6507 either.)

That said, I will look again at what is said about revocation in order to see if any additional comments (e.g. one saying you could maintain an out of band distributed blacklist, if you have a trustworthy distribution mechanism, but that is beyond the scope of this document) are appropriate in the security considerations section. I would plan to collect all IETF LC comments first. And fix that nit!

Christopher

-- 
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 24 October 2014 03:36
To: [email-masked]; [email-masked]
Subject: Gen-ART review of draft-ietf-manet-ibs-03

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please wait for direction from your document shepherd or AD before posting a new version of the draft.

The language is quite clear and precise.  I did find that comprehension required a non-trivial amount of digging into other documents, but nothing was particularly hard to find.

Questions:
The security considerations notes that the trusted authority has access to private keys.  That would seem to defeat much of the benefit of using asymmetric crypto here.  Why is this considered acceptable in this context?  (I'd have thought it to be unacceptable in any context when superior alternatives exist.)

The document mentions revocation, but does not seem to specify anything.  If that is intentional, shouldn't the draft be more forward about that?  (I only skimmed 6507 and the other docs, so I apologize if I missed something.

Nits:
S4.1: duplicate "in in"

S5: It's probably not necessary to amend the reserved codepoints in the registry: that rots quickly.
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Oct 2014 20:31:04 +0200

> I am also not aware of a solution that overcomes this problem without introducing different limitations, so it is a question of tradeoffs. This is one point in that tradeoff space. If anyone has a…

It's fairly obvious that any entity that is trusted to assert identity
can arbitrarily impersonate.  But PKIX doesn't require that end
entities share private keying material with certification authorities.

I'm not 100% clear on the architecture here, but I've inferred that
participating nodes receive a private key from the trusted authority
and a set of public keys for other trusted nodes.  This could work
equally well if the nodes were able to instead distribute their own
public key to the authority.

I'm OK with making revocation out of scope, but it's not particularly
prominent, and that decision is a major constraint on the operational
approach you need when deploying something like this.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 27 Oct 2014 09:41:46 +0000

> I'm not 100% clear on the architecture here, but I've inferred that participating nodes receive a private key from the trusted authority and a set of public keys for other trusted nodes.

No, and that's where the win is here. You receive a private key (which includes some public information). You have no advance knowledge of what other nodes there are, and no key state that depends on other nodes. You can even field a node (thus cutting any connection with the authority) when which other nodes are to be trusted hasn't even been decided. Each node is keyed independently (except for the requirement to have unique identities) and in a O(1) operation, not O(N), where N is the number of nodes. This is appropriate to some ad hoc networks.

A node of course has a public key - but it's its identity (e.g. IP address). And just to forestall an obvious point, the security does not depend on the size of the identity space.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 24 October 2014 19:31
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]
Subject: Re: Gen-ART review of draft-ietf-manet-ibs-03

> I am also not aware of a solution that overcomes this problem without introducing different limitations, so it is a question of tradeoffs. This is one point in that tradeoff space. If anyone has a…

It's fairly obvious that any entity that is trusted to assert identity can arbitrarily impersonate.  But PKIX doesn't require that end entities share private keying material with certification authorities.

I'm not 100% clear on the architecture here, but I've inferred that participating nodes receive a private key from the trusted authority and a set of public keys for other trusted nodes.  This could work equally well if the nodes were able to instead distribute their own public key to the authority.

I'm OK with making revocation out of scope, but it's not particularly prominent, and that decision is a major constraint on the operational approach you need when deploying something like this.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 27 Oct 2014 10:04:41 +0000

I didn't say this, and perhaps I should have, but while signature uses the private key, verification uses the sender's identity (included in the packet/message) and the user-independent public information only.

-----Original Message-----
From: Dearlove, Christopher (UK) 
Sent: 27 October 2014 09:42
To: 'Martin Thomson'
Cc: [email-masked]; [email-masked]
Subject: RE: Gen-ART review of draft-ietf-manet-ibs-03

--
Christopher Dearlove
Senior Principal Engineer, Information Assurance Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124 [email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Oct 2014 13:01:46 -0000

All,

This document has completed IETF last call, but it seems to me that this
conversation may not be complete yet. Please continue it and try to reach
resolution.

The document is on the IESG telechat for 11/25 and I am confident that you will
reach some agreement (if only agreement to disagree) by then. Until that time I
will enter a Discuss ballot to track this as an open issue.

Thanks,
Adrian

> ________________________________________
> Sent: 27 October 2014 10:04:41 (UTC) Dublin, Edinburgh, Lisbon, London
> To: Martin Thomson
> I didn't say this, and perhaps I should have, but while signature uses the
private
> key, verification uses the sender's identity (included in the packet/message)
and
> the user-independent public information only.
> 
> --
> Christopher Dearlove
participating
> nodes receive a private key from the trusted authority and a set of public
keys for
> other trusted nodes.
> 
> No, and that's where the win is here. You receive a private key (which
includes
> some public information). You have no advance knowledge of what other nodes
> there are, and no key state that depends on other nodes. You can even field a
> node (thus cutting any connection with the authority) when which other nodes
> are to be trusted hasn't even been decided. Each node is keyed independently
> (except for the requirement to have unique identities) and in a O(1)
operation,
> not O(N), where N is the number of nodes. This is appropriate to some ad hoc
> networks.
> 
> A node of course has a public key - but it's its identity (e.g. IP address).
And just
> to forestall an obvious point, the security does not depend on the size of the
> identity space.
> 
> --
> Christopher Dearlove
> Senior Principal Engineer, Information Assurance Group Communications,
> Networks and Image Analysis Capability BAE Systems Advanced Technology
> Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre,
> Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687
> 
> ----------------------! WARNING ! ---------------------- This message
originates from
> outside our organisation, either from an external partner or from the
internet.
> > I am also not aware of a solution that overcomes this problem without
> introducing different limitations, so it is a question of tradeoffs. This is
one point
> in that tradeoff space. If anyone has a clearly superior solution that both
avoids
> the need to trust an authority, and without introducing other limitations,
then
> there are many of us in the ad hoc network community (and elsewhere, as just
> one example, to improve on 6507) who would like to see it. Note that all of
the
> previously specified options (in RFC 7182) rely on keys shared by all
participants,
> which is clearly weaker in some regards (but acceptable to many, hence also a
> valid option).
> 
> It's fairly obvious that any entity that is trusted to assert identity can
arbitrarily
> impersonate.  But PKIX doesn't require that end entities share private keying
> material with certification authorities.
> 
participating
> nodes receive a private key from the trusted authority and a set of public
keys for
> other trusted nodes.  This could work equally well if the nodes were able to
> instead distribute their own public key to the authority.
> 
prominent,
> and that decision is a major constraint on the operational approach you need
> when deploying something like this.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 28 Oct 2014 13:37:11 +0000

>From my perspective, and with support shown in the WG, this is an option that several people want. The need for a trusted authority is a minus point, but acceptable by some users and should not be blocked because it is not ideal for everyone. (The only other so far standardised options, based on shared keys, also are not ideal for everyone.) If there were a method that retained all of the advantages of this approach and removed the need to trust the authority, that would be a different matter, but I do not believe such a method is known. Note that this approach has at least one advantage Martin had not picked up on.

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: 28 October 2014 13:02
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Gen-ART review of draft-ietf-manet-ibs-03

All,

This document has completed IETF last call, but it seems to me that this conversation may not be complete yet. Please continue it and try to reach resolution.

The document is on the IESG telechat for 11/25 and I am confident that you will reach some agreement (if only agreement to disagree) by then. Until that time I will enter a Discuss ballot to track this as an open issue.

Thanks,
Adrian

private
and
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace 
> Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales 
> No: 1996687
> 
> 
participating
keys for
includes
> some public information). You have no advance knowledge of what other 
> nodes there are, and no key state that depends on other nodes. You can 
> even field a node (thus cutting any connection with the authority) 
> when which other nodes are to be trusted hasn't even been decided. 
> Each node is keyed independently (except for the requirement to have 
> unique identities) and in a O(1)
operation,
> not O(N), where N is the number of nodes. This is appropriate to some 
> ad hoc networks.
> 
And just
> to forestall an obvious point, the security does not depend on the 
> size of the identity space.
> 
> --
> Christopher Dearlove
> Registered Office: Warwick House, PO Box 87, Farnborough Aerospace 
> Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales 
> No: 1996687
> 
originates from
internet.
> Follow the 'Report Suspicious Emails' link on IT matters for 
> instructions on reporting suspicious email messages.
one point
avoids
then
> there are many of us in the ad hoc network community (and elsewhere, 
> as just one example, to improve on 6507) who would like to see it. 
> Note that all of
the
participants,
> which is clearly weaker in some regards (but acceptable to many, hence 
> also a valid option).
> 
> can
arbitrarily
> impersonate.  But PKIX doesn't require that end entities share private 
> keying material with certification authorities.
> 
participating
keys for
> other trusted nodes.  This could work equally well if the nodes were 
> able to instead distribute their own public key to the authority.
> 
prominent,
> and that decision is a major constraint on the operational approach 
> you need when deploying something like this.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Oct 2014 16:40:38 -0700

> From my perspective, and with support shown in the WG, this is an option that several people want. The need for a trusted authority is a minus point, but acceptable by some users and should not be…

I'm not sure that I'll be able to close on this quickly, since all I
have from Christopher's description is a distinct vibe of snake-oil,
which is very unfair and almost certainly hugely inaccurate.  I don't
believe for a minute that this is what we're talking about, so I must
be misunderstanding something.

As I understand the information flow, new nodes acquire a private key
from some trusted source, which is constructed in such a way that they
are able to make assertions about their identity (an IP address, if I
understand correctly) that will be accepted by other nodes who also
trust that authority.  I know just enough about crypto to know that
something like this might be possible, but it's outside of my direct
knowledge.

What I was thinking was that if you go to the trouble of using
asymmetric crypto, then you already have the pieces to build a system
that doesn't require sharing of private keying material between any
two parties.  Then trust can be disconnected from the authority to
some extent (you might trust X because of previous things X did,
whereas now, you don't know for certain that X is the same X because
the authority might have given the keys to a new X).

All that requires is that there is a two way exchange with the
authority rather than a one way exchange between the device and the
authority.  I freely admit that I don't understand whether there might
be some restrictions on the construction of the private key such that
it binds some additional information, maybe you can explain.  (Small
words, I'm not a cryptographer, I just use it.)

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 29 Oct 2014 10:52:15 +0000

The underlying cryptography is defined in RFC 6507. That is authored from CESG, who essentially stand in the same relationship to GCHQ as NIST do to the NSA. Experts in other words. Googling, you can find current CESG interest in implementing MIKEY-SAKKE (RFC 6509, of which RFC 6507 is a component). If there were a simple replacement with all the required properties, and not requiring trust in an authority, they (and at least one other expert I have communicated with) would be using that. So would I, and the other MANET WG members who have supported this draft.

I am not going to try to explain the underlying mathematics. See RFC 6507 and its references. It's an impossibility for me to try to say "it has to be this way". Any objection that something better can be done needs to provide that something better, not just say "asymmetric, therefore something better". 

Here is the key property that anything better also has to achieve. Authority A, users X and Y. A and X exchange information. It happens that this can be either one way (identity and key material A to X) or two way (identity X to A, key material A to X). But any (sensible) number of messages back and forth would be acceptable. This exchange mentions no other user than X. (In particular it can't mention Y, Y might not even exist at this point.) X now departs, and a similar exchange takes place between A and Y. No other user (including not X) is mentioned. The key material held by both X and Y is of fixed size, not dependent on the number of possible users, which is unbounded. (It might be acceptable to relax this last sentence constraint, depending on how it was relaxed.)

Now X is capable of signing a message that Y can verify as being sent by an X who was keyed by A in the same way that Y was. (Specifically, based on the same master secret held by A, which is never revealed by this.) And vice versa. Note that in both cases X and Y have no a priori knowledge of even the existence of the other. This is most clearly so for Y to X, because X departed A before Y contacted A. This process does not require A to be present. (A may even not exist by this point, it is possible to destroy A after keying X and Y, which may be desirable to some, though it denies the possibility of later adding Z. There have also been people using identity based methods who have put A into tamper-resistant hardware to make reading the master secret hard.)

It's clear that A must hold something independent of X and Y. That this is a master secret that allows the authority to do anything is, agreed, undesirable, but my understanding (not an expert, I just talk to them) is that this is the state of the art. (Actually the state of the art - of identity based cryptography in general, not necessarily the specific RFC 6507 realisation - may permit things like splitting A into A and B, but A and B could collude to act like a single A.) I would, as I have said, more than welcome something that removed this limitation. But whether it is an acceptable limitation depends on the user community. It will be acceptable for some, and this option is there for them.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 28 October 2014 23:41
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-ART review of draft-ietf-manet-ibs-03

> From my perspective, and with support shown in the WG, this is an option that several people want. The need for a trusted authority is a minus point, but acceptable by some users and should not be…

I'm not sure that I'll be able to close on this quickly, since all I have from Christopher's description is a distinct vibe of snake-oil, which is very unfair and almost certainly hugely inaccurate.  I don't believe for a minute that this is what we're talking about, so I must be misunderstanding something.

As I understand the information flow, new nodes acquire a private key from some trusted source, which is constructed in such a way that they are able to make assertions about their identity (an IP address, if I understand correctly) that will be accepted by other nodes who also trust that authority.  I know just enough about crypto to know that something like this might be possible, but it's outside of my direct knowledge.

What I was thinking was that if you go to the trouble of using asymmetric crypto, then you already have the pieces to build a system that doesn't require sharing of private keying material between any two parties.  Then trust can be disconnected from the authority to some extent (you might trust X because of previous things X did, whereas now, you don't know for certain that X is the same X because the authority might have given the keys to a new X).

All that requires is that there is a two way exchange with the authority rather than a one way exchange between the device and the authority.  I freely admit that I don't understand whether there might be some restrictions on the construction of the private key such that it binds some additional information, maybe you can explain.  (Small words, I'm not a cryptographer, I just use it.)

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Oct 2014 11:47:53 -0700

On 29 October 2014 03:52, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> Any objection that something better can be done needs to provide that something better, not just say "asymmetric, therefore something better".

That's a totally fair comment.  I was trying for expediency, since
that is fairly obvious to me.  Here's a rough sketch:

A has the same properties you describe: a secret that only it knows
(KSAK) and a paired public value (KPAK) that it can distribute.

X generates a secret (analogous to SSK) and passes a signature over
some material (optionally its identity, as you note above, plus the
paired public value) to A.  A provides X with a signature over the
both the public value and identity that X can subsequently use to
claim that identity to others with the KPAK (analogous to PVT).  X is
expected to keep that value secret also.

Then X can send message in the form (data || PVT || sig(SSK, data ||
PVT)), and Y can validate both sig and PVT to establish that this is
valid.

I'm not saying that this is strictly better.  It is more complex; RFC
6507 seems to cleverly roll the identity of X into the public key it
uses to sign.  But this has the property that private keys aren't
shared.  That means that you can implement this using an HSM that
enforces a strict containment for keys.  It also means that you can
establish a parallel bases for trust to the single authority.

I think that this highlights the reason we call out downrefs in the
process.  As a standalone information RFC, the abstract presentation
of RFC 6507 is perfectly innocuous.  But it's application to a
standards track effort does open questions about suitability.

You claim that this is an improvement over the status quo, and that is
quite clear.  The scheme prevents participants from impersonating each
other, which might not have been possible with a system based on a
shared symmetric key.  It does however, require that all trust is
placed in an authority.  I believe that we can do better.

Maybe the property I'm describing here not valuable in the deployment
context this is designed for and maybe this can be addressed by
establishing firm expectations about applicability.  Maybe a simple
applicability statement would suffice.  That is above my pay grade to
decide.  I'll defer to the IESG on this one.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Oct 2014 10:24:53 +0200

We should add Thomas Clause (the shepherd) into this thread as well.

(Unfortunately, .all doesn’t reach shepherds if they are not WG chairs, as is the case sometimes.)

Jari

On 29 Oct 2014, at 20:47, Martin Thomson <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 30 Oct 2014 10:46:08 +0000

I have a number of problems with this (including at some points not being clear what exactly is being defined), but I'll start with the first major one. X generates a public key related to SSK. But that's useless, Y does not know it. The whole point is that X and Y can be in total ignorance of each other until Y receives a message from X. There is no secure channel from X to Y to distribute a public key (including not via A). So now how does Y validate PVT? All Y knows about X is X's identity.

So you may believe we can do better (this needs to be retaining the key properties we have here). So far I do not. I don't expect to either, but we'll see. Note that a system that distributes public keys is a different tradeoff in the space. A valid one, but not the one here. (It is neither absolutely better or worse, as each has advantages over the other.)

I think you are mistaken about the issue with RFC 6507. The issue you have is that the authority knows all. But we didn't sleepwalk into that. That's completely known, and acceptable in some cases. This is for use in those cases. The issue similarly applies to MIKEY-SAKKE (RFC 6509) that is what RFC 6507 was issued to support. (It also applies to various people offering IBE-based encryption schemes for email, but that's another story.)

And it's up front in this draft. From the Introduction

  The disadvantage referred to is that the trusted authority has
   complete authority, even more so than a conventional certificate
   authority.  

(and the rest of that paragraph). And it's said again in the Security Considerations section.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 29 October 2014 18:48
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-ART review of draft-ietf-manet-ibs-03

> Any objection that something better can be done needs to provide that something better, not just say "asymmetric, therefore something better".

That's a totally fair comment.  I was trying for expediency, since that is fairly obvious to me.  Here's a rough sketch:

X generates a secret (analogous to SSK) and passes a signature over some material (optionally its identity, as you note above, plus the paired public value) to A.  A provides X with a signature over the both the public value and identity that X can subsequently use to claim that identity to others with the KPAK (analogous to PVT).  X is expected to keep that value secret also.

Then X can send message in the form (data || PVT || sig(SSK, data || PVT)), and Y can validate both sig and PVT to establish that this is valid.

I'm not saying that this is strictly better.  It is more complex; RFC
6507 seems to cleverly roll the identity of X into the public key it uses to sign.  But this has the property that private keys aren't shared.  That means that you can implement this using an HSM that enforces a strict containment for keys.  It also means that you can establish a parallel bases for trust to the single authority.

I think that this highlights the reason we call out downrefs in the process.  As a standalone information RFC, the abstract presentation of RFC 6507 is perfectly innocuous.  But it's application to a standards track effort does open questions about suitability.

You claim that this is an improvement over the status quo, and that is quite clear.  The scheme prevents participants from impersonating each other, which might not have been possible with a system based on a shared symmetric key.  It does however, require that all trust is placed in an authority.  I believe that we can do better.

Maybe the property I'm describing here not valuable in the deployment context this is designed for and maybe this can be addressed by establishing firm expectations about applicability.  Maybe a simple applicability statement would suffice.  That is above my pay grade to decide.  I'll defer to the IESG on this one.

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 30 Oct 2014 09:29:08 +0100

> On 30 Oct 2014, at 09:24, Jari Arkko <[email-masked]> wrote:
> 

Fabulous, thank you Jari. I will read up on this, try to understand the proxy-DISCUSS raised by Adrian.

> (Unfortunately, .all doesn’t reach shepherds if they are not WG chairs, as is the case sometimes.)

That does sound like something, which would be an easy fix in the tools set-up, and which probably would be a good fix (assuming that Shepherds are supposed to be of use to the process).

Thomas