On Mon, Feb 17, 2014 at 02:54:02PM -0500, Warren Kumari wrote:
> We decided not to do that, but I wonder if in light of recent
> revelations we should revisit this decision. I'm not quite sure how
> we'd cram this into the current record, if it should be defined in
> each of the "DANE with foo" docs or if it would require yet another RR
> type...
For what it is worth, I think that the DANE TLSA RRset is already
too much rope. There is no need for yet more complexity.
> Or we could give the person publishing the RR the ability to specify.
They do that by publishing the RR, in the context of an application
protocol (e.g. SMTP) where DANE TLS is opportunistic. My vote is
strongly to let the TLSA RRset stand as-is, and allow "DANE for
foo" specifications to define appropriate semantics in the context
of "foo". In particular "discovery" would be a "foo-specific"
feature.
> > And, to be blunt, if we think that Viktor is right about DANE
> for SMTP, shouldn't DANE for HTTP have the same MITM protection
> and operational downsides?
>
> Personally I think that it should, but I might be in the weeds here.
One of the key points in the introduction to the SMTP draft (please
read at least the introduction). Is that analogies between HTTP
and SMTP are deeply flawed.
HTTP has no STARTTLS. HTTP has a separate URI scheme for security,
which runs on a different port.
If one were to design an opportunistic downgrade-resistant upgrade
from HTTP to HTTPS, then one might consider approaches similar in
spirit to the SMTP draft, though there would difficulties. Lack
of STARTTLS means that any secure HTTP would need a separate port,
and thus a simple detection of TLSA RRs is not sufficient.
There would likely need to be SRV records (or something similar)
for HTTP that a client would consult to determine whether a domain
supported HTTPS and on what hosts/ports before falling back to
HTTP. Since we're not designing HTTP here, I don't think we should
discuss this any further. It is not really relevant, other than
an observation that direct application of the SMTP draft to HTTP
is not possible.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
