Dear colleagues,
The mail exchanges on this draft and conversations with Victor have brought up
a new issue that we want to
highlight. (this message uses vocabulary from the dane-vocabulary draft)
Question: Are there more than one security models possible for
applications/protocols that use DANE ?
The original DANE/TLSA model in effect says "all records used for DANE must be
DNSSEC protected, both
actual records and DNS records used to get to those records."
The protocol we designed for HTTPS, unlike many other protocols uses Address
records as Service specification.
Protocols that use a different record (like MX or SRV) as a service
specification record now have 2 places to put
Authentication (TLSA) records.
SRV draft and SMTP drafts both say put Authentication records with Address
records, as that is better for operators.
The SRV and Vocabulary drafts both assume that both Service records and Address
records are secured if the
Authentication records are stored with Address records, (requiring DNSSEC for
all sets).
The SMTP draft is proposing that it is ok to use TLSA records that are stored
with Address records even if the
Service (MX) records are not signed.
Attempts to answer the question as what kind of security models can we have
with DANE?
Full: All records used to find service, address and authentication are
DNSSEC protected
Server only: Address and Authentication records are DNSSEC protected
Service only: Service and Authentication records are protected but not
Address records
Questions that need answers:
- What are the security implications of each model?
- What types of security does each model provide ?
- What is not possible with each model?
- What threats does each model handle?
- any others?
Do we (as a WG) want to document these models formally and the implications of
each model operationally ?
Olafur & Warren
On May 6, 2014, at 1:33 AM, Viktor Dukhovni <[email protected]> wrote:
> On Mon, May 05, 2014 at 10:15:11PM -0700, [email protected] wrote:
>
>> Title : SMTP security via opportunistic DANE TLS
>> Authors : Viktor Dukhovni
>> Wes Hardaker
>> Filename : draft-ietf-dane-smtp-with-dane-09.txt
>> Pages : 34
>> Date : 2014-05-05
>
> Changes from -08:
>
> - Document organization feedback from Olafur. Some long sections
> broken up into smaller pieces, and some sub-sections promoted to
> top-level sections.
>
> - SMTP clients MAY elect to make use of TLSA records after "insecure"
> MX redirection, but MUST NOT misrepresent this as secure delivery.
>
> - Server logs SHOULD show the original (not CNAME expanded) MX hostname
> when the MX RRset is "insecure". Otherwise, redirection leading
> to downgrades may not be "tamper-evident".
>
> - SMTP clients MAY elect to make use of "insecure" TLSA records (typically
> resulting from "insecure" CNAME indirection from
> _port._tcp.<servername>, as the zone containing <servername> is
> always signed when TLSA records are requested). Again, MUST NOT
> misrepresent resulting security.
>
> - Routine corrections already discussed, based on Tom Ritter's feedback.
>
> --
> Viktor.
>
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
