Re: [saag] new terminology ID posted

[Stephen Kent <[e-mail]>]

Viktor,

> ...
> I am not asking you to classify RFC 6698 DANE as OS.  Rather, I'm
> asking you leave room for opportunistic variants of RFC 6698 such
> as:
>
>      http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane
>
> Opportunistic DANE TLS is a protocol in which (for now SMTP) clients
> employ as strong as possible security with each (SMTP) server.
> This subsumes cleartext for servers that neither publish TLSA
> records nor offer STARTTLS (or some MITM downgraded their EHLO
> response).  It also subsumes opportunitic unauthenticated TLS when
> no TLSA records are found, but STARTTLS is available.  It also
> subsumes mandatory unauthenticated TLS when TLSA records exist,
> but none are usable, ...
I understand, now. Sorry for the confusion.
>
>> But, as you noted, if one employs authenticated cipher suites plus
>> DH (ECDH) one can still achieve PFS.
> Across all TLSA record types, the TLSA record does not select the
> TLS key exchange mechanism.  It can be PFS or RSA key transport if
> the keys happen to be RSA keys, but even RSA keys work with PFS.
You are correct. But, I suspect that most folks reading 6698 interpret
it relative to the most common practice for TLS, in which RSA is used
for key transport. If one conveys an EE cert via a TLSA record, I think
most folks would not expect that cert to be used for auth and NOT key
transport, even though that use case is covered by TLS.

Anyway, I was confused by which doc we were debating. My bad. And, you
are correct that TLSA records do not, strictly speaking, dictate the
cipher suite used with TLS, so PFS is not incompatible with use of DANE.

Steve