Subject: [stir] Moving from BOF to Charter

From: Russ Housley <[email-masked]>
Date: Wed, 31 Jul 2013 10:25:08 -0400

With the BOF behind us, I think there is one, and only one topic that this mail list should be discussing.  That is the charter text that is ready for the IESG.

The pre-BOF charter text is here: http://www.ietf.org/charter/charter-ietf-stir-00-00.txt

I will hold the pen on changes to the charter text.  Some people suggested changes during the BOF:

Preamble
   - Remove "deployable" or change it to "rapidly deployable"
   - Add "within call set up time"
   - Add a discussion of a threat model
   - Be clear that the "calling party" is identified by their telephone number

Postamble
   - Can something be said about alignment of incentives?

Privacy
   - We need to do more than punt.

Please propose exact text for any of these topics.  I prefer one proposed change per message in a hope to more easily judge consensus.  To this end, I will start a thread on the inclusion of an out-of-band mechanism.

Russ

---

From: Russ Housley <[email-masked]>
Date: Wed, 31 Jul 2013 11:22:33 -0400

No one spoke against including an in-band mechanism in the charter.  So, it is clearly in the charter.  We need to decide whether an out-of-band mechanism is included as well.

Many people spoke for including an out-of-band mechanism in the charter.  And, many people spoke against it.

Here is my view of the hums that were taken at the end of the BOF ...

First Hum: in-band only,  out-of-band only, in-band then out-of-band, and in-band and out-of-band together
  - there was no support for out-of-band only
  - there was roughly equal support for the other three options

Second hum: could live with in-band and out-of-band in the charter
  - significant response

Third hum: can't live in-band and out-of-band in the charter
  - a few people trying to make a lot of noise

Since the BOF, I tried to talk to people that spoke against inclusion of an out-of-band mechanism in the charter.  I was not able to find everyone, but I did find many.  The majority of these people can live with an out-of-band mechanism in the charter. 

So, I suggest that we leave this aspect of the charter alone.  That is, the proposed WG will deliver an in-band mechanism first, and then deliver an out-of-band mechanism.  Notice that this does not prevent the WG from working on them at the same time, but ti does speak directly to the order that they will be sent to the IESG.

Thoughts?

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 31 Jul 2013 11:27:25 -0400

Russ,

As I mentioned at the mic, I'd like to see both a threat model and a 
privacy analysis
as deliverables early in this process.

I also think we need to have a discussion about the size of the population
of calling parties who will have credentials, and the size of the verifiers
in the system. This seemed to be the source of some disagreement during 
the BoF,
and some proposals that might work well for small values of either (or both)
of these parameters might not work well for very large values of these 
parameters.

The texts says:

As its first work item, the working group will specify a SIP header-based
authorization mechanism to verify the originator of a SIP session is
authorized to use the claimed source telephone number,

Should the "authorization" be "authentication" above. I agree with the 
use of
"authorized" in the latter part of the sentence.

later, the text says:

After completing the in-band mechanism, the working group will consider
session establishment where there are one or more non-SIP hops, most
likely using an out-of-band authorization mechanism.

Did you mean authorization or authentication here?

Steve

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 31 Jul 2013 15:33:43 +0000

> So, I suggest that we leave this aspect of the charter alone.  That is, the proposed WG will deliver an in-band mechanism first, and then deliver an out-of-band mechanism.  Notice that this does no…

Given the urgency to move forward with this work, I can live with this. 

Cullen

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 31 Jul 2013 17:49:24 +0200

This works for me.

On Wed, Jul 31, 2013 at 5:33 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

> > No one spoke against including an in-band mechanism in the charter.  So,
> it is clearly in the charter.  We need to decide whether an out-of-band
> mechanism is included as well.
> >
> > Since the BOF, I tried to talk to people that spoke against inclusion of
> an out-of-band mechanism in the charter.  I was not able to find everyone,
> but I did find many.  The majority of these people can live with an
> out-of-band mechanism in the charter.
> >
> > So, I suggest that we leave this aspect of the charter alone.  That is,
> the proposed WG will deliver an in-band mechanism first, and then deliver
> an out-of-band mechanism.  Notice that this does not prevent the WG from
> working on them at the same time, but ti does speak directly to the order
> that they will be sent to the IESG.
> >
> > Thoughts?
>
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 31 Jul 2013 11:52:24 -0400

> Given the urgency to move forward with this work, I can live with this. 

Same here.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 31 Jul 2013 16:26:01 +0000

Looks good enough.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Wednesday, July 31, 2013 11:52 AM
To: Russ Housley
Cc: IETF STIR Mail List
Subject: Re: [stir] Including out-of-band in the Charter

>> So, I suggest that we leave this aspect of the charter alone.  That is,
the proposed WG will deliver an in-band mechanism first, and then deliver an
out-of-band mechanism.  Notice that this does not prevent the WG from
working on them at the same time, but ti does speak directly to the order
that they will be sent to the IESG.

Same here.

-hadriel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 31 Jul 2013 18:30:43 +0200

On 7/31/2013 5:27 PM, Stephen Kent wrote:
>  privacy analysis as deliverables early in this process.

+1

The only caveat I'll raise is based on a 'scoping' problem that happened 
for the threats exercise when the DKIM wg was being formed.  What we 
were initially asked for was a rather basic consideration of threats, to 
formulate some summary, pragmatic statements.

Within a few days, a few IETF security folk -- I don't recall Herr 
Kent's position on this -- attempted to turn this into a detailed 
exercise at a level of detail I was told would have been appropriate to 
a military security system.  Calling that onerous would entirely miss 
how unrealistic it would have been to attempt.

I thought the original request quite appropriate, since it would get 
everyone on the same page about some essential motivations and goals for 
the effort.  The result was a 25-page RFC.[1]  I've never been clear 
whether it was more work than reasonable, too little, or just right.

So I suggest some care in formulating these requirements, to keep it 
useful, quick and short.

> I also think we need to have a discussion about the size of the
> population of calling parties who will have credentials, and the size
> of the verifiers in the system.

+1

d/

[1]  http://www.ietf.org/rfc/rfc4686.txt

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 31 Jul 2013 12:38:23 -0400

I agree though as Lucy Lynch pointed out in calling out attention to the
privacy problem there may be an interesting dimension to this. When does the
right to privacy trump the right to be anonymous?  We are confronted with a
situation where a genuine perceived need for anonymous communications
identity for some has become a shield for criminal behavior.  

The other issue maybe ISOC can help us with this problem is we still don't
have an idea of the scope of the problem beyond North America.  Other
jurisdictions handle this differently and this is a perfect opportunity to
encourage national regulators to engage with the IETF/ISOC in investigating
these problems.

I would argue that what we are seeing in North America is the "Canary in the
Coal Mine".  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephen Kent
Sent: Wednesday, July 31, 2013 11:27 AM
To: [email-masked]
Subject: Re: [stir] Moving from BOF to Charter

Russ,

As I mentioned at the mic, I'd like to see both a threat model and a privacy
analysis as deliverables early in this process.

I also think we need to have a discussion about the size of the population
of calling parties who will have credentials, and the size of the verifiers
in the system. This seemed to be the source of some disagreement during the
BoF, and some proposals that might work well for small values of either (or
both) of these parameters might not work well for very large values of these
parameters.

The texts says:

Should the "authorization" be "authentication" above. I agree with the use
of "authorized" in the latter part of the sentence.

later, the text says:

After completing the in-band mechanism, the working group will consider
session establishment where there are one or more non-SIP hops, most likely
using an out-of-band authorization mechanism.

Steve

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 31 Jul 2013 12:39:04 -0400

+1   in band first then ...

-----Original Message-----

Same here.

-hadriel

---

From: Michael Hammer <[email-masked]>
Date: Wed, 31 Jul 2013 16:56:48 +0000

All,

For security, an assessment of the degree to which a called party can
reasonably rely on the caller ID validation is in order.  
But, it should probably contain the warning to users to still not provide
any sensitive information when they are not the calling party, to be safe.

While privacy is important, I believe that it could be secondary, because, 
if this is designed as an optional feature (user chooses what to assert and
whether to sign or not) 
such considerations are in the realm of the supplementary features like CLIP
and CLIR.
The default may be to show and sign for the 99% with an opt-in to suppress
for the corner cases that need it.
Privacy could also be modeled as an over-ride feature that allows a party or
carrier to substitute an anonymous signature.

Bottom line, privacy is a derivative of the caller ID function.

Clearly there needs to be balance between the calling and called parties.
Called parties are going to have to learn to automatically or manually block
calls.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Richard Shockey
Sent: Wednesday, July 31, 2013 12:38 PM
To: 'Stephen Kent'; 'IETF STIR Mail List'
Subject: Re: [stir] Moving from BOF to Charter

-----Original Message-----

Russ,

The texts says:

later, the text says:

Steve

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 31 Jul 2013 18:07:25 +0000

Ok for as long as the in band is first....and please explain within the rules how that will be enforced?

-----Original Message-----

Same here.

-hadriel

---

From: Russ Housley <[email-masked]>
Date: Wed, 31 Jul 2013 14:22:38 -0400

If the charter says that in-band must be done first, then the AD will not accept a publication request for out-of-banf until that criteria is met.

Russ

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 31 Jul 2013 18:24:48 +0000

Sorry in advance for being a pain, but "done first" as published RFC, or into IESG? If the latter, then first has little meaning...

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, July 31, 2013 2:23 PM
To: DOLLY, MARTIN C
Cc: IETF STIR Mail List
Subject: Re: [stir] Including out-of-band in the Charter

Russ

---

From: Brian Rosen <[email-masked]>
Date: Wed, 31 Jul 2013 16:28:30 -0400

With respect to privacy, I think there are two principles we ought to
explicitly agree to
1) Anonymous calls, as already defined in SIP standards will still work,
which means they will not have a valid identiy
2) the mechanisms we design will not reveal any more information than a
call without the mechanism would.

The former is just some explici text that says the mechanism must not be
applied to calls to with the anonymous From uri.  The latter may constrain
the mechanisms some, but that is a good thing.

Brian

On Wednesday, July 31, 2013, Michael Hammer wrote:

> From: [email-masked] <javascript:;> [mailto:[email-masked]<javascript:;>]
> On Behalf Of
> Richard Shockey
> From: [email-masked] <javascript:;> [mailto:[email-masked]<javascript:;>]
> On Behalf Of
> Stephen Kent
> To: [email-masked] <javascript:;>
> privacy
> [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: <[email-masked]>
Date: Wed, 31 Jul 2013 20:45:39 +0000

>   - Be clear that the "calling party" is identified by their telephone number

It's only used once in the preamble, and although I'm not enthralled with the use of authorization in that sentence, I can live with the current phrasing personally. 

This working group will define a deployable
mechanism that verifies the authorization of the calling party to use
a particular telephone number.

Philippe Fouquart
Orange Labs Networks
+33 (0) 1 45 29 58 13

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Wednesday, July 31, 2013 4:25 PM
To: IETF STIR Mail List
Subject: [stir] Moving from BOF to Charter

Preamble

Postamble

Privacy

Russ

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 1 Aug 2013 00:25:00 +0200

As Russ suggested, the hard gate is submission to the IESG.  That's the
step that is most directly under the control of the WG, though they can
obviously speed up IESG processing by ensuring that the document(s) are
well-reviewed before they're submitted.  After the documents have been
submitted to the IESG, it will be my job to keep them in the right order.

That said, it's not like publication request timing is the only tool we
have.  If consensus continues to build around In-then-Out, I would read the
charter text to mean that the energy of the WG should be focused on the
in-band solution until that solution is approaching completion, after which
point out-of-band work can start up.  The chairs can manage this by setting
the timing of calls to adopt documents for the various solutions, timings
of WGLCs, etc.  We could also consider arranging the milestones so that
they specify the sequencing in some more detail.

(In any event, I would encourage WG participants to keep in mind that there
will likely substantial overlap between the two solutions.  They both
require a credential infrastructure and some sort of authenticated object
that attests to the validity of a call.  They might only really differ in
how the authenticated object is delivered from originator to verifier.  So
we might find that some of the first things that are delivered are common
to both solutions.)

Once we come to agreement on sequencing, we should take a look at the
milestones to ensure that they reflect the sequencing we agree on.

Hope that helps,
--Richard

On Wed, Jul 31, 2013 at 8:24 PM, DOLLY, MARTIN C <[email-masked]> wrote:

> Sorry in advance for being a pain, but "done first" as published RFC, or
> into IESG? If the latter, then first has little meaning...
>
> If the charter says that in-band must be done first, then the AD will not
> accept a publication request for out-of-banf until that criteria is met.
>
> Russ
>
>
> > On Jul 31, 2013, at 11:33 AM, Cullen Jennings (fluffy) <[email-masked]
> >
> > wrote:
> >
> >>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 Aug 2013 07:22:20 +0200

On 8/1/2013 12:25 AM, Richard Barnes wrote:
> (In any event, I would encourage WG participants to keep in mind that
> there will likely substantial overlap between the two solutions.
> They both require a credential infrastructure and some sort of
> authenticated object that attests to the validity of a call.  They
> might only really differ in how the authenticated object is delivered
> from originator to verifier.  So we might find that some of the first
> things that are delivered are common to both solutions.)

Richard,

The above text is, of course, an entirely reasonable line of thinking. 
It might even be correct, and for some approaches most certainly is.

For others it isn't at all correct.

The project management problem with what you've put forward is that any 
meaningful version of "keeping out-of-band in mind" while working on 
in-band effectively requires working on in-band and out-of-band 
simultaneously.

That's fundamentally different from working with complete focus on 
in-band and only afterwards moving towards out-of-band.

At every turn in considering choices for in-band, the implication of 
your statement is that people will be raising concerns for application 
to out-of-band.  That essentially requires working out the details of 
out-of-band simultaneously with in-band.

This is quite contrary to what is usually meant in a charter about 
working on one thing and /then/ on another.

A charter is supposed to help reconcile these sorts of potential sources 
of focus-confusion, rather than make them fuzzier.

d/

---

From: Stephen Kent <[email-masked]>
Date: Thu, 01 Aug 2013 02:59:31 -0400

Dave,

I refer you to the BGPSEC threat doc 
(draft-ietf-sidr-bgpsec-threats-05), which is now
in the hands of the RTG ADs, as an example of what I have in mind. It 
addresses a
fairly complex, global system, so I would not expect an analogous doc 
for STIR
to be any longer.

Steve