Subject: Re: [stir] Comments on draft-ietf-stir-certificates-09

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Mar 2017 16:20:28 -0700

>
> You don't define the semantics of TelephoneNumberRange. This seems
> like it's potentially subtle. The natural design seems like you
> would interpret start as if it were an integer and then allow
> everything in the range [start, start + count ). However, aren't
> there edge cases here. Consider the field that contains:
>
>   { +1.999.999.9999, 2 }  // punctuation added for clarity.
>
> Clearly, +1.999.999.9999 is permitted, but are there any other
> numbers permitted? My algorithm above would include
> +2.000.000.0000, but that's clearly not right. Does it wrap
> so that it includes +1.000.000.0000? Seems like some text
> is required here.
>

In reading -12, this does not seem to be adjusted :)

-Ekr

>
> S 10.
>    The tradeoff between short lived certificates and using status
>    information is that the former’s burden is on the front end (i.e.,
>    enrollment) and the latter’s burden is on the back end (i.e.,
>    verification).  Both impact call setup time, but it is assumed that
>    generating a short-lived certificate for each call, and consequently
>    performing enrollment for each call, is more of an impact than
>    acquiring status information.
>
> This seems to confuse enrollment with certificate issuance. However,
> at least in protocols like ACME, that's not correct: you enroll
> once and then you can get as many certs issued as you want within
> a time window. It's not clear why this would be a bigger issue
> than OCSP, and there are obvious latency advantages because you
> can get a new cert at the start of dialing (i.e., before the
> destination number is known).
>
> You are also ignoring the possibility of OCSP stapling, which
> would seem to resolve both concerns. It seems like it would
> be good to specify this mode.
>
>
> S 10.2.
>    The requirement to consult OCSP in real time results in a network
>    round-trip time of day,
>
> Should this say "delay"?
>
>
> S 10.2.1.
> Am I supposed to be getting here that you are importing a bunch of
> the HVE requirements, but you don't want to directly refer to HVE
> because of the requirement to not use per-request extensions. Is
> that right? If so, maybe it would be better to normatively reference
> the spec and then override it.
>
>
> S 10.3.
> How does the mechanism described in this section interact with TN
> lists that are in the cert? Or do you only use it if you have the
> spid form?
>
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 24 Mar 2017 21:24:43 +0000

I’d note that I am not aware of any standard that defines that telephone numbers have a sequence. Further it should be remembered that it is convention in some countries only that telephone numbers might have a fixed length from a common root.

Therefore rather than talking about a block or a range of numbers, it would be better to talk about numbers with a common set of most significate digits, with posibly the next digit being a subset of the full digits 0 through 9, and so on.

Regards

Keith

From: stir [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: 23 March 2017 23:20
To: [email-masked]
Subject: Re: [stir] Comments on draft-ietf-stir-certificates-09

-Ekr

S 10.

S 10.2.

Should this say "delay"?

S 10.2.1.

S 10.3.

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 27 Mar 2017 05:22:20 -0400

<advocacy>

http://www.circleid.com/posts/20170324_use_stix_to_block_robocalls/

The blog is self explanatory, but seems worth
considering at the IETF STIR session on Thursday.
There are alternatives such as STIX that seem
far more effective, global, flexible, scaleable,
and contemporary.  They also involve less
"governance" and are less anti-competitive.
Robo/spoof call ISACs using STIR are an ideal
solution.

That's all the IETF STIR group needs to do is
work with OASIS CTI and recognize there are
other approaches!

</advocacy>

--tony