Subject: [TLS] Enforcing Protocol Invariants

From: Ryan Carboni <[email-masked]>
Date: Thu, 8 Nov 2018 00:44:16 -0800

Hmm. TLS has gotten too complex. How does one create a new protocol? Maybe
we should ask Google.

The SSHFP DNS record exists. DNSSEC exists.

This might be a radical proposal, but maybe the certificate hash could be
placed in a DNS TXT record. In another DNS TXT record, a list of supported
protocols could be listed.
A DNS SRV record would define the port that one can use to connect to a
service, because the URL scheme died after .onion was recognized as a
domain and after chromium decided to that the presentation of sub domains
was unimportant. So no browser has to show which port it is connected to.
Although, to be radical, all anyone needs is RSA-2048, ephemeral DH-3072,
and SHAKE-128 as AEAD.
And maybe recommend that boot entropy could be obtained by using the timer
entropy daemon for one second (and which would in theory provide enough
entropy for perpetuity).

This isn’t rocket science. The state of cyber security is a horrible
disappointment.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 8 Nov 2018 09:34:15 +0000

>Hmm. TLS has gotten too complex.

What makes you say that?  Please be specific about what you think should be taken out.

---

From: Ryan Carboni <[email-masked]>
Date: Thu, 8 Nov 2018 16:02:46 -0800

I think I have implied that ClientHello is unneccesary to an extent, it can
be replaced by a DNS TXT record.

I think I implied that self-signed certificates are acceptable given the
precedent of Let’s Encrypt and the use of DNSSEC (has there been evidence
of DNS spoofing attacks against a CA?).

I think my suggestion has the implication that protocol negotiation is
unnecessary, although it can be kept.

I think my suggestion would have automatic backwards compatibility. A TLS
1.2-only client (likely to be found in regulated sectors that requires
middlebox inspection and decryption) would attempt to connect using port
443, while my proposed protocol would attempt to look up using DNS first to
obtain DNS records relevant. By using separate ports for each new protocol,
it maintains a greater level of cross-compatibility and allows for future
development.

These compounded extensions make the protocol less secure by making it
harder to implement, particularly given the recent spate of attacks against
unintuitively implemented state machines for key negotiation.

The entire protocol should be removed and replaced by something far simpler.

Is this sufficiently specific?

I hope in the future, the IETF TLS working group will reach out to
middlebox designers to understand what they are exactly doing to TLS so
that these things won’t be unexpected.

I must also say that CBC isn’t bad, as long as the padding is considered to
be part of the message to be authenticated.

On Thursday, November 8, 2018, Salz, Rich <[email-masked]> wrote:

> *>*Hmm. TLS has gotten too complex.
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Nov 2018 17:04:10 -0800

Hi Ryan,

Thanks for your comments.

On Thu, Nov 8, 2018 at 12:44 AM Ryan Carboni <[email-masked]> wrote:

> placed in a DNS TXT record.
>

There's actually an RFC for this: https://tools.ietf.org/rfcmarkup?doc=6968.
Unfortunately, it is not really a viable option for replacing the WebPKI
for TLS for two reasons:

1. A nontrivial number of network elements will not correctly pass DNSSEC,
and so attempting to use it will cause failures.
2. Essentially all clients and servers only support WebPKI authentication,
so at least for existing applications (such as the Web), endpoints will
need to support WebPKI for a very long time.

There are some specific applications that could potentially use this
method, but that's not going to work for most applications. It's also worth
noting that in practice, many sites are served on multiple CDNs which do
not share keying material. This is a real unsolved problem for Encrypted
SNI and would also likely be a problem if the keys in question were
endpoint keys.

In another DNS TXT record, a list of supported protocols could be listed.
> was unimportant. So no browser has to show which port it is connected to.

This is an orthogonal question to TLS, I believe. However, in general at
least the Web community has decided that it's not excited about SRV.
However, at least on the Web, the reason for the ubiquity of 443 isn't the
inability to indicate the right port in the URL (which has a slot for
this), but rather that other ports than 443 have much lower middlebox
penetration rates.

> and SHAKE-128 as AEAD.

This is a fairly surprising proposed set of ciphers, given that the
Internet seems to be rapidly moving towards elliptic curve. This proposal
would certainly have very significantly worse computationsl performance
than the mandatory TLS 1.3 ciphers.

> entropy daemon for one second (and which would in theory provide enough

This also seems out of scope for TLS.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 8 Nov 2018 20:08:03 -0500

> On Nov 8, 2018, at 4:34 AM, Salz, Rich <[email-masked]> wrote:
> 

One example area where the complexity is noticeably high:

 * Certificate selection metadata specificity seems to far exceed
   plausible diversity of choice on the peer end.  Are there
   really clients or servers out there with so many different
   certificates to choose from that we need:

	a.  CA name hints from client to server?
	b.  OID filters in the certificate request from server to client?
	c.  signature_algorithms_cert (TLS -> X.509 layer violation, I
            just ignore this one)?

    In TLS 1.2 the signature_algorithms extension needs to be combined
    with the certificate types list, and neither 5246 or 4492 provides
    a means for the client to decide which curves the server supports
    in the client certificate (addressed in TLS 1.3).

TLS 1.2 has fixed-(EC)DH ciphersuites that should probably never have
been defined, and for some unknown reason added MD5 as a valid signature
algorithm hash, even though MD5 had already reached its use-by date...

For simplicity, I am a fan of Mike Hamburg's STROBE (a protocol design
framework, not a finished protocol):

   https://eprint.iacr.org/2017/003

of course one still needs to plug in some sort of PKI to get
a complete system, but it robustly unifies many things that in
TLS need to be built with one's bare hands.  I do hope that
STROBE is getting used somewhere, and not just languishing as
a paper design.

-- 
-- 
	Viktor.

---

From: Jim Reid <[email-masked]>
Date: Fri, 9 Nov 2018 01:41:48 +0000

On 8 Nov 2018, at 08:44, Ryan Carboni <[email-masked]> wrote:
> 
> This might be a radical proposal, but maybe the certificate hash could be placed in a DNS TXT record.

This is a bad idea.

Overloading TXT records with special semantics rarely, if ever, has a happy ending. For instance application software would need to somehow work out which of the TXT records for some domain name was your hypothetical hash and which were SPF strings or whatever else has been dumped into TXT records.

If you need to put this hash in the DNS, you might as well get a type code assigned for a specifc RR to do that.

---

From: Ryan Carboni <[email-masked]>
Date: Thu, 8 Nov 2018 18:31:28 -0800

On Thursday, November 8, 2018, Eric Rescorla <[email-masked]> wrote:

>  It's also worth noting that in practice, many sites are served on
> multiple CDNs which do not share keying material.
>
>
Encrypting common knowledge is cargo cult fetishism for cryptography. The
files could be sent unencrypted, and protected using subresource integrity.
If you are sharing the same data to multiple second parties to serve to a
single third party, the value of encryption is less than zero.

This could create a long drawn out argument which may prove that it is
impossible to change anything about TLS as it has reached a point where too
many people are doing too many things to it, that is outside any original
or rational design.

In any case, Eric, you inadvertently contradict yourself. The whole point
of WebPKI is to certify trust, and has been an issue over the years. But
CDNs act as a intermediary between the creator of the content and the end
user. CDNs do not have as strict requirements as do CAs in terms of
auditing, and have their own issues outside the scope of this conversation.

Like I said, this could go on forever, I’m just making one point, you
people have made a protocol does very little of what one should expect it
should do, and the internet has evolved to be some sort of non functioning
system, the best example of which would be that everyone has forgotten what
URI standards are supposed to be about.

In any case, TLS 1.3 won’t reach widespread adoption for another few years,
and any subsequent protocol (independent of Google’s worldwide lab
experiment) won’t be finalized for five years, and depending on how radical
it is, won’t achieve mass adoption for four to fifteen years.

By which point layer 2 protocols might allow for IPv6 jumbo packets to be
used.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 8 Nov 2018 18:51:49 -0800

> single third party, the value of encryption is less than zero.

I believe you are misunderstanding me. The issue is not about
confidentiality of the records but about correctness.

Consider the case where example.com which is hosted on two CDNs, X and Y. X
and Y have different private keys (for the reasons you indicate) as well as
different crypto configurations. The client does an A/AAAA lookup for
example.com and gets an A for X and then does a TXT lookup for example.com
and gets the TXT for Y. This creates failures. We've spent quite a while
working on this problem for ESNI and there aren't a lot of great answers
right now. It seems like your proposal would suffer from the same issue.

> auditing, and have their own issues outside the scope of this conversation.

Well, I agree that this is out of scope, but the guarantees that the WebPKI
claims to enforce (at least for DV) is effective control of the domain
name, and a CDN acts as the origin server for a given domain and hence
effectively controls it. I appreciate that many people don't like this, but
it's essentially the only design that's consistent with having the CDN act
for the origin, which is at present basically essential for good
performance.

I don't know what you consider "widespread", but presently both Chrome and
Firefox support TLS 1.3, and our data shows that about 5% of Firefox
connections use TLS 1.3. Chrome's numbers are similar and the numbers from
the server side perspective are higher (last time I checked, Facebook was
reporting > 50% TLS 1.3).

-Ekr

---

From: Dmitry Belyavsky <[email-masked]>
Date: Fri, 9 Nov 2018 09:53:23 +0700

Hello,

пт, 9 нояб. 2018 г., 7:03 Ryan Carboni [email-masked]:

> I think I have implied that ClientHello is unneccesary to an extent, it
> can be replaced by a DNS TXT record.
>

Sure.
At least this proof-of-concept one.

https://blog.powerdns.com/2018/09/10/spoofing-dns-with-fragments/

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 8 Nov 2018 22:46:14 -0500

> On Nov 8, 2018, at 9:51 PM, Eric Rescorla <[email-masked]> wrote:
> 
> I don't know what you consider "widespread", but presently both Chrome and Firefox support TLS 1.3, and our data shows that about 5% of Firefox connections use TLS 1.3. Chrome's numbers are similar and the numbers from the server side perspective are higher (last time I checked, Facebook was reporting > 50% TLS 1.3).

Even my SMTP submission server is seeing its fair share of TLS 1.3
connections, from the iPhones of some of its users...

The long tail of TLS 1.2 will persist for quite some time, but TLS
1.3 adoption ramp-up is happening.

-- 
	Viktor.

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 9 Nov 2018 09:38:20 -0500

>> This might be a radical proposal, but maybe the certificate hash could be placed in a DNS TXT record.

[..]

> If you need to put this hash in the DNS, you might as well get a type code assigned for a specifc RR to do that.

Which is exactly what TLSA records are for (RFC 6698), and its type 3:

3 -- Certificate usage 3 is used to specify a certificate, or the
       public key of such a certificate, that MUST match the end entity
       certificate given by the server in TLS.  This certificate usage is
       sometimes referred to as "domain-issued certificate" because it
       allows for a domain name administrator to issue certificates for a
       domain without involving a third-party CA.  The target certificate
       MUST match the TLSA record.  The difference between certificate
       usage 1 and certificate usage 3 is that certificate usage 1
       requires that the certificate pass PKIX validation, but PKIX
       validation is not tested for certificate usage 3.
-- 
Patrick Mevzek

---

From: Ryan Carboni <[email-masked]>
Date: Fri, 9 Nov 2018 10:20:01 -0800

Okay, a modern browser connecting to a server owned by billion dollar
corporations are able to implement the latest version of TLS, I’ll concede
that. Regardless, I can only underline one point: any new protocol needs to
break both compatibility and be downgradable, and require a small amount of
code. It probably wasn’t wrong for the average browser implementation to
downgrade upon connection failure before, it certainly seem more sound than
any gritty details of recent protocol design.

Furthermore, TLS 1.2 is perfectly fine, and so is TLS 1.3 by everyone’s
statements. If so, a new protocol has no need to quickly replace either one
of them, but instead have a high likelihood of being superior and simpler,
and performs better according to current design of the internet.

And possibly list recommendations for how out of scope issues could be
resolved in a subsection for the inevitable RFC describing it. Boot entropy
can be solved by increasing boot times by one second. Reminders of various
Javascript functions to ensure authenticity. Etc.

Google’s idea to rush out experimental protocols looks disgusting to me.

---

From: Eric Mill <[email-masked]>
Date: Fri, 9 Nov 2018 15:39:25 -0500

> single third party, the value of encryption is less than zero.

This misunderstands the utility and deployability of SRI. SRI is based on
hashing data exactly, and so sites can only practically use it for files
that do not change (e.g. jQuery x.y.z) and not services that do change
(e.g. an analytics service, or really any live service). Encryption in
transit for public files, between services operated by separate entities,
is a practical necessity to preserve integrity.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 10 Nov 2018 02:29:59 -0800

> and performs better according to current design of the internet.

This thread seems like it has drifted afield of the TLS WG, which is
chartered to work on TLS.

-Ekr

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 12 Nov 2018 07:06:59 -0500

> single third party, the value of encryption is less than zero.

I agree that the widespread move to CDNs makes those CDNs a point of
vulnerability and potential compromise.

But from a harm reduction point of view, encrypting data that transits a
CDN does protect that traffic from surveillance by non-CDN network-based
adversaries.

There is more research and development work to be done to make that
protection even more robust: anti-traffic analysis work, for example.
But simply reverting to cleartext would be a mistake.

Ryan, your posts in this thread suggest an understandable frustration
with cryptographic deployment on the public Internet, and perhaps an
even more understandable frustration with cryptographic *deprecation* on
the public Internet.  However, the web suffers from the same two
problems as much of the public Internet: the curse of the deployed base,
and a small but non-negligible fraction of confused, interfering
middleboxes.

I love proposals that happily ignore these problems, because they tend
to be elegant, and more often correct than janky old stuff!  But, if we
want our protocol designs to actually eventually replace old, worse
protocol designs, we need to look at deployment/upgrade/deprecation
paths, which involves a *lot* of ugliness -- the main job of the TLS WG,
afaict.  Otherwise, our beautiful new designs will get rolled out, and
will simply co-exist alongside the old brokenness :/

     --dkg

---

From: Tony Arcieri <[email-masked]>
Date: Mon, 12 Nov 2018 11:15:53 -0800

Ryan, I'm having trouble finding anything you suggest which isn't
significantly inferior to what's in TLS 1.3 at best, or bewilderingly
confused at worst.

> The SSHFP DNS record exists. DNSSEC exists.

The cryptography employed by the X.509 PKI is substantially more modern
than what's in DNSSEC. Much of DNSSEC's security comes down to 1024-bit or
1280-bit RSA ZSKs.

Furthermore DNSSEC deployment in general lags behind the X.509 PKI
significantly. In general attempts to bolster browser security with DNSSEC
have failed due to DNSSEC misconfigurations or outages.

Regardless, if your goal is to make TLS less complex, shifting from the
X.509 PKI to a DNSSEC/X.509 hybrid seems diametrically opposed to that
goal. And that's the best that you can do, as you can't just wish away the
X.509 PKI.

> placed in a DNS TXT record.

How about instead of that, DNS can be used to deliver a CT log inclusion
proof?

https://github.com/google/certificate-transparency-rfcs/blob/master/dns/draft-ct-over-dns.md

> and SHAKE-128 as AEAD.

Both RSA and traditional FFDH are difficult to implement in constant time
due to their use of bignums, making both notorious for side channel attacks.

Due to its reliance on large random primes, RSA key generation is fraught
with peril.

BB'98 is a recurring problem, and affects not just key encipherment but, in
conjunction with other bugs, also affects PKCS#1v1.5 signatures (e.g.
BERserk). At least TLS 1.3 adds PSS support, I guess.

Elliptic curve cryptography is faster, easier to implement in constant
time, and has comparatively trivial key generation.

For these reasons elliptic curve algorithms are preferred in modern
protocols. By sheer volume, we see many, many more attacks on RSA than we
do on ECC, and the attacks are mostly not novel, but the same sharp edges
coming back to haunt us over and over again. The surest way to avoid BB'98
is to stop using RSA.

> This isn’t rocket science. The state of cyber security is a horrible

Your suggestions are not improvements, they are regressions, or simply do
not make sense.

-- 
Tony Arcieri

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 Nov 2018 18:13:58 -0500

[ I agree that this thread is off topic for this WG, thus below
  just a short OT aside on some oft-repeated critiques of DNSSEC. ]

> On Nov 12, 2018, at 2:15 PM, Tony Arcieri <[email-masked]> wrote:
> 
> The cryptography employed by the X..509 PKI is substantially more modern than what's in DNSSEC. Much of DNSSEC's security comes down to 1024-bit or 1280-bit RSA ZSKs.

It is true that while the KSKs tend to be 2048-bit RSA, ZSKs are typically
1024-bits or 1280-bits.

	http://stats.dnssec-tools.org/#keysize

That said, all the TLDs are using 2048-bit KSKs, and we're seeing
increasing adoption of ECDSA in DSSSEC:

	http://stats.dnssec-tools.org/#parameter

and the .CZ and .BR TLDs switched to ECDSA this year, and more will likely follow.

Furthermore, the weakest link in the chain for both WebPKI and DNSSEC is not the
cryptography.  Rather it is operational weaknesses in the enrollment processes.

For WebPKI, we basically have TOFU by the CA based on apparent unauthenticated
control of a TCP endpoint as the basis of certificate issuance, occasionally
strengthened via DNSSEC(!) validated CAA records and/or ACME challenges.

For DNSSEC, the domain administrator actually has login credentials at the
registrar, and domain control does not require a leap of faith, it is a
fundamental fact of the registrant/registrar bilateral relationship, there's
no third-party trying to bootstrap trust from indirect evidence.

What's more anyone who can compromise the registrar account and take over your
DNS can quickly obtain a WebPKI certificate as a trophy of their accomplishment. :-)

So the WebPKI picture isn't especially better, there pros and cons in each
space.

> Furthermore DNSSEC deployment in general lags behind the X.509 PKI significantly.
> In general attempts to bolster browser security with DNSSEC have failed due to
> DNSSEC misconfigurations or outages.

Certificate renewals are also botched from time to time, but we've not abandoned
the WebPKI.  The main barriers to DNSSEC are last-mile issues, and poor support
for DS record enrollment at some registrars.  Zone signing tools have been difficult
to use, but are much improved lately.

-- 
	Viktor.

---

From: Hubert Kario <[email-masked]>
Date: Fri, 16 Nov 2018 16:08:16 +0100

On Tuesday, 13 November 2018 00:13:58 CET Viktor Dukhovni wrote:
> > The cryptography employed by the X..509 PKI is substantially more modern
> > than what's in DNSSEC. Much of DNSSEC's security comes down to 1024-bit
> > or 1280-bit RSA ZSKs.
> Furthermore, the weakest link in the chain for both WebPKI and DNSSEC is not
> the cryptography.  Rather it is operational weaknesses in the enrollment
> processes.
> 
> For WebPKI, we basically have TOFU by the CA based on apparent
> unauthenticated control of a TCP endpoint as the basis of certificate
> issuance, occasionally strengthened via DNSSEC(!) validated CAA records
> and/or ACME challenges.

but that TOFU is global, not local to a client

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Lanlan Pan <[email-masked]>
Date: Sat, 17 Nov 2018 06:07:42 -0500

Personally I think the low rate of dnssec deployment on SLD authoritative
server and recursive resolver is the problem.

And TLS's distribute certificate exchange maybe better than DNSSEC's
centralized trust anchor.

Ryan Carboni <[email-masked]>于2018年11月8日周四 下午4:44写道：

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 17 Nov 2018 15:45:41 -0500

> On Nov 17, 2018, at 6:07 AM, Lanlan Pan <[email-masked]> wrote:
> 
> And TLS's distribute certificate exchange maybe better than DNSSEC's centralized trust anchor.

In principle, yes, when one carefully selects just the appropriate
trust anchor(s) for a given task.  Some applications do use specific
trust-anchors (internal corporate CAs) at least some of the time.

[ FWIW, TLS is trust-model agnostic, it is the WebPKI that uses the
  usual panoply of CAs. ]

In practice, one generally uses the Mozilla or similar trust bundle,
and so it is still centralized, except that now the attacker has a
choice of multiple central authorities to compromise.

So most of the time the WebPKI is weaker, but you sometimes have
a choice when you can limit the set of peers with which you need
to communicate.

With DNSSEC validating resolvers can also configure trust-anchors
at any point in the tree, which also allows for internal corporate
trust-anchors, and if some TLD or similar followed the RFC5011 key
rollover process used at the root, one could also track the TLD's
keys independently of the delegation from ICANN, but AFAIK this is
not presently a common TLD practice.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 18 Nov 2018 14:30:53 +0000

usual panoply of CAs. ]
 
No, it is not agnostic.  It does support other trust models -- raw keys, PGP web-of-trust -- but it's default and primary model from its inception is X509 and its (so ingrained you might consider it implicit) "trust the issuer" model.  Look at the definitions of certs and CA's and things like path validation in PKIX and its predecessors, the "trust anchors" which builds on the chain model -- chained through *issuers* -- in the protocol, and so on.

The "usual panoply of CAs" is the WebPKI instantiation of a trust model, but do not confuse it with the trust model itself. I have deployed several instances of the X509/PKI trust model at work, and none of them use a conventional WebPKI set of anchors.

If DANE-TLS is to come back, the authors should use a new TLS certificate type that is perhaps an X509 structure, but whose trust semantics are defined by DANE. The recent IEEE vehicle cert did similar, and all it took was a couple of pieces of email.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 18 Nov 2018 15:15:06 -0500

On Sun, Nov 18, 2018 at 02:30:53PM +0000, Salz, Rich wrote:

> No, it is not agnostic.  It does support other trust models -- raw keys,
> PGP web-of-trust -- but it's default and primary model from its inception
> is X509 and its (so ingrained you might consider it implicit) "trust the
> issuer" model.  Look at the definitions of certs and CA's and things like
> path validation in PKIX and its predecessors, the "trust anchors" which
> builds on the chain model -- chained through *issuers* -- in the protocol,
> and so on.

[ I don't know why you would choose to argue this point, let's not
  confuse TLS with the CA/B forum WebPKI in browsers.  My post was
  about TLS.

  My post was emphatically not an attempt to revive the DANE chain
  discussion here, and was not even about DANE, nobody is looking
  forward to reopening that discussion here.  However, since bashing
  DNSSEC is a popular sport, I may for the record, now and then
  post corrections to messages that mischaracterize DNSSEC. ]

The X.509 trust-anchors are NOT specified in TLS, and need not be
used.  Long before DANE, Postfix supported "fingerprint" authentication,
especially for email submission clients, which bypassed the WebPKI
and never looked at the certificate issuer.  Peter Gutmann may
apprise you of similar usage in industrial automation.

> The "usual panoply of CAs" is the WebPKI instantiation of a trust model,
> but do not confuse it with the trust model itself. I have deployed several
> instances of the X509/PKI trust model at work, and none of them use a
> conventional WebPKI set of anchors.

This was explicitly acknowledged and discussed in more detail in
the message you're responding to.  Yes, PKIX is not always the
WebPKI, but in practice it typically is.

> If DANE-TLS is to come back, the authors should use a new TLS certificate
> type that is perhaps an X509 structure, but whose trust semantics are
> defined by DANE. The recent IEEE vehicle cert did similar, and all it took
> was a couple of pieces of email.

There is simply no need for that.  The existing X.509 encapsultion
works just fine, and makes it possible to transparently interoperate
with both DANE and CA/B forum WebPKI or other PKIX peers.

For clients that can do DNSSEC lookups directly and reliably, DANE
works in TLS with no friction.  With DANE-TA(2) and DANE-EE(3) you
get a different trust model, and DANE-TA(2) does use "trust the
issuer", but the ultimately trusted issuer is delivered via DNSSEC
TLSA records.

DANE does not have to "come back".  It is in use today, enabling
authenticated SMTP to over 337 thousand email domains and growing:

    http://stats.dnssec-tools.org/#graphs

DANE TLS for SMTP is supported by Postfix, Exim, Halon, PowerMTA,
Cisco ESA, ...  There are also consumer email providers with millions
of users that employ DANE in both directions: comcast.net, web.de,
gmx.de, freenet.de, ... and more planned.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 18 Nov 2018 21:27:17 +0000

I am not.  You say TLS is CA/B WebPKI. I say TLS favors X509 CA-trust model, and in fact has it as its default.  For example, in TLS 1.3 page 44 (text format):
   "The signatures on certificates that are self-signed or certificates
   that are trust anchors are not validated, since they begin a
   certification path (see [RFC5280], Section 3.2)."

Section D.3, implementation notes in SSLv3 RFC 6101
   "Certificates should always be verified to ensure proper
   signing by a trusted certificate authority (CA).  The selection and
   addition of trusted CAs should be done very carefully.  Users should
   be able to view information about the certificate and root CA."
The glossary says this about certificates:
   "As part of the X.509 protocol (a.k.a.  ISO
      Authentication framework),"

>  However, since bashing
  
I said nothing about DNSSEC, certainly nothing that could remotely be taken as bashing.
  
    used.

They are specified, and if provided, how they are used is also specified and has been from the beginning, through and including TLS 1.3, as I showed via the excerpts above.

>   The existing X.509 encapsultion

The existing encoding could be used just fine, just indicate that this is a DANE-validated cert.  Then it will be clear and obvious to everyone how to validate it. Complex combinations are hard to reason about, cannot be intuited by the protocol but must be done by reading code and configuration, etc.  A DANE client could specify DANE in the acceptable cert-type, which is encoded as X509. I believe this approach was considered, but rejected. I was trying to offer advice on how that draft might be edited and brought forward more productively if the authors want to try again in the general sense of enabling DANE-style trust within TLS generally.  I don't care, I have no horse in that race.

	/r$

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 18 Nov 2018 16:51:50 -0500

> On Nov 18, 2018, at 4:27 PM, Salz, Rich <[email-masked]> wrote:
> 
> I am not.  You say TLS is CA/B WebPKI.

No, I specifically say that TLS *is not* CA/B WebPKI.
The OP to whom I responded was comparing WebPKI to
DNSSEC, so my response was about WebPKI and its use
in TLS (which also supports other models).

Anyway, this is way off topic.  I've made my points,
and stand by them.  I think we're done.

-- 
	Viktor.

---

From: Christopher Wood <[email-masked]>
Date: Sun, 18 Nov 2018 15:02:28 -0800

> and stand by them.  I think we're done.

Yes, this is off topic. Let’s please leave this thread here and focus
on Ryan’s original post.

Thanks,
Chris (chair hat on)

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 19 Nov 2018 12:37:22 +0100

Hi Ryan

reading through your email and the subsequent exchanges I am surprised that you show up right after years of standardization of TLS 1.3.

Suggesting ideas at the right time is somewhat important.

Later in your emails you explain what you consider complex in TLS and some of the ideas you are suggesting are alternative design approaches. What standardization helps you do is to work out the details of these different proposals and then to compare the different approaches against each other.

> The state of cyber security is a horrible disappointment.

... and most (if not all) of that disappointment has nothing to do with TLS.

Ciao

Hannes

Gesendet: Donnerstag, 08. November 2018 um 09:44 Uhr

Von: "Ryan Carboni" <[email-masked]>

An: [email-masked]

Betreff: [TLS] Enforcing Protocol Invariants

Hmm. TLS has gotten too complex. How does one create a new protocol? Maybe we should ask Google.

This might be a radical proposal, but maybe the certificate hash could be placed in a DNS TXT record. In another DNS TXT record, a list of supported protocols could be listed.

A DNS SRV record would define the port that one can use to connect to a service, because the URL scheme died after .onion was recognized as a domain and after chromium decided to that the presentation of sub domains was unimportant. So no browser has to show which port it is connected to.

Although, to be radical, all anyone needs is RSA-2048, ephemeral DH-3072, and SHAKE-128 as AEAD.

And maybe recommend that boot entropy could be obtained by using the timer entropy daemon for one second (and which would in theory provide enough entropy for perpetuity).

This isn’t rocket science. The state of cyber security is a horrible disappointment.

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