Re: [stir] Key query/validation

[Dave Crocker <[e-mail]>]

Eric,

On 8/22/2016 9:26 AM, Eric Rescorla wrote:
> On Mon, Aug 22, 2016 at 8:59 AM, Dave Crocker <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Eric, et al,
>
>     On 8/21/2016 6:50 AM, Eric Rescorla wrote:
>
>         On Sat, Aug 20, 2016 at 11:53 AM, Dave Crocker <[e-mail]
>         <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>> 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.
>     ...
>
>         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?
>
>     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:
>
>     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.
>
> 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.

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...


> 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.

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


> 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.

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.


>     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

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
> browser vendors and TLS implementors take authentication failures seriously.

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.)


>         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.
>
>
>     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[*].
>
>
>
> Does this footnote go somewhere?

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


>     2) Your comment appears to imply exclusion of human factors from
>     analysis of cert issues.
>
>
> Hmm... Can you elaborate on this?

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.


>         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.
>
>
> 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.


>         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.
>
> 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
   Brandenburg InternetWorking
   bbiw.net



-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net