Subject: [stir] Key query/validation

From: Dave Crocker <[email-masked]>
Date: Sat, 20 Aug 2016 11:53:19 -0700

The current status of the STIR technical specifications for the 
mechanism(s) to find, obtain, and validate keys is extremely incomplete. 
  This is distinct from the operations and policy issues the build upon 
the technical specifications.

      1. draft-ietf-stir-cert is a discussion piece, not a specification.

         And, yes, it really is that basic a problem with the document. 
It has a couple of brief meta-syntax segments intended to be 
specifications of a couple of things, but even these are inadequately 
documented, nevermind the rest of the surrounding mechanism(s).

      2. CAs and X.509 are problematic.

         It appears that the group has viewed saying "CA" and "X.509" as 
sufficient technical detail to fill portion of the system specification 
that covers finding and validating keys.  It doesn't, and not the least 
of which is because the extant CA usage has a long and storied history 
of very serious problems.

         While, yes, there are also examples of their substantive use, 
they are constrained. For serious reliance on certification semantic, I 
believe they are only successful in closed systems.[*]  Is that the goal 
for STIR?  To the extent that there is an operational target for STIR 
that is amenable to this track record, it hasn't been documented.

      3. STIR's differential handling of SIP addressing, using domain 
names vs telephone numbers, is confusing at best. It needs to be 
substantially consolidated and clarified, with clean interfaces to that 
consolidation, so the rest of the documentation doesn't have to know or 
care about the difference.

d/

[*] Use of certs for the web are famously problematic.  First, the only 
serious reliance on them is to prevent MITM attacks.  Second, are all of 
the operational problems with root CAs.  Third are all the times sites 
do self-signing.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 21 Aug 2016 06:50:26 -0700

On Sat, Aug 20, 2016 at 11:53 AM, Dave Crocker <[email-masked]> wrote:
> the operational problems with root CAs.  Third are all the times sites do
> self-signing.

I'm not sure I understand this argument.

1. I'm not quite sure what you mean when you say that the only serious
reliance of Web certificates is to prevent MITM attacks. In general, the
purpose of Web certificates is to authenticate the endpoints involved in
the HTTPS connection, thus preventing attackers from impersonating one of
those endpoints (whether the attacker then does an MITM attack or some
other attack is kind of a detail; for instance an attacker might just
impersonate a site without ever connecting to it). What purpose would you
expect these certificates to serve that they are not serving?

2. It's certainly true that there have been a number of high-profile
instances of misissuance by trust anchors, but I'm not sure that this
speaks as much to inherent problems of PKI as to the scale of the Web PKI
and the number of trust anchors in the system.

3. I'm not sure how self-signing comes into things; self-signing is largely
a response to difficulty in obtaining valid certs. My understanding was
that STIR was going to have a more straightforward (and initially less
distributed) issuance story.

More generally, if STIR authentication merely worked almost as well as the
Web PKI, that seems like it would be pretty significant improvement over
the current situation.

-Ekr

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 Aug 2016 08:59:33 -0700

Eric, et al,

On 8/21/2016 6:50 AM, Eric Rescorla wrote:
> On Sat, Aug 20, 2016 at 11:53 AM, Dave Crocker <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     [*] Use of certs for the web are famously problematic.  First, the
>     only serious reliance on them is to prevent MITM attacks.  Second,
>     are all of the operational problems with root CAs.  Third are all
>     the times sites do self-signing.
...
> the HTTPS connection, thus preventing attackers from impersonating one
> of those endpoints (whether the attacker then does an MITM attack or
> some other attack is kind of a detail; for instance an attacker might
> just impersonate a site without ever connecting to it). What purpose
> would you expect these certificates to serve that they are not serving?

First, apologies; my comment was much too cryptic.  Second, my comment 
was on current operational realities, whereas your response started by 
noting intent.  This disparity evokes the cliche about the difference 
between theory and practice.

Now to be less cryptic:

The TLS specification supports server authentication, client 
authentication and channel encryption.  Its primary use, at scale, is 
only for encryption.  Server authentication is performed, if possible, 
but only to make the encryption protect against man-in-the-middle 
attacks.  (My understanding is that client authentication has no 
significant use.) Absent that authentication, opportunistic encryption 
protects against passive wiretapping but not MITM.  Hence my previous, 
cryptic summary.

As for serving other purposes, certs are also used to validate the 
target (server) domain name in a web session -- that is, it the obtained 
server authorized under the domain name used by the client.  While I 
believe that the mechanisms for this are in relatively widescale use, 
there's been little-to-no demonstrated efficacy, which limits the amount 
people attend to any possible problems with the certs. (Why spend time 
worrying about something that isn't useful?) There are also the 
significant domain name matching problems with the mechanism, prompting 
a significant revision effort.  I haven't been its status, but the work 
is recent.

Certs are also used for OAUTH, which looks like large scale use but is 
only large-scale on the client-side and rather tiny scale at the side of 
the services getting validated. Worse, I believe these are all 
pre-registered with any server choosing to emply oauth.

Over the open Internet, at scale, I'm not aware of other significant 
uses of certs.

> speaks as much to inherent problems of PKI as to the scale of the Web
> PKI and the number of trust anchors in the system.

Therein likes a really basic disconnect between the security technical 
community and the real world.  1) The history appears to be much worse 
than you indicate[*]. 2) Your comment appears to imply exclusion of 
human factors from analysis of cert issues.

In fact, the root -- well, actually, 'bush' -- cert system has so far 
demonstrated a failure to be safe or manageable. And the end-user 
experience with certs remains much worse than problematic.

By the way, the ATIS-SIPforum texts I've seen about use of certs appears 
to only cover North America.  What is the operational model for certs 
planned for global use?

> 3. I'm not sure how self-signing comes into things; self-signing is
> largely a response to difficulty in obtaining valid certs. My
> understanding was that STIR was going to have a more straightforward
> (and initially less distributed) issuance story.

I was noting an operational reality, in the environment that is the 
largest users of certs.  It is the ultimate demonstration of the failure 
of that model.

My point is not that STIR can't work around it but that STIR has not 
documented any of the design issues and has not specified any 
operational constraints for ensuring success.  Hence, whether STIR can 
produce acceptable use of certs is currently unknowable, but should be 
counted as high risk, IMO.

> More generally, if STIR authentication merely worked almost as well as
> the Web PKI, that seems like it would be pretty significant improvement
> over the current situation.

That does sound appealing, doesn't it?

Except that I believe there is no documentation to support even this 
modest a claim of efficacy, while there is quite a bit of documentation 
of failures and problems with Web PKI.

d/
-- 

   Dave Crocker

---

From: Brian Rosen <[email-masked]>
Date: Mon, 22 Aug 2016 12:14:47 -0400

The primary premise of stir is that in every country, there exists a delegation process for telephone numbers.  It can be multi-step, it can be formal, informal, or most commonly, a combination.

The root of trust for every country is the regulator.  They are the ultimate source of telephone numbers for that country code (there are some more complex issues for country codes like +1 that encompass more than one regulator, but the formal delegation processes for TNs in those cases are well controlled).  In every country, the first delegation is a formal delegation: the regulator or some entity operating on behalf of the regulator is delegated a block of numbers.  From there, delegation processes vary, and they can include number portability (which is a delegation of a single TN from one service provider to another).  

Our premise is that issuance of certs follows the delegation process.  When you delegate, a cert is issued (or the scope of an existing cert is changed). 

The goal to to provide authenticated source of calls, but in reality, what we need is a way for the authorities to find bad actors.  By making the PKI follow the delegation path, you end up with someone holding the bag.  If a delegation was made to someone who is a bad actor, then either the bad actor can be identified, or the entity who did the delegation to someone who was the bad actor is left with the bag.  Everyone can make mistakes, but if the authorities keep finding the same service provider not being able to identify their bad actor customers, then steps can be taken to address the situation.

I believe that’s deployable at scale.

Brian

> On Aug 22, 2016, at 11:59 AM, Dave Crocker <[email-masked]> wrote:
> 
> Eric, et al,
> 
> First, apologies; my comment was much too cryptic.  Second, my comment was on current operational realities, whereas your response started by noting intent.  This disparity evokes the cliche about the difference between theory and practice.
> 
> Now to be less cryptic:
> 
> The TLS specification supports server authentication, client authentication and channel encryption.  Its primary use, at scale, is only for encryption.  Server authentication is performed, if possible, but only to make the encryption protect against man-in-the-middle attacks.  (My understanding is that client authentication has no significant use.) Absent that authentication, opportunistic encryption protects against passive wiretapping but not MITM.  Hence my previous, cryptic summary.
> 
> As for serving other purposes, certs are also used to validate the target (server) domain name in a web session -- that is, it the obtained server authorized under the domain name used by the client.  While I believe that the mechanisms for this are in relatively widescale use, there's been little-to-no demonstrated efficacy, which limits the amount people attend to any possible problems with the certs. (Why spend time worrying about something that isn't useful?) There are also the significant domain name matching problems with the mechanism, prompting a significant revision effort.  I haven't been its status, but the work is recent.
> 
> Certs are also used for OAUTH, which looks like large scale use but is only large-scale on the client-side and rather tiny scale at the side of the services getting validated. Worse, I believe these are all pre-registered with any server choosing to emply oauth.
> 
> Over the open Internet, at scale, I'm not aware of other significant uses of certs.
> 
> 
> Therein likes a really basic disconnect between the security technical community and the real world.  1) The history appears to be much worse than you indicate[*]. 2) Your comment appears to imply exclusion of human factors from analysis of cert issues.
> 
> In fact, the root -- well, actually, 'bush' -- cert system has so far demonstrated a failure to be safe or manageable. And the end-user experience with certs remains much worse than problematic.
> 
> By the way, the ATIS-SIPforum texts I've seen about use of certs appears to only cover North America.  What is the operational model for certs planned for global use?
> 
> 
> I was noting an operational reality, in the environment that is the largest users of certs.  It is the ultimate demonstration of the failure of that model.
> 
> My point is not that STIR can't work around it but that STIR has not documented any of the design issues and has not specified any operational constraints for ensuring success.  Hence, whether STIR can produce acceptable use of certs is currently unknowable, but should be counted as high risk, IMO.
> 
> 
> 
> Except that I believe there is no documentation to support even this modest a claim of efficacy, while there is quite a bit of documentation of failures and problems with Web PKI.
> 
> 
> d/
> -- 
> 
>  Dave Crocker

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Aug 2016 09:26:04 -0700

On Mon, Aug 22, 2016 at 8:59 AM, Dave Crocker <[email-masked]> wrote:

> First, apologies; my comment was much too cryptic.  Second, my comment was
> on current operational realities, whereas your response started by noting
> intent.

Thanks for clarifying. Responses below.

> This disparity evokes the cliche about the difference between theory and
> practice.
>
> Now to be less cryptic:
>
> authentication and channel encryption.  Its primary use, at scale, is only
> for encryption.  Server authentication is performed, if possible, but only
> to make the encryption protect against man-in-the-middle attacks.  (My
> understanding is that client authentication has no significant use.) Absent
> that authentication, opportunistic encryption protects against passive
> wiretapping but not MITM.  Hence my previous, cryptic summary.

I don't believe that this is an accurate summary of the situation.
Certificates are routinely used for server authentication in settings where
the primary target is not confidentiality of the traffic but rather
integrity of the data between the server and the client (or vice versa). A
typical example would be software download (or alternately, embedding of JS
libraries into Web applications) where it's obviously important that the
user get the software they intended. As a specific example, Mozilla
distributes Firefox over HTTPS not because Firefox is secret but because we
don't want attackers tampering with it. Encryption is generally used in
those scenarios as well merely because that's how TLS is customarily
operated, but primary target is integrity/data origin authentication.

I'm not sure what you would consider "significant" use of client
authentication but I can tell you that it's in sufficiently wide use that
we had to make special accommodations in TLS 1.3 for some variants of
client auth because it was so important in enterprise use cases.

Incidentally, it would probably be helpful here to avoid the use of the
term "MITM". I appreciate that that terminology once had wide currency, but
it really only refers to a specific class of impersonation attack, and not
necessarily the one of interest. For instance, if I impersonate Mozilla and
send you malware instead of Firefox, I don't need to connect to Mozilla's
server, so it's not really a MITM Attack, just server impersonation.

As for serving other purposes, certs are also used to validate the target
> (server) domain name in a web session -- that is, it the obtained server
> authorized under the domain name used by the client.  While I believe that
> the mechanisms for this are in relatively widescale use, there's been
> little-to-no demonstrated efficacy, which limits the amount people attend
> to any possible problems with the certs. (Why spend time worrying about
> something that isn't useful?) There are also the significant domain name
> matching problems with the mechanism, prompting a significant revision
> effort.  I haven't been its status, but the work is recent.
>

This seems to be raising a separate question, namely whether the Web PKI
system actually meaningfully achieves its security goals. I'm not aware of
any definitive research in this area, however, I also think it's fair to
say that HTTPS is widely considered to be best practice and that both
browser vendors and TLS implementors take authentication failures seriously.

> community and the real world.  1) The history appears to be much worse than
> you indicate[*].

Does this footnote go somewhere?

> 2) Your comment appears to imply exclusion of human factors from analysis
> of cert issues.
>

Hmm... Can you elaborate on this?

> largest users of certs.  It is the ultimate demonstration of the failure of
> that model.
>

I'm going to have to differ here. I certainly wouldn't argue that the Web
PKI system is perfect, but it has also become vastly easier to obtain and
deploy certificates (thanks in large part to efforts like Let's Encrypt,
SSLmate, Caddy, and Amazon's CA), and our telemetry shows that we're
approaching 50% of browser transactions being HTTPS, despite the browsers
strongly discouraging self-signed certs so I think "ultimate demonstration
of the failure" somewhat overstates things.

> modest a claim of efficacy, while there is quite a bit of documentation of
> failures and problems with Web PKI.

Hmm.... What kind of documentation would you consider to support this kind
of claim (leaving aside the question of whether such documentation exists).

-Ekr

---

From: Dave Crocker <[email-masked]>
Date: Tue, 23 Aug 2016 20:49:01 -0700

Eric,

On 8/22/2016 9:26 AM, Eric Rescorla wrote:
> On Mon, Aug 22, 2016 at 8:59 AM, Dave Crocker <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>     First, apologies; my comment was much too cryptic.  Second, my
>     comment was on current operational realities, whereas your response
>     started by noting intent.
>
>     This disparity evokes the cliche about the difference between theory
>     and practice.
>
>     Now to be less cryptic:
>
>     authentication and channel encryption.  Its primary use, at scale,
>     is only for encryption.  Server authentication is performed, if
>     possible, but only to make the encryption protect against
>     man-in-the-middle attacks.  (My understanding is that client
>     authentication has no significant use.) Absent that authentication,
>     opportunistic encryption protects against passive wiretapping but
>     not MITM.  Hence my previous, cryptic summary.
>
> Certificates are routinely used for server authentication in settings
> where the primary target is not confidentiality of the traffic but
> rather integrity of the data between the server and the client (or vice
> versa). A typical example would be software download (or alternately,
> embedding of JS libraries into Web applications) where it's obviously
> important that the user get the software they intended. As a specific
> example, Mozilla distributes Firefox over HTTPS not because Firefox is
> secret but because we don't want attackers tampering with it. Encryption
> is generally used in those scenarios as well merely because that's how
> TLS is customarily operated, but primary target is integrity/data origin
> authentication.

So, yes, I take your point, although there's some irony to your 
explanation.  Your example for data integrity is concern with tampering. 
  Discounting my imprecision in saying "MITM" that you note, I believe 
your example falls under that very same concern as the one I expressed...

> authentication but I can tell you that it's in sufficiently wide use
> that we had to make special accommodations in TLS 1.3 for some variants
> of client auth because it was so important in enterprise use cases.

Dandy.  Let's see some citations for its successful and continuing use 
at scale over the open Internet (ie, with lots of independent 
administrations.)

> term "MITM". I appreciate that that terminology once had wide currency,
> but it really only refers to a specific class of impersonation attack,
> and not necessarily the one of interest. For instance, if I impersonate
> Mozilla and send you malware instead of Firefox, I don't need to connect
> to Mozilla's server, so it's not really a MITM Attack, just server
> impersonation.

Point taken.  And for careful technical discussions about very specific 
attack vectors and mitigation strategies, careful labeling is of course 
essential.

My casual use of MITM was actually meant to refer to 'anything that has 
an active attacker participating in the data stream with the client, at 
the level of generating responses'.  (Otherwise, it's just passive 
monitoring.)

It would be nice to have a single term that covers MITM and server 
compromise.

>     target (server) domain name in a web session -- that is, it the
>     obtained server authorized under the domain name used by the
>     client.  While I believe that the mechanisms for this are in
>     relatively widescale use, there's been little-to-no demonstrated
>     efficacy, which limits the amount people attend to any possible
>     problems with the certs. (Why spend time worrying about something
>     that isn't useful?) There are also the significant domain name
>     matching problems with the mechanism, prompting a significant
>     revision effort.  I haven't been its status, but the work is recent.
>
> system actually meaningfully achieves its security goals. I'm not aware

Well, 'efficacy' is meant in a somewhat higher-level way.  Is the nature 
of the use of that authentication -- that is, the consumption of the 
produced data -- at at least the same level of trust as is being 
targeted here?

If the goal here is for use that requires more trust that that 
established use -- e.g., greater downside if there is a problem -- then 
established use isn't comparable.

> of any definitive research in this area, however, I also think it's fair
> to say that HTTPS is widely considered to be best practice and that both

Sure.  For protecting against wiretapping and MITM attacks. (Except for 
one of the many servers that self-sign their cert, in which case MITM 
protection is largely absent.)

>     Therein likes a really basic disconnect between the security
>     technical community and the real world.  1) The history appears to
>     be much worse than you indicate[*].
>
>
>

darn.  yes.  sorry.  see below.[*]

>     2) Your comment appears to imply exclusion of human factors from
>     analysis of cert issues.
>
>

There are serious and continuing problems with the global operations of 
CA roots -- that's a human factor.

There is large-scale use of self-signing certs, indicating a major and 
widespread hole in the official 'CA root' model -- that's a human factor.

Analysis of working systems needs to treat all of the human actors as 
part of that working system.  If there are serious and/or persistent 
problems with those folk, then there is a serious or persistent problem 
with the system.

>     largest users of certs.  It is the ultimate demonstration of the
>     failure of that model.
>
>
> I'm going to have to differ here. I certainly wouldn't argue that the
> Web PKI system is perfect, but it has also become vastly easier to
> obtain and deploy certificates (thanks in large part to efforts like
> Let's Encrypt, SSLmate, Caddy, and Amazon's CA), and our telemetry shows
> that we're approaching 50% of browser transactions being HTTPS, despite
> the browsers strongly discouraging self-signed certs so I think
> "ultimate demonstration of the failure" somewhat overstates things.

I note that you don't offer a metric on the amount of self-signing that 
is done.

>         over the current situation.>
>     modest a claim of efficacy, while there is quite a bit of
>     documentation of failures and problems with Web PKI.
>
> Hmm.... What kind of documentation would you consider to support this
> kind of claim (leaving aside the question of whether such documentation
> exists).

Reports of tiger team efforts to crack a variety of web traffic -- and 
failing -- would be nice.  Certainly it would be nice to hear fewer 
stories about server data bases getting compromised.

My point is that from what I can tell, most of the confidence in the Web 
PKI system comes from theoretical analysis rather than active 
operational measurement.

d/

[*]  A few articles on certs:

    o Phishing sites exploit trust in valid SSL certificates

      http://www.infoworld.com/article/2992605/security/phishing-sites-
      exploit-trust-in-valid-ssl-certificates.html

    o Microsoft move to revoke trust in 20 root certificates could wreak
      havoc on sites

      http://www.pcworld.com/article/3017157/security/microsoft-move-to-
      revoke-trust-in-20-root-certificates-could-wreak-havoc-
      on-sites.html

    o What You Should, But Don't, Do About Untrusted Certs, CAs

      http://www.darkreading.com/cloud/what-you-should-but-dont-do-about-
      untrusted-certs-cas-/d/d-id/1322111

    o IT pros don't get cybersecurity risks around certificate
      authorities

      http://searchsecurity.techtarget.com/news/4500253216/IT-pros-
      dont-get-cybersecurity-risks-around-certificate-authorities

    o What you need to know about Dell's root certificate security
      debacle

      http://www.infoworld.com/article/3008422/security/what-you-need-
      to-know-about-dells-root-certificate-security-debacle.html

-- 

   Dave Crocker

-- 

   Dave Crocker

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Aug 2016 16:10:46 -0700

Top-posting with my summary, detailed comments below.

It's probably useful to separate out two questions:

- What security properties people are relying on TLS to give them and what
operational scenarios it is being used in.
- What security properties people are actually getting from TLS in practice.

I think it's clear from what I wrote previously and below that people are
on a wide scale are relying on TLS and the Web PKI to provide the following
features:

- Server authentication
- Confidentiality
- Integrity

As you suggest, they are not generally relying on the Web PKI to provide
client authentication; client authentication is usually provided by sending
secrets (e.g., passwords) over the TLS channel, thus relying on the
previous three properties.

I'm not quite sure if you're arguing that people aren't relying on TLS for
those properties, but if you are, I don't think that's correct.

Rather, I take you to be arguing that those properties are illusory because
the Web PKI doesn't actually provide them. I think you're on somewhat
stronger ground there though; it's clear that the Web PKI could work
better, hence active efforts to improve it along the lines of Let's
Encrypt, Certificate Transparency, and ongoing coordination between the
major root programs. With that said, I do think that TLS and the WebPKI are
providing substantial security here over and above not having them, though
I don't think we have anything that would meet a medical standard of proof
to that effect.

Best,,
-Ekr

On Tue, Aug 23, 2016 at 8:49 PM, Dave Crocker <[email-masked]> wrote:

> Discounting my imprecision in saying "MITM" that you note, I believe your
> example falls under that very same concern as the one I expressed...

Sorry, but I'm puzzled. The threat in question here is active attack, not
passive one.

> Dandy.  Let's see some citations for its successful and continuing use at
> scale over the open Internet (ie, with lots of independent administrations.)

Hmm... We're probably talking past each other here, which may be my fault.
The typical TLS client auth scenario is as
follows:

- The server is authenticated with a WebPKI cert.
- The client is authenticated with some locally issued cert.

So the server authentication scenario is the usual one and the client
essentially has one consumer
and one administrator.

> My casual use of MITM was actually meant to refer to 'anything that has an
> active attacker participating in the data stream with the client, at the
> level of generating responses'.  (Otherwise, it's just passive monitoring.)
>

If you mean "server impersonation" here, then the term you are looking for
is "active attack".
See https://tools.ietf.org/rfcmarkup?doc=3552#section-3.3

> produced data -- at at least the same level of trust as is being targeted
> here?
>
> If the goal here is for use that requires more trust that that established
> use -- e.g., greater downside if there is a problem -- then established use
> isn't comparable.

I suspect that the information being protected is generally of higher value
given that we're talking about electronic banking, e-health etc. And of
course  the base case for STIR deployment is going to be that the existence
of the call is authenticated but then that the actual call is in the clear,
though we eventually hope to do better than that.

> I note that you don't offer a metric on the amount of self-signing that is
> done.

Yeah, I didn't have it to hand, but I've looked since.

Our telemetry shows that around 10% of TLS validations (more in beta, less
in release) is by "non-default roots", which (I believe, but haven't
completely validated) lumps in enterprise MITM boxes, enterprise CAs, and
end-entity certs which don't chain to any valid CA. I believe that the
latter category is what you mean by "self-signed". (Technically self-signed
is just a description of the relationship between the subject and issuer of
the certificate and it's common, for instance, to package CA certificates
as self-signed certs, but that's not really the topic at hand). In any
case, as far as I can tell, the vast majority of TLS connections go to
valid WebPKI certs.

        More generally, if STIR authentication merely worked almost as
>>         well as
> failing -- would be nice.

I'm not sure what you mean here. There has been an enormous amount of
research on attacking TLS and TLS stacks, some of it successful and some of
it not, and some of the things they found were big and have been fixed and
some of the things they found were small and have not. But I think it gives
a pretty clear picture of the security of TLS per se. If you mean efforts
to obtain WebPKI certs and failing, that's obviously a harder problem to
analyze

> Certainly it would be nice to hear fewer stories about server data bases
> getting compromised.
>

I'm not sure I'm seeing the connection here. Even a perfect WebPKI wouldn't
do much to prevent server compromise because that's generally a result of
vulnerabilities in the server of one kind or another, not of the
cryptographic protocols deployed by the server.

-Ekr

> [*]  A few articles on certs:

Thanks for providing these.  I don't think they actually tell us much about
the question at hand.

>      exploit-trust-in-valid-ssl-certificates.html

This article is about people misunderstanding valid TLS connections as
meaning that the site can be trusted. Unfortunate, but it's the WebPKI
behaving as intended. Arguably a browser UI failure.

>      revoke-trust-in-20-root-certificates-could-wreak-havoc-

This article seems to be more or less about routine pruning of the browser
trust anchor lists. As I think I observed previously, large trust anchor
lists are in fact a problem (hence efforts like CT, etc.). However, this
again seems to be the system operating as intended, namely the trust anchor
lists being curated.

>      untrusted-certs-cas-/d/d-id/1322111

This article seems to be an overview of the known threats. I think we've
mostly recapped these here.

>      dont-get-cybersecurity-risks-around-certificate-authorities

I can't read this, but it looks like it's reporting on the same survey as
the one above.

>      to-know-about-dells-root-certificate-security-debacle.html

This is an interesting case, but I don't see it really reflecting much on
the PKI. Effectively, Dell installed a MITM proxy (in the precise sense of
MITM that we generally use in the security community) on their boxes before
shipping them. This proxy operated (as most do) by installing their own
trust anchor on the box, but that's just one form of attack you can do if
you control the user's computer (see https://www.chromium.org/
Home/chromium-security/security-faq)

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Aug 2016 20:47:38 -0700

Eric,

On 8/25/2016 4:10 PM, Eric Rescorla wrote:
> - What security properties people are relying on TLS to give them and
> what operational scenarios it is being used in.
> I think it's clear from what I wrote previously and below that people
> are on a wide scale are relying on TLS and the Web PKI to provide the
> following features:
>
> - Server authentication
> - Confidentiality
> - Integrity

Yes.

> I'm not quite sure if you're arguing that people aren't relying on TLS
> for those properties, but if you are, I don't think that's correct.

I'm not arguing that.  And to carry this further, I'm not expressing 
concern about the mathematics of these mechanisms.  That is, the 
underlying components appear to do what they are supposed to.

> Rather, I take you to be arguing that those properties are illusory
> because the Web PKI doesn't actually provide them.

Not quite, though maybe somewhat.  And I would not phrase it as "Web PKI 
doesn't actually provide them".

The wording would be more along the lines of:  The human factors 
challenges of getting and using Web PKI produce significant and frequent 
limitations in the operation of the Web's security service.  In the 
aggregate, the limitations produce an overall system performance that is 
significantly different from what is typically promised.

The very large number of CA roots has a continuing problem with some roots.

The challenges of getting a cert has encouraged self-signed certs, and 
opportunistic encryption, which defeats the trust hierarchy.  The 
efforts you cite to make it easier to get certs is -- from what I'm 
hearing -- improving the statistics.  But still it is quite common to 
encounter an exception due to a self-signing cert.  It's probably not 
excessive to guess that this is at least a daily occurrence for many folk.

Limitations in the cert model also create failure scenarios, notably 
when the contacted host operates under a different domain name and/or 
administrative structure, than the user asked for, such as due to a 
redirect.  Again, there are efforts to counter this, but I believe they 
aren't fielded yet, so we need to be careful about minimizing the 
real-world effect.[*]

>With that said, I do think that TLS and the WebPKI
> are providing substantial security here over and above not having them,
> though I don't think we have anything that would meet a medical standard
> of proof to that effect.

My concern is not whether Web PKI is useful but whether there has been a 
diligent consideration of its real-world problems in relation to its 
application to a STIR service.

 From what I've seen, it has been embraced without that careful analysis.

But I'd be quite glad to be wrong about this.  So a pointer to that 
analysis -- a warts-and-all pragmatic assessment -- would be greatly 
appreciated.

(A basic challenge in developing such an analysis is that it requires 
having a clear, concrete, concise and consensus-based specification for 
the administrative and operational characteristics for STIR, but there 
isn't one.)

d/

[*] Possibly ironically, this includes the ietf.org site, I discovered 
this morning. Going to page:

    https://xml2rfc.ietf.org/wg/dkim/trac/ticket/8

I got:

> Your connection is not secure
>
> The owner of xml2rfc.ietf.org has configured their website
> improperly. To protect your information from being stolen, Firefox
> has not connected to this website. and xml2rfc.ietf.org uses an
> invalid security certificate.
...

The problem is that http://xml2rfc.ietf.org/ now redirects to 
https://xml2rfc.tools.ietf.org/, which is under independent 
administration.  The former is the Secretariat, while the latter is the 
tools team.  The administrative separation is deemed appropriate, but it 
creates this problem.

-- 

   Dave Crocker

---

From: Richard Shockey <[email-masked]>
Date: Fri, 26 Aug 2016 01:17:16 -0400

Ekr…

I simply going to say what should be obvious at this point.

In the first order implementation of the STIR/SHAKEN concept the root trust authority for certificates bound to TN’s or ranges of TN will be a closed system.  Certainly in North America and I’ll bet that is how it rolls out in Europe/Asia. A system that will have to be agreed to by the “powers that be”.  I think I made that clear from my PPT I posted earlier. 

To restate the obvious. “This is Telephony,  Not the Internet.”   Is that Shockey’s Third Law?  1.  Money is the answer what is the question 2 The network is landline everything else is access.”

That is actually a subtle distinction that is not well understood by some. I know some of our mutual friends think we need to “democratize real-time communications” and some are resentful that the entire SIP construct was essentially lifted by the IMS folks to reconstruct the PSTN on IP Transport protocols.  Well we are not going to go over that ancient history either. 

We are all aware of industry specific root trust authorities that have scaled to the zillions. Think cable set top boxes, electric utility meters, credit cards etc.  I am doing my best to hold my fingers back from truly epic rant at the same time Dave and others do have some ..some legitimate points but there is a new process in place now and we in the IETF have a role. A valuable role, but NOT THE ONLY ROLE. The great wheels of progress have been set in motion by the FCC and the Strike Force and IMHO there is something that looks like a rational plan to satisfy the goals and objectives of not only our US Regulatory friends and colleagues but other NRA as well.

IMHO the root trust decision has been made.  As Brian Rosen ( to his eternal credit THANK YOU BRIAN)  has pointed out the delegation authority for those identifiers is a well understood legal and regulatory construct in every nation state on the planet. 

Many of our colleagues on this list have has endless sleepless nights trying to understand and design all of this as a system.  The best task for this WG is to encourage our document editors to make their documents A. more readable B more implementable (examples) and we just move on. 

Noise is not helpful but OK whatever. It’s the IETF after all. 

— 

Richard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shockey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook rshockey101

PSTN +1 703-593-2683

From: stir <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Date: Thursday, August 25, 2016 at 7:10 PM
To: Dave Crocker <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [stir] Key query/validation

- What security properties people are relying on TLS to give them and what operational scenarios it is being used in.

I think it's clear from what I wrote previously and below that people are on a wide scale are relying on TLS and the Web PKI to provide the following features:

- Server authentication

- Confidentiality

- Integrity

As you suggest, they are not generally relying on the Web PKI to provide client authentication; client authentication is usually provided by sending secrets (e.g., passwords) over the TLS channel, thus relying on the previous three properties.

I'm not quite sure if you're arguing that people aren't relying on TLS for those properties, but if you are, I don't think that's correct.

Rather, I take you to be arguing that those properties are illusory because the Web PKI doesn't actually provide them. I think you're on somewhat stronger ground there though; it's clear that the Web PKI could work better, hence active efforts to improve it along the lines of Let's Encrypt, Certificate Transparency, and ongoing coordination between the major root programs. With that said, I do think that TLS and the WebPKI are providing substantial security here over and above not having them, though I don't think we have anything that would meet a medical standard of proof to that effect.

Best,,

-Ekr

Eric,

    Eric, et al,

            [*] Use of certs for the web are famously problematic.
        First, the
            only serious reliance on them is to prevent MITM attacks.
        Second,
            are all of the operational problems with root CAs.  Third
        are all
            the times sites do self-signing.
    ...

        1. I'm not quite sure what you mean when you say that the only
        serious
        reliance of Web certificates is to prevent MITM attacks. In
        general, the
        purpose of Web certificates is to authenticate the endpoints
        involved in
        the HTTPS connection, thus preventing attackers from
        impersonating one
        of those endpoints (whether the attacker then does an MITM attack or
        some other attack is kind of a detail; for instance an attacker
        might
        just impersonate a site without ever connecting to it). What purpose
        would you expect these certificates to serve that they are not
        serving?

    Now to be less cryptic:

So, yes, I take your point, although there's some irony to your explanation.  Your example for data integrity is concern with tampering.  Discounting my imprecision in saying "MITM" that you note, I believe your example falls under that very same concern as the one I expressed...

Sorry, but I'm puzzled. The threat in question here is active attack, not passive one.

Dandy.  Let's see some citations for its successful and continuing use at scale over the open Internet (ie, with lots of independent administrations.)

Hmm... We're probably talking past each other here, which may be my fault. The typical TLS client auth scenario is as

follows:

So the server authentication scenario is the usual one and the client essentially has one consumer

and one administrator. 

Point taken.  And for careful technical discussions about very specific attack vectors and mitigation strategies, careful labeling is of course essential.

My casual use of MITM was actually meant to refer to 'anything that has an active attacker participating in the data stream with the client, at the level of generating responses'.  (Otherwise, it's just passive monitoring.)

It would be nice to have a single term that covers MITM and server compromise.

If you mean "server impersonation" here, then the term you are looking for is "active attack".

 

Well, 'efficacy' is meant in a somewhat higher-level way.  Is the nature of the use of that authentication -- that is, the consumption of the produced data -- at at least the same level of trust as is being targeted here?

If the goal here is for use that requires more trust that that established use -- e.g., greater downside if there is a problem -- then established use isn't comparable.

I suspect that the information being protected is generally of higher value given that we're talking about electronic banking, e-health etc. And of course  the base case for STIR deployment is going to be that the existence of the call is authenticated but then that the actual call is in the clear, though we eventually hope to do better than that.

I note that you don't offer a metric on the amount of self-signing that is done.

Our telemetry shows that around 10% of TLS validations (more in beta, less in release) is by "non-default roots", which (I believe, but haven't completely validated) lumps in enterprise MITM boxes, enterprise CAs, and end-entity certs which don't chain to any valid CA. I believe that the latter category is what you mean by "self-signed". (Technically self-signed is just a description of the relationship between the subject and issuer of the certificate and it's common, for instance, to package CA certificates as self-signed certs, but that's not really the topic at hand). In any case, as far as I can tell, the vast majority of TLS connections go to valid WebPKI certs.

        More generally, if STIR authentication merely worked almost as
        well as
        the Web PKI, that seems like it would be pretty significant
        improvement
        over the current situation.>
    That does sound appealing, doesn't it?

Reports of tiger team efforts to crack a variety of web traffic -- and failing -- would be nice. 

I'm not sure what you mean here. There has been an enormous amount of research on attacking TLS and TLS stacks, some of it successful and some of it not, and some of the things they found were big and have been fixed and some of the things they found were small and have not. But I think it gives a pretty clear picture of the security of TLS per se. If you mean efforts to obtain WebPKI certs and failing, that's obviously a harder problem to analyze 

Certainly it would be nice to hear fewer stories about server data bases getting compromised.

I'm not sure I'm seeing the connection here. Even a perfect WebPKI wouldn't do much to prevent server compromise because that's generally a result of vulnerabilities in the server of one kind or another, not of the cryptographic protocols deployed by the server.

-Ekr

Thanks for providing these.  I don't think they actually tell us much about the question at hand.

This article is about people misunderstanding valid TLS connections as meaning that the site can be trusted. Unfortunate, but it's the WebPKI behaving as intended. Arguably a browser UI failure.

This article seems to be more or less about routine pruning of the browser trust anchor lists. As I think I observed previously, large trust anchor lists are in fact a problem (hence efforts like CT, etc.). However, this again seems to be the system operating as intended, namely the trust anchor lists being curated.

This article seems to be an overview of the known threats. I think we've mostly recapped these here.

I can't read this, but it looks like it's reporting on the same survey as the one above.

This is an interesting case, but I don't see it really reflecting much on the PKI. Effectively, Dell installed a MITM proxy (in the precise sense of MITM that we generally use in the security community) on their boxes before shipping them. This proxy operated (as most do) by installing their own trust anchor on the box, but that's just one form of attack you can do if you control the user's computer (see https://www.chromium.org/Home/chromium-security/security-faq)

-- 

  Dave Crocker

-- 

  Dave Crocker

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Aug 2016 04:34:23 -0700

On 8/25/2016 10:17 PM, Richard Shockey wrote:
> Dave and others do have some ..some legitimate points

Such as?

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Aug 2016 05:49:16 -0700

Eric,

Hadn't realized that your response included inline comments as well as 
the top-posting.

Responses to the inline comments...

On 8/25/2016 4:10 PM, Eric Rescorla wrote:

> On Tue, Aug 23, 2016 at 8:49 PM, Dave Crocker <[email-masked]
>                 On Sat, Aug 20, 2016 at 11:53 AM, Dave Crocker
>         <[email-masked] <mailto:[email-masked]>
>                 <mailto:[email-masked] <mailto:[email-masked]>>
>                 <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>
>     explanation.  Your example for data integrity is concern with
>     tampering.  Discounting my imprecision in saying "MITM" that you
>     note, I believe your example falls under that very same concern as
>     the one I expressed...
>
>

Exactly.  Your example was about an active attack that modifies data. 
Generically, that's what MITM was/is getting used for (albeit without 
the distinction between coercing the comms data stream versus operating 
on the server.)

(And yes, I see your later clarification that I should have been using 
the term 'active attack' rather than MITM, to cover both server 
compromise and MITM.  Thanks.)

>     Dandy.  Let's see some citations for its successful and continuing
>     use at scale over the open Internet (ie, with lots of independent
>     administrations.)
>
>
> Hmm... We're probably talking past each other here, which may be my
> fault. The typical TLS client auth scenario is as
> follows:
>

With respect to use of TLS for client authentication:  it is not done. 
It's supported in TLS, but not used.  (Unless folk can supply some 
documentation of its use at scale in a multi-administration Internet 
environment.)

Rather, client authentication is a separate function, using a mechanism 
that is independent of TLS.  (The fact that it's running over a 
TLS-protected link does not make it part of TLS.)

>     Point taken.  And for careful technical discussions about very
>     specific attack vectors and mitigation strategies, careful labeling
>     is of course essential.
>
>     My casual use of MITM was actually meant to refer to 'anything that
>     has an active attacker participating in the data stream with the
>     client, at the level of generating responses'.  (Otherwise, it's
>     just passive monitoring.)
>
> <https://tools.ietf.org/rfcmarkup?doc=3552#section-3.3>

dandy.  thanks.

>     Well, 'efficacy' is meant in a somewhat higher-level way.  Is the
>     nature of the use of that authentication -- that is, the consumption
>     of the produced data -- at at least the same level of trust as is
>     being targeted here?
>
>     established use -- e.g., greater downside if there is a problem --
>     then established use isn't comparable.
>
>
> I suspect that the information being protected is generally of higher
> value given that we're talking about electronic banking, e-health etc.
> And of course  the base case for STIR deployment is going to be that the
> existence of the call is authenticated but then that the actual call is
> in the clear, though we eventually hope to do better than that.

The current global reality for TLS is that it is tolerated to operate 
with self-signed certs and constant user overrides of security warnings.

Is that a tolerable mode for STIR?  If it isn't, then what will 
eliminate the problematic operational behaviors.  I think the answer 
implied in various people's comments is that this will be a closed 
system.  Yet that's not documented anywhere except informal emails and 
maybe some powerpoints.

It's an essential design constraint, but it isn't documented.  To the 
extent anyone thinks this now or ever will be open, then it conflicts 
with this reality in Web PKI operational behavior and there needs to be 
a description of how to achieve the improvement.

> Our telemetry shows that around 10% of TLS validations (more in beta,
> less in release) is by "non-default roots", which (I believe, but
> haven't completely validated) lumps in enterprise MITM boxes, enterprise
> CAs, and end-entity certs which don't chain to any valid CA. I believe
> that the latter category is what you mean by "self-signed". (Technically
> self-signed is just a description of the relationship between the
> subject and issuer of the certificate and it's common, for instance, to
> package CA certificates as self-signed certs, but that's not really the
> topic at hand). In any case, as far as I can tell, the vast majority of
> TLS connections go to valid WebPKI certs.

Without worrying about the accuracy or even the precise meaning of the 
statistic, having 10% of a mechanism's use be violation of a fundamental 
operational precept of that mechanism undermines the credibility of that 
mechanism, especially given the sensitive purpose of this particular 
mechanism.

> research on attacking TLS and TLS stacks, some of it successful and some
> of it not, and some of the things they found were big and have been
> fixed and some of the things they found were small and have not. But I
> think it gives a pretty clear picture of the security of TLS per se. If
> you mean efforts to obtain WebPKI certs and failing, that's obviously a
> harder problem to analyze

I was asking a simplistic question:  The claim is that TLS is effective; 
I realize it is a widely-held view.  I was asking for some empirical 
(operational) basis for that assurance.  It's a pretty straightforward 
due-diligence question when choosing to use a critical service.

> I'm not sure I'm seeing the connection here. Even a perfect WebPKI
> wouldn't do much to prevent server compromise because that's generally a
> result of vulnerabilities in the server of one kind or another, not of
> the cryptographic protocols deployed by the server.
>
> -Ekr
>
>
>

ekr, thanks for the following per-article comments, but I'll note that 
the point behind my providing these citations was merely a very quick 
sampling of indications of varied and serious issues in the ongoing use 
of the Web PKI mechanism.  At the least, they ought to create some 
modest caution in adopting the model for a new service.

>     <http://www.infoworld.com/article/2992605/security/phishing-sites->

And again:  human factors (and failings) are part of the system, not 
separate from it.

>     <http://www.pcworld.com/article/3017157/security/microsoft-move-to->
> This article seems to be more or less about routine pruning of the
> browser trust anchor lists. As I think I observed previously, large
> trust anchor lists are in fact a problem (hence efforts like CT, etc.).
> However, this again seems to be the system operating as intended, namely
> the trust anchor lists being curated.

If it were 'as intended' it would not threaten havoc.  Trust anchor list 
pruning has not been part of the presented characteristics of the PKI 
model for typical presentations, nor for public operational models using 
PKI.

>     <http://www.darkreading.com/cloud/what-you-should-but-dont-do-about->
>     <http://searchsecurity.techtarget.com/news/4500253216/IT-pros->
>     <http://www.infoworld.com/article/3008422/security/what-you-need->
> This is an interesting case, but I don't see it really reflecting much
> on the PKI. Effectively, Dell installed a MITM proxy (in the precise
> sense of MITM that we generally use in the security community) on their
> boxes before shipping them. This proxy operated (as most do) by
> installing their own trust anchor on the box, but that's just one form
> of attack you can do if you control the user's computer
> (see https://www.chromium.org/Home/chromium-security/security-faq
> <https://www.chromium.org/Home/chromium-security/security-faq>)

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Aug 2016 06:40:11 -0700

On 8/22/2016 9:14 AM, Brian Rosen wrote:
> The root of trust for every country is the regulator.  They are the
> ultimate source of telephone numbers for that country code
...
> Our premise is that issuance of certs follows the delegation process.
> When you delegate, a cert is issued (or the scope of an existing cert
> is changed).
>
> The goal to to provide authenticated source of calls, but in reality,
> what we need is a way for the authorities to find bad actors.  By
> making the PKI follow the delegation path, you end up with someone
> holding the bag.

Brian,

The above is a useful start, for talking about what exactly is needed.

The messiness seems to be getting to the granularity of individual 
telephone numbers, given that neighboring numbers don't have to be 
administered by the same organization.  The administrative challenges in 
operating a query service with that many entries and that much 
variability in administrative responsibility from one entry to the next 
is beyond not merely challenging.

I believe there is no example of it being done across organizational 
boundaries, such as having different parts being administered by 
competing telecom providers. Yet that's the requirement STIR is taking on.

What has been occurring to me is that that level of granularity isn't 
needed, if we take your above summary seriously.

So, don't have an entry per telephone number.

Rather, we only need to have things be signed by the responsible 
/organization/.  And operating at that coarser lever of granularity is 
something we /do/ know how to run.  (Guess what reference gets inserted 
here.)

That is, have the responsible provider (or their delegatee) do the 
signing and you have an accountable entity on the hook for any problems.

d/

-- 

   Dave Crocker

-- 

   Dave Crocker

---

From: Brian Rosen <[email-masked]>
Date: Fri, 26 Aug 2016 09:58:12 -0400

> On Aug 26, 2016, at 9:40 AM, Dave Crocker <[email-masked]> wrote:
> 
> The messiness seems to be getting to the granularity of individual telephone numbers, given that neighboring numbers don't have to be administered by the same organization.  The administrative challenges in operating a query service with that many entries and that much variability in administrative responsibility from one entry to the next is beyond not merely challenging.
Huh?  The only problem is discovering the root of trust for a country you haven’t gotten a call from.  We’re not going to build a golden root, but because the root of trust is either the regulator itself or someone it designates, it’s trivial for anyone who wants to to make a list of them.  We’re standardizing the protocols.

> 
> I believe there is no example of it being done across organizational boundaries, such as having different parts being administered by competing telecom providers. Yet that's the requirement STIR is taking on.
> 
> What has been occurring to me is that that level of granularity isn't needed, if we take your above summary seriously.
> 
> Rather, we only need to have things be signed by the responsible /organization/.  And operating at that coarser lever of granularity is something we /do/ know how to run.  (Guess what reference gets inserted here.)
> 
> That is, have the responsible provider (or their delegatee) do the signing and you have an accountable entity on the hook for any problems.
You get a call with a signature.

How do you know who the responsible organization is?

Could be an enterprise, could be a service provider, could be a phone.  It in fact could be all three.  How do you know?

There is no database of who the responsible organizations are.  There is no vetting of who constitutes “responsible”.  A VoIP service provider can set up shop, purchase some numbers and termination service from a certificated carrier, resell 100 numbers to a PBX hosting provider, who resells 10 to an enterprise, who contracts with a call center (on another certificated carrier) to make calls.  Who is the “responsible organization”?

Brian

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Aug 2016 11:07:43 -0400

> That is, have the responsible provider (or their delegatee) do the signing and you have an accountable entity on the hook for any problems.

Dave, this is not correct.  All of the numbers with a given country code are under the authority of that national requlator.  This regulator must establish (and publish) one or more trust anchor.  If the certificate chains to that trust anchor, then it is valid.

One can imagine this scaling to a certificate for each phone number, but that is not the near-term plan.

I have asked the authors to add a section to the stir-certificates document that explains what a national regulator must do to establish the trust anchor(s) for their country.  Hopefully that yet-to-be-written text will resolve this concern.

Russ

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 26 Aug 2016 15:45:58 +0000

Well, the stir-certs document outlines a method for a responsible provider doing the signing (the "first approach" of Section 3) without getting into the details of who exactly has been assigned what number. That's so you have an accountable entity on the hook for any problems. This reflects the approach that Rich and others in ATIS have been developing. They intend to make use of the LoA in STIR-certs as well.

We then have a separate story about number assignment for TNs that we believe is also salient to the threat model. There are ways that could work with and without the direct involvement of national regulators. Some of the more casual approaches to establishing number ownership, while they don't constitute a definitive chain-of-title as it were, would still address our threat model I think.

Ultimately I think we are looking at a situation where we have the flexibility to experiment with some different trust models, to try transitional strategies and so on. STIR-certs intentionally creates that room for the trust story to develop independently from the signaling defined in rfc4474bis. Personally, if people wanted to deliver keys through the DNS, I'd still be open to considering it as a model. I just don't see that model as mutually exclusive with the work we've done in stir-certs. 

Jon Peterson
Neustar, Inc.

Sent from my iPad

> On Aug 26, 2016, at 8:07 AM, Russ Housley <[email-masked]> wrote:
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Aug 2016 08:48:02 -0700

On Fri, Aug 26, 2016 at 5:49 AM, Dave Crocker <[email-masked]> wrote:

> Eric,
>
> Hadn't realized that your response included inline comments as well as the
> top-posting.
>
> Generically, that's what MITM was/is getting used for (albeit without the
> distinction between coercing the comms data stream versus operating on the
> server.)
>
> (And yes, I see your later clarification that I should have been using the
> term 'active attack' rather than MITM, to cover both server compromise and
> MITM.  Thanks.)

Do you mean "server impersonation" here? Because "server compromise" is yet
a different kind of attack. That's of course active too, but it's not a
network attack, really, and falls under a different threat model.

> TLS-protected link does not make it part of TLS.)

You seem to be applying an odd standard here.

As I said, people use TLS client authentication (i.e., the mechanism
specified in TLS, not just something that runs over TLS like FIDO) but with
privately issued certificates. I concur that they don't generally use it
with publicly verifiable certificates, but that does not mean that they do
not use TLS for client authentication.

> The current global reality for TLS is that it is tolerated to operate with
> self-signed certs and constant user overrides of security warnings.
>

I'm not sure what you mean by "constant user overrides". As I said in my
previous e-mail, it's a big Internet so there are a lot of self-signed
certs, but it's actually not the case that you have to override certs
constantly to use the Internet (I basically never do except when I'm
testing something), and the browsers strongly discourage it.

Is that a tolerable mode for STIR?  If it isn't, then what will eliminate
> the problematic operational behaviors.  I think the answer implied in
> various people's comments is that this will be a closed system.

I don't actually think that that's the answer. Rather the answer is that
STIR is opportunistic in a way that HTTPS is not. I.e., if I enter an
https:// URL, then that tells the browser I want to do HTTPS and if the
server does not have a real cert, it can either offer a self-signed cert or
fail and my browser can either accept that (possibly with an override) or
fail. However, STIR is different in the sense that I can get non-STIR SIP
messages and then I just don't show security indicators (or show unknown
caller-ID, or whatever local policy demands). Thus, there is no need to
fall back to an unvalidatable credential except for testing purposes.

> I was asking a simplistic question:  The claim is that TLS is effective; I
> realize it is a widely-held view.  I was asking for some empirical

I think I've made clear what sort of evidence is available. You (and the WG
in general) will have to make your own judgements about whether that
evidence is sufficient.

> pruning has not been part of the presented characteristics of the PKI model
> for typical presentations, nor for public operational models using PKI.

Well, I don't know what's in "typical presentations", but the fact that the
trust anchor list maintainers can and do remove trust anchors is quite well
known and in fact it's often very public when we choose to distrust a CA.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Fri, 26 Aug 2016 11:50:04 -0400

Jon:

I am not arguing against flexibility.  However, I think a national regulator would have a hard time figuring out what they needed to do if they wanted to set up a trust anchor for their country code.  I think we should be more clear on that.

Russ

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 26 Aug 2016 12:45:55 -0400

1.  E.164 provides for an array of different constructs
for both geographic areas and global services.  Are
you circumscribing the specifications here to only
geographical areas?  What happens for country codes
that are shared?

2. The current reference should read:

[E.164]    Recommendation ITU-T E.164 (11/2010), "The international 
public telecommunication numbering plan." Amendment 1 (06/2011): 
"Revised Annex A – Clarification and explanation of the structure and 
function of international ITU-T E.164-numbers."

Is there some reason why the most current specification
and the amendment are not being referenced?  The
amendment treats several new number constructs
which seem significant.

Will there be any mechanism to enhance trust in
in the integrity of the numbers used against the
provisions of the E.164 and related Recommendations?
There are some related international treaty provisions
in play here, e.g., PP-2014, Res. 190.

Has everyone has actually read E.164? :-)

--tony

---

From: Brian Rosen <[email-masked]>
Date: Fri, 26 Aug 2016 12:53:52 -0400

Just as there is no golden root, there will be multiple roots for shared country codes, but there are a small number of these, and it’s easy to determine what the right thing is for anyone who wants to do it.

There are no mechanisms to enhance trust in the integrity of numbers.  There is just a mechanism to follow delegation of telephone numbers as they get delegated, and re-delegaed down towards the consumer/enterprise that is assigned them.

There is no assumption that any regulator will do anything, but if they don’t then calls from that country may not be treated well by the recipient.

Right now, I think the only assumptions we make about E.164 is that telephone numbers have a maximum number of digits, and the first few digits give us the information we need to determine the trust anchor.

Brian

> On Aug 26, 2016, at 12:45 PM, Tony Rutkowski <[email-masked]> wrote:
> 
> [E.164]    Recommendation ITU-T E.164 (11/2010), "The international public telecommunication numbering plan." Amendment 1 (06/2011): "Revised Annex A – Clarification and explanation of the structure and function of international ITU-T E.164-numbers."
>

---

From: Richard Shockey <[email-masked]>
Date: Fri, 26 Aug 2016 13:24:37 -0400

I totally agree with Russ…

I think it would be reasonable and appropriate to insert some text in the certificate document that says 

“National Regulatory Authorities that have plenary and sovereign responsibilities for their portions of the global E.164 plan should take appropriate steps to establish trust anchors consistent with applicable laws and regulations”  blah blah blah.

For the time being phone numbers ARE NOT DOMAIN NAMES.   Over time they may ..may take on that function and role and certainly in the US there is an ongoing discussion of National Number Portability that would remove the geographic distinction in the US portions of the NANP and grant “one number for life” like functions.

For the time being, this “flexibility” in the trust model is a fine academic discussion but frankly has no place in getting these documents completed.  I do not want these documents to confuse NRA’s with a bedtime “story”  of what might be or could be only what the protocols can do right now. 

Jon .. please please don’t even start a discussion of number assignment.  For those of you that want to have that discussion you can go over to the MODERN list and perhaps listen to my epic rant at the MODERN WG meeting in Berlin. 

— 
Richard Shockey
Shockey Consulting LLC

On 8/26/16, 11:50 AM, "stir on behalf of Russ Housley" <[email-masked] on behalf of [email-masked]> wrote:

    Jon:

    Russ

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 26 Aug 2016 14:08:57 -0400

Hi Rich,

Suggest you avoid abstruse pseudo legal terms
found in your proffered sentence that are not found
in E.164 and related specifications.   It's also desirable
to keep it generic, simple, and flexible.  Perhaps
something like:

"Assignees of E.164 numbering resources should
take appropriate steps to establish trust anchors."

--tony

---

From: Dave Crocker <[email-masked]>
Date: Fri, 26 Aug 2016 20:38:22 -0700

...
>> administered by the same organization.  The administrative
>> challenges in operating a query service with that many entries and
>> that much variability in administrative responsibility from one
>> entry to the next is beyond not merely challenging.
>>
>> I believe there is no example of it being done across
>> organizational boundaries, such as having different parts being
>> administered by competing telecom providers. Yet that's the
>> requirement STIR is taking on.
>>
>> What has been occurring to me is that that level of granularity
>> isn't needed, if we take your above summary seriously.
>>
>> /organization/.  And operating at that coarser lever of granularity
>> is something we /do/ know how to run.  (Guess what reference gets
>> inserted here.)
>>
> Dave, this is not correct.

Russ,

What, exactly, did I say that was incorrect?  From your note I cannot tell.

Please note that my point was not about the nature of hierarchies with a 
trust chain, but per-number administration at the other end of the 
hierarchy and a query service that has a different provider responsible 
for each number in a sequence. (cf, number portability with many 
possible providers.)

Again, my comment was about the challenge of operating a query service 
for telephone numbers that has to support that level of per-number 
administrative variability.

> but that is not the near-term plan.

There is no plan Russ.  Not within the IETF.  There are informal 
comments different folk have posted, but there is no document for a 
'plan' and certainly nothing that distinguishes near-term from 
long-term, nevermind an explanation for how they are different and how 
the transition will be achieved.

Please do provide a pointer to the specification for this plan, along 
with the rest of the necessary details that will permit IETF evaluation 
of operational feasibility.

> I have asked the authors to add a section to the stir-certificates
> document that explains what a national regulator must do to establish
> the trust anchor(s) for their country.  Hopefully that
> yet-to-be-written text will resolve this concern.

So, no single trust anchor for this service.  Instead, every validator 
is going to be required to maintain an up-to-date list of keys for /all/ 
of the national trust anchors?  And this is going to be kep up to date 
safely exactly how?

d/
-- 

   Dave Crocker

-- 

   Dave Crocker

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 27 Aug 2016 10:34:21 -0400

Russ et al.,

Dave raises some serious concerns.  Indeed,
a careful reading of some of the stir texts,
especially draft-ietf-stir-certificates-07 raises
fundamental problems.  He has done everyone
a service here.

The trust anchor for E.164 telephone numbers is
the ITU-T Telecommunication Standardization Bureau
which allocates and assigns those numbers and blocks
to a variety of parties, including designated Administration
authorities pursuant to the E.164 sub-parts.  Those
assignees can then establish sub-allocation/assignment
processes within a variety of legal/regulatory constraints.
There are treaty provisions that have baked this trust
construct into public international law for decades.

The construct is also effectively a domain name system
that was indeed a model for the DARPA Internet DNS,
and was subsequently layered onto DNS resolvers via
ENUM specifications and implementations.

How can one even create a specification like this and
not cite E.164 (except amusingly in the syntax
expressions where you have to)?

The assertion in the introduction of draft-ietf-stir-
certificates-07, that "telephone numbers have long
been a part of the X.509 standard" is flat wrong, if
not bizarre.  (This is the case both for Rec. ITU-T X.509
as well as the IETF's derivative version, RFC5280.]
Furthermore, pause should be given to the assertions that
> this document provides
> ways to determine authority more aligned with telephone network
> requirements, including extending X.509 with a Telephone Number
> Authorization List which binds certificates to authority for
> particular telephone numbers, or potentially telephone number blocks
> or ranges.
  and
> the credential system described in this document could be useful for
> other protocols that want to make use of certificates to prove
> authority over telephone numbers on the Internet
"Prove authority?"  How about "assert."   The
document provides basically four different
schemes using certs - some of which have
rather low levels of assurance.  The casual
constructs here and failure to tie anything to
E.164 limits the utility and creates potential
problems in the future.

It's not clear why the certificates here make
use of just PKIX and an IANA OID leaf.  That
seems rather constrained from an antitrust
standpoint, and unlikely to fly globally.

There are many inconsistencies threaded through
this and related documents with respect to X.509
references, the use of OIDs, and related citations
such as the mystifying one citing ISI as responsible
for X.680 - X.683.

--tony

On 2016-08-26 11:38 PM, Dave Crocker wrote:
> Please note that my point was not about the nature of hierarchies with 
> a trust chain, but per-number administration at the other end of the 
> hierarchy and a query service that has a different provider 
> responsible for each number in a sequence. (cf, number portability 
> with many possible providers.)
>
> with the rest of the necessary details that will permit IETF 
> evaluation of operational feasibility.
>
>
> is going to be required to maintain an up-to-date list of keys for 
> /all/ of the national trust anchors?  And this is going to be kep up 
> to date safely exactly how?
>
> d/