Re: Quic: the elephant in the room

[Phillip Hallam-Baker <[e-mail]>]

On Sun, Apr 11, 2021 at 4:13 PM Michael Thomas <[e-mail]> wrote:

> On 4/11/21 12:56 PM, Phillip Hallam-Baker wrote:
>
> On Sun, Apr 11, 2021 at 3:34 PM Michael Thomas <[e-mail]> 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)
<https://tools.ietf.org/id/draft-hallambaker-web-service-discovery-05.html>

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.