Re: Quic: the elephant in the room

[Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx>]

On Sun, Apr 11, 2021 at 4:13 PM Michael Thomas <mike@xxxxxxxx> wrote:

On 4/11/21 12:56 PM, Phillip Hallam-Baker wrote:

On Sun, Apr 11, 2021 at 3:34 PM Michael Thomas <mike@xxxxxxxx> wrote:

e already have a widely adopted example where we ignored the webpki folks too: DKIM.

That is completely false. I was a member of the DKIM working group and its predecessors. Two years before the DKIM WG was started, I designed a DNS based key credentialing scheme together with a major technology vendor. This was demonstrated to Yahoo by my CEO, Stratton Sclavos before the date of the Yahoo patent claim.

Uh, Jim and I didn't use certificates in the design of IIM and neither did Mark with DK. Since the three of us were the basis of the combined protocol

I am very surprised that you are unaware of the Sender-ID protocol. Surely Jim mentioned it to you. That was joint work with a third party. We agreed not to put our proposal on the table so as to make it easier for work to proceed.

Allowing others to take credit is one thing, misrepresenting my position is quite another. There was never a question of using certificates. At the time I was deeply involved trying to get the DNSSEC spec modified so we could deploy it. The Assertion infrastructure in SAML was originally from my Trust Assertion XML Infrastructure from the late 1990s. Together with Barb Fox and Brian LaMacchia at Microsoft and Dave Solo at Citi, I had proposed XKMS which doesn't have anything like a certificate.

 

I think I have a little bit of insight into our thinking. So yes, we ignored the webpki guys including you. Thank goodness for that because a trip down that rat hole would have doomed it.

VRSN wanted a protocol with either raw keys or hashes of keys in the DNS so that we could create a use case for DNSSEC.

The history here is that about a year earlier, I had had discussions with Jon Callas, then CTO of PGP to see if we could persuade the market to move beyond the S/MIME vs PGP format war. The thing that ultimately prevented that work getting off the ground was not DKIM itself but the spam crisis that had prompted it. It was clearly not time to propose a second, different scheme. Some of the proposals I made in that group were intended to keep the door open to progress towards an encryption solution.

We showed Jon our design before we released it as a sanity check. At no time did he say anything about certificate based approaches.

Again, you assume that VRSN was only interested in certificates.

The original IIM design used SRV records to find key servers. It's looking more and more that it was actually the right design. But Cisco was nobody with email so it was easier to go with flow of DK. I was the original one in our group to advocate that and I'm at peace with that.

I agree SRV was the right tool to do the job right, if you want to see the approach I would do instead of DANE:

https://tools.ietf.org/id/draft-hallambaker-web-service-discovery-05.html

DNS Web Service Discovery (ietf.org)

Take the following service description:

_mmm._tcp.example.com SRV host1.example.com 0 10 80 host1.example.com

_mmm._tcp.example.com SRV host2.example.com 0 40 80 host2.example.com

_mmm._tcp.example.com TXT "version=1.0-2.0"

mmm.example.com       CNAME host3.example.com

host1.example.com     A 10.0.1.1

host2.example.com     A 10.0.1.2

_mmm._tcp.host2.example.com TXT "path=/service"

host3.example.com     A 10.0.1.1

host3.example.com     A 10.0.1.2

The text in the spec doesn't have TLS policy but you can see exactly where it would go. I could decorate the _mmm._tcp.example.com record to specify policy for all the hosts or do it on a granular per-host basis on _mmm._tcp.host2.example.com.

Starting with TLSA and then trying to work out how SRV fitted in was an obvious non starter.

And I don't know how something that could reduce the message count to the original 3 way handshake is somehow the "wrong model". In what way? Is DKIM the wrong model too?

DKIM is very definitely the wrong model and we knew that when we wrote the spec. DKIM is simply the best model that was possible within the time frame and with the vast and ugly legacy of SMTP deployment. It would have been even uglier if not for SPF giving us some breathing room.

I have no idea how something that signs billions and billions of messages a day can be considered the "wrong model" whatever that means.

DKIM was designed for SMTP and SMTP alone. It is not a model that can be generalized to other protocols and we knew that at the time. It is certainly not a pattern I would want people to repeat as a paragon.

IIM was a better approach if you wanted to go for policy. The web-service-discovery draft above is basically taking ideas from IIM and Stuart Cheshire's DNS Service Discovery work.

Given where we are now with all SMTP using STARTTLS, I would probably look to implement TLS client auth instead which would allow fast restart to amortize the public key operations. But thats not where we were then.

TLS doesn't do anything to help the end-to-end authentication.

DKIM provides 'middle to end' authentication, not end to end. Since it is (usually) checked only in the middle, middle to middle might have been as good a choice. 

The reason I think it might have been the right approach is that we wouldn't have needed to sit through the endless discussions of envelope vs sender From, the vagaries of sending mail etc. But at the time it was the wrong approach because much as I would have wanted to use spam to drive STARTTLS deployment, that approach almost never works.