Subject: Re: [keyassure] Latest spin at the chater...

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 1 Oct 2010 15:05:22 +0300

On Fri, Oct 01, 2010 at 01:16:24AM -0400, Phillip Hallam-Baker wrote:
> 
> The policy mechanism should be orthogonal to the keying mechanism.
> 
> Existing experience of security policy ties the policy to protocols and not
> keys. Security policies are of the form 'must use SSL when using HTTP at
> example.com' and 'must use SSL with key conforming to trust criteria X when
> using HTTP...'

I'm not a fan of security policies in DNS. I would like more to see facts,
like:

* Client can upgrade the connection (to this or that) after connecting
for this service (downgrade-attack-free upgrades)
* Client can connect securely (using this or that) to this service
(it will sniff the connection type)
* Client can obtain equivalent secure service (using this or that) from
that service (service redirect)

* This service supports security, client MAY use it.
* This service is sensitive, client SHOULD use security.
* This service doesn't yield useful nonsecure service, client MUST use
security.

* The certificate will chain to one of these TAs.

Of course, the client is free to ignore this, but it will do so on peril
of itself and its user.

This is pretty much everything one needs to have secure connection. One can
then send actual (protocol dependent) policy (securely) via that.

> I don't see any particular reason to separate TLS and non TLS protocols
> either. So far the only aspects of the protocol that are tied to TLS are the
> 'cert enumeration' mechanism and the cert type identifier.

I thought the idea was to form some "core" with some free "parameters" and
then instantiate that for each protocol.

Anyway, spec for TLS can be transformed into spec for IPSEC with little
search-and-replace.

> Given the choice, I would much prefer a key assurance mechanism that
> supports any security protocol but only works with X.509 certs than one the
> only works with TLS but has the option of using additional cert formats that
> are either essentially historic or make no real sense in the context of a
> hierarchical naming structure (PGP).

I think OpenPGP would make great sense here. Its way simpler if you just
need key container for TLS (since TLS doesn't have "raw key cert" format).
 
-Ilari

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 1 Oct 2010 08:11:32 -0400

I would support striking this sentence, which is the only mention of  
the word "privacy":
"The group will also investigate publishing security policies that are  
related to the use of keying material in the DNS, such as whether  
communications must be cryptographically protected."

This is not a policy group, it's a domain-to-key binding group.   
Policy, as I've said before, is the domain of the applications.

--Richard

On Oct 1, 2010, at 1:16 AM, Phillip Hallam-Baker wrote:

> I have asked on three separate occasions to have the ESRV draft  
> added to the list of possible starting points:
>
> Possible starting points for these deliverables include draft- 
> hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, draft- 
> josefsson-keyassure-tls and draft-hallambaker-esrv
>
>
>
>
>
>
>
>  If we are doing security policy we should look at all the proposals.
>
>
> The charter as written is of the form 'here is a technology, we want  
> a WG to turn it into a standard'. While that is the right approach  
> when there is significant experience of using actual code, we are  
> not in that position here.
>
> In particular I disagree with the following:
>
> The group will also investigate publishing security policies that  
> are related to the use of keying material in the DNS, such as  
> whether communications must be cryptographically protected.
>
> Please remove " that are related to the use of keying material"
>
>
> Existing experience of security policy ties the policy to protocols  
> and not keys. Security policies are of the form 'must use SSL when  
> using HTTP at example.com' and 'must use SSL with key conforming to  
> trust criteria X when using HTTP...'
>
> Absent extensive experience of tying policy to keys and a  
> demonstration of clear benefits resulting from that approach, the  
> charter should leave that choice open.
>
> I don't see any particular reason to separate TLS and non TLS  
> protocols either. So far the only aspects of the protocol that are  
> tied to TLS are the 'cert enumeration' mechanism and the cert type  
> identifier.
>
> supports any security protocol but only works with X.509 certs than  
> one the only works with TLS but has the option of using additional  
> cert formats that are either essentially historic or make no real  
> sense in the context of a hierarchical naming structure (PGP).
>
>
> I find the milestones to be entirely unrealistic.
>
> It will take considerably longer than June 2011 to have any draft  
> with the cert enumeration semantics contained in it ready for the  
> IESG. It would be somewhat optimistic to expect to have a draft with  
> only the key assurance semantics ready in that time, and that is  
> work we have twenty years experience doing at this point.
>
>
> The natural place to break the problem is between key assurance and  
> security policy. That is, along the major functional lines.
>
> I would anticipate the final document set looking something like
>
> * Key Assurance Mechanism
> * Use of Key Assurance Cert Type with HTTP/TLS
> * DNS Security Policy Mechanism
> * Use of Security Policy with HTTP
> * Use of Security Policy with SMTP, POP3, IMAP
>
> For each of the 'Mechanism' documents I would anticipate an  
> effective 3 step process of Experimental, Proposed, Standard.
>
> For the Use documents I would anticipate a 2 step process starting  
> at Proposed and going to Standard.
>
> If Russ' 2 step proposal goes through then the final step would be  
> 'Full Standard' otherwise it will most likely be 'Draft'.
>
>
> I would also leave open the possibility that there may be multiple  
> experimental mechanism documents in the case that there is no  
> agreement before test deployments start.
>
> The reason I propose using the experimental step is that I want to  
> start real world trials as soon as possible and want the results of  
> those trials to feed into the Proposed Standard. And to do trials, I  
> would like to have possible production code points assigned.
>
> Based on previous IETF experience, three years for getting the  
> documents of this type to Proposed Standard is rather more realistic  
> than the schedules proposed.
>
> On Thu, Sep 30, 2010 at 8:06 PM, Warren Kumari <[email-masked]>  
> wrote:
> Hi there all,
>
> I wanted to thank everyone for their hard work and active  
> involvement in the chartering discussions.
>
> I have reread most of the mail on this topic, and have tried to  
> integrate everyones suggestions, and I think that we finally have a  
> version that will be *acceptable* to everyone.
>
> I'd like to especially thank Stephen Farrell for his suggestions  
> (which I somehow filed into a different label and missed) as well as  
> Phillip, Paul, Richard and Jakob for their input and suggested text...
>
> I think that we have been fairly close to an acceptable charter for  
> a long time now, but were getting hung up on misunderstandings and  
> misinterpretations of what others were saying...
>
> So, please have another look at the charter and hopefully you will  
> find it acceptable to you:
> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
>
> If parts are not acceptable, please do me 3 favors:
> 1: Reread the unacceptable parts and try figure out if what you are  
> objecting to is what the sentence is trying to say, or it is just a  
> wording issue / differing uses of a term.
>
> 2: If  you are OK with it being in the charter so that we (as a WG)  
> can at least discuss the issue and come to consensus.
>
> and, most importantly:
> 3: send text --- saying "Bah, paragraph X is the devil! eat flaming  
> death, mongrel!" is *not* helpful... "How does the group feel about  
> 'Foo blargh wumblet boop' instead of 'mumble'?" is...
>
> W
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>
>
>
> -- 
> Website: http://hallambaker.com/
>
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Warren Kumari <[email-masked]>
Date: Fri, 1 Oct 2010 09:00:04 -0400

Will respond more fully later, but wanted to at least start responding before heading in to office.
On Oct 1, 2010, at 1:16 AM, Phillip Hallam-Baker wrote:

> I have asked on three separate occasions to have the ESRV draft added to the list of possible starting points:
> 
> Possible starting points for these deliverables include draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, draft-josefsson-keyassure-tls and draft-hallambaker-esrv
> 
> 

Apologies, done.

> The charter as written is of the form 'here is a technology, we want a WG to turn it into a standard'. While that is the right approach when there is significant experience of using actual code, we are not in that position here. 
> 
> The group will also investigate publishing security policies that are related to the use of keying material in the DNS, such as whether communications must be cryptographically protected.
> 

Can you please try and limit this a bit? I had initially written it without that phrase, but then realized that that also opened the door to talking about how high a fence should be around your datacenter and that you shouldn't write your password on a sticky on your monitor... One of the major sticking points on these discussions has been:
A: if policy should be included at all (and, my reading is that the majority of folk think that it shouldn't)
B: if it is, what all should be allowed.

Just saying "publishing security policies in the DNS" is entirely too broad... 

> Existing experience of security policy ties the policy to protocols and not keys. Security policies are of the form 'must use SSL when using HTTP at example.com' and 'must use SSL with key conforming to trust criteria X when using HTTP...'
> 
> Absent extensive experience of tying policy to keys and a demonstration of clear benefits resulting from that approach, the charter should leave that choice open.
> 
> I don't see any particular reason to separate TLS and non TLS protocols either. So far the only aspects of the protocol that are tied to TLS are the 'cert enumeration' mechanism and the cert type identifier.
> 
> Given the choice, I would much prefer a key assurance mechanism that supports any security protocol but only works with X.509 certs than one the only works with TLS but has the option of using additional cert formats that are either essentially historic or make no real sense in the context of a hierarchical naming structure (PGP).
> 

Yes, you've made that clear --- however, you are not the only person participating. Keep in mind that I haven't had my morning coffee yet, and so am extra grumpy -- We have been trying really hard to come to a compromise on many of these points, but I'm beginning to think that we are just not going to be able to make you happy. We have been trying to move things forward, but it feels like you are intentionally being obstructionistic.

> It will take considerably longer than June 2011 to have any draft with the cert enumeration semantics contained in it ready for the IESG. It would be somewhat optimistic to expect to have a draft with only the key assurance semantics ready in that time, and that is work we have twenty years experience doing at this point.
> 
> 
> The natural place to break the problem is between key assurance and security policy. That is, along the major functional lines.
> 

While the final document set may or may not look like that, having a few items and then rechartering may allow us to actually get some things done... 
When rechartering we can look at increasing or decreasing the scope --- forming while saying "And we'll poke at a whole bunch of other WGs space" is yet another obstacle to getting formed...

> 
> For each of the 'Mechanism' documents I would anticipate an effective 3 step process of Experimental, Proposed, Standard.
> 
> For the Use documents I would anticipate a 2 step process starting at Proposed and going to Standard.
> 
> If Russ' 2 step proposal goes through then the final step would be 'Full Standard' otherwise it will most likely be 'Draft'.
> 
> 
> I would also leave open the possibility that there may be multiple experimental mechanism documents in the case that there is no agreement before test deployments start. 
> 

The possibility of multiple experimental mechanism documents is still open -- work can happen that isn't listed in the milestones, but I do not think that we *need* to do multiple for all docs...

> The reason I propose using the experimental step is that I want to start real world trials as soon as possible and want the results of those trials to feed into the Proposed Standard. And to do trials, I would like to have possible production code points assigned.
> 
> Based on previous IETF experience, three years for getting the documents of this type to Proposed Standard is rather more realistic than the schedules proposed.

Yes, the milestones were intended to be aggressive, and I think that we could meet them if folk are willing to ignore distraction / disruptions.

W (who still hasn't had his coffee).

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Oct 2010 09:56:23 -0400

Ilari's position is completely reasonable here. We have not yet demonstrated
the practicality of any approach to security policy and we are building on
an infrastructure (DNSSEC) that is still in deployment phase.

That is why I do not want the charter to be tied to any specific approach,
mine included.

The point I was trying to make was that forced to chose between a
certificate type that works for TLS+IPSEC+S/MIME+SSH and one that works for
X.509+PGP+SPKI, I would choose the first, i.e. we would have:

CERT APKIX ....
CERT APGP ....
CERT ASPKI ....

But that is if I am forced to choose. I would prefer

CERT ASSERT 0 0 <AlgID> <CertID> <Digest>

Which is completely general.

What I do not want is for these decisions to be made in the charter.

On Fri, Oct 1, 2010 at 8:05 AM, Ilari Liusvaara <[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 1 Oct 2010 10:23:53 -0400

> That is why I do not want the charter to be tied to any specific approach,

Over on the homegate list, an open-ended, unfocussed charter of that
type was just rejected on the very grounds that it's too open-ended,
unfocussed, unclear, and unconstrained.

My lesson from that discussion is that the current IESG wants specific
deliverables in charters.

Therefore, if we don't tie to specific approaches, we'll get nowhere
except wandering in the wilderness.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Oct 2010 10:47:33 -0400

If you believe that then tie the charter to the proven approach as used in
DKIM and policymaker and every other Security Policy scheme.

If you believe that then tie the charter to the approach that gives the
clean API.

Having recently shepherded three drafts through the IESG to RFC-EDITOR
state, the issues that they have been concerned with are consistency of
architectural approach, separation of concerns and that the group
understands the security considerations and has deployed all relevant
controls.

On that basis, I don't think the IESG is going to be impressed by a charter
that is written to force adoption of the cert enumeration approach.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 1 Oct 2010 13:54:56 -0400

On Oct 1, 2010, at 9:56 AM, Phillip Hallam-Baker wrote:

> Ilari's position is completely reasonable here. We have not yet  
> demonstrated the practicality of any approach to security policy and  
> we are building on an infrastructure (DNSSEC) that is still in  
> deployment phase.

Thats true -- as we have not "demonstrated the practicality of any  
approach to security policy" I am leaning more and more to making the  
charter as specific as possible, and not opening the "security policy"  
door at all...

>
> That is why I do not want the charter to be tied to any specific  
> approach, mine included.
>
>
> certificate type that works for TLS+IPSEC+S/MIME+SSH and one that  
> works for X.509+PGP+SPKI, I would choose the first, i.e. we would  
> have:
>
> CERT APKIX ....
> CERT APGP ....
> CERT ASPKI ....
>

Can you please try draft text that explains that in a short and  
concise and *specific* manner?

We keep coming back to the "security policy" bit, and it seems as  
though A: most of the participant have a different view than yours, B:  
your definition is vague and / or changing and / or  C: poorly  
defined / overly broad....

> What I do not want is for these decisions to be made in the charter.

Oh, but what we REALLY don't want is to have a charter that is so  
broad that:
A: It never gets agreed to (which is what is happening here -- we have  
been trying to limit the scope, but have slowly increased it to try  
accommodate your suggestions and views).
B: the working group gets bogged down (like the mailing list has been)  
and forward process is thwarted.

A tightly bounded and specific charter that allows us to move forward,  
do a bit of work and then A: conclude or B: recharter seems preferable  
-- "launch and iterate" approach vs "extended kvetching".

I really appreciate your experience, insight, passion and knowledge,  
but it seems more and more as though the list's view and your view's  
on what we are trying to accomplish differ and that these may be  
irreconcilable differences.

One possible option is that the security policy parts could be  
included in a different RR and worked on as an individual submission  
and / or in a different group...

W

> protocols

-- 
Outside of a dog, a book is your best friend, and inside of a dog,  
it's too dark to read

---

From: Scott Schmit <[email-masked]>
Date: Fri, 1 Oct 2010 23:26:45 -0400

Looking at the deliverables, I see an asymmetry:
> Nov 2010   First WG draft of standards-track protocol for using DNS to 
>            associate hosts with keys for TLS and DTLS
> Jan 2011   First WG draft of standards-track protocols for using DNS 
>            to associate hosts with non-TLS security protocols
                                     ^^^^^^^
> Jun 2011   Protocol for using DNS to associate domain names with keys 
>            for TLS and DTLS to IESG
> Aug 2011   Protocols for using DNS to associate domain names with keys 
>            for IPsec to IESG
                 ^^^^^

Is this deliberate? If I understand the latter two correctly, the intent 
is that the Jun/Aug deliverables are final RFCs of the drafts put out in 
Nov/Jan.

The other thing is that I'm not a big believer in special cases unless 
they're really necessary, and I don't quite understand why TLS/DTLS 
warrants a special case. I would have thought that we'd explain the
basic mechanism, and then appropriate protocol WGs (or this WG) would
explain how to leverage the mechanism in follow-on RFCs. Otherwise
you're setting yourself up for a maintenance nightmare of
almost-the-same mechanisms.

If the thought is that the TLS/DTLS use cases are somehow more complex
than average, then maybe we should be laying out the requirements and
constraints first...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 2 Oct 2010 00:07:40 -0400

On Fri, Oct 1, 2010 at 1:54 PM, Warren Kumari <[email-masked]> wrote:

> Can you please try draft text that explains that in a short and concise and
> *specific* manner?
>
> We keep coming back to the "security policy" bit, and it seems as though A:
> most of the participant have a different view than yours, B: your definition
> is vague and / or changing and / or  C: poorly defined / overly broad....

Please read your own draft that your name is on before accusing others of
being vague or confusing. You will find that the certificate enumeration
semantics that you claim to be the main point are never actually explained
directly.

Are you honestly confused by my comments on your spec or are you as confused
by the document you put your name on as I was until I spent several weeks
working out what it says?

Where do I mention security policy in the foregoing paragraph you are
commenting on? The answer is that I don't because I am only addressing the
fact that you have a peculiar and unexplained fixation with having a spec
that covers all known certificate types yet arbitrarily separates TLS
protocol handling from all others.

None of the authors of the draft have bothered to explain this rationale.

The fixation with support for multiple cert types is despite the fact that
SPKI concluded in 1999 and has never progressed beyond EXPERIMENTAL and the
only other cert format of relevance is OpenPGP. While support for multiple
certificate types might be arguably 'nice to have' it is hardly as
significant as support for multiple protocols in a consistent fashion.

No other key assurance format I know of has this peculiar distinction that
you are attempting to foist on us and never bother to explain. Instead you
use the tactics of agenda denial against me.

Please explain to us just why you think TLS should be handled as a special
case in the protocol.

Note that it is perfectly OK to have a mechanism that is general and only
give a detailed explanation for TLS. But that is not what is being proposed
here. What you are proposing is to do a one off for using TLS with any
certificate type and then do other protocols.

The CERT slot is for certificate type not protocol type. You do owe us an
explanation for that approach.

So far none of you have ever deigned to justify a single one of your design
decisions. Instead you have attempted to avoid engagement by claiming not to
understand any of the points being made. Then you declare that consensus in
the group is not to make any change and carry on as before.

>>
>
> Oh, but what we REALLY don't want is to have a charter that is so broad
> that:
> A: It never gets agreed to (which is what is happening here -- we have been
> trying to limit the scope, but have slowly increased it to try accommodate
> your suggestions and views).
> B: the working group gets bogged down (like the mailing list has been) and
> forward process is thwarted.
>

The question that the IESG is asking is not 'is the charter too broad' it is
'is the WG likely to finish anything worthwhile'.

So responding to every design query by claiming not to understand the
question is not exactly a good tactic if you want to give the ADs confidence
in the WG ability to deliver.

The approach that you appear to have been advised to follow here is to avoid
engagement on the technical issues at all costs and just stick to the party
line.

I think that before you continue much further that you should consult an
alternative expert on IETF WG strategy. I think that the advice you get back
will be surprisingly different to the advice you have been receiving to
date.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 2 Oct 2010 08:47:20 -0700

At 11:26 PM -0400 10/1/10, Scott Schmit wrote:
>Is this deliberate?

Er, no, it was a mistake. Now fixed.

>If I understand the latter two correctly, the intent

Correct.

>almost-the-same mechanisms.

Can you explain more? The drafts done so far show that most of the protocol work is in specifying the DNS part. For example, the "change" to TLS is simply "trust this cert without validating, unless you want to validate anyway". It would be similar for IPsec, although IPsec is quite different because of the many different types of authentication mechanisms that need to be shown in and out of scope.

>than average, then maybe we should be laying out the requirements and

At least for me, I didn't choose it because of its complexity, but in fact the opposite: the new protocol makes almost no changes to TLS processing.

--Paul Hoffman, Director
--VPN Consortium