ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] New proposal: SMTP Strict Transport Security

2016-03-21 17:13:02


----- Original Message -----
From: "David Schweikert" <david(_at_)schweikert(_dot_)ch>
To: "Daniel Margolis" <dmargolis(_at_)google(_dot_)com>
Cc: "Wei Chuang" <weihaw(_at_)google(_dot_)com>, "Mark Risher" 
<risher(_at_)google(_dot_)com>, ietf-smtp(_at_)ietf(_dot_)org
Sent: Monday, March 21, 2016 1:12:12 PM
Subject: Re: [ietf-smtp] New proposal: SMTP Strict Transport Security


I think there are a couple of options for addressing this that involve some
mechanism of policy "pointers". For example, you could instead say that the
policy RR (_smtp_sts.example.com) is merely a pointer to either a HTTPS URI
(which contains the policy potentially served via an SNI-aware server) or a
new
DNSSEC-served record (depending on your preferred authentication
mechanism). By
this approach the perishable bits of a policy can be hosted by the MX
provider
and the *existence* of a policy still indicated by the policy domain owner.

Yes. I was also thinking that having one level of indirection might
better fit the SMTP model of mail domain and mail hosts. Let me make
an example to see if I understand you right:

The _smtp_sts.example.com RR could contain the policy like
"redirect:gmail.com" and also publish that same information under
https://policy._smtp_sts.example.com. Then, any client would need to
access and authenticate two HTTPS resources:

- https://policy._smtp_sts.example.com   -> redirect:gmail.com
- https://policy._smtp_sts.gmail.com     -> mx:... a:...


may be a CNAME could do the same ?

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp