A group met this afternoon to discuss the TLS DNSSEC document. I
want to thank the participants as I think it was a productive meeting.
Here
is chairs' summary of some of the important points of the discussion from
notes from the meeting. The second section outlines some behavior that
we need to clarify in the draft.
THE NON-TLS BEHAVIOR
Consider the following TLSA record:
- domain example.com
- record for key K1
- TTL of 3600s
If I retrieved this record over DNS and then connected to example.com
over TLS and it gave me key K2, which is WebPKI certified, but is
different from K1 [0], then I would be required to terminate the
connection per RFC6698 S 2.1.1. Similarly, if I later went to connect
to example.com and it displayed K2, then assuming I still had the
records in my cache, I would be required to terminate the connection.
INTERACTION BETWEEN DNS TTLs AND THIS EXTENSION
The current document is a bit unclear on the question of the behavior
when these records are delivered via TLS as in this draft as-is, i.e.,
without
pinning to the extension. Assume that my client is not configured to
require this extension.
It seems clear that if during the connection, the server
negotiates the extension and provides this record but also key K2, I
need to terminate the connection. It's not clear how this would happen
other than misconfiguration; it wouldn't benefit an attacker. Now,
consider what happens if I make an initial connection to the server
and it provides K1, but immediately thereafter, I make a separate
connection to the server and this time it does *not* negotiate the
extension, and displays K2.
What happens then? It seems to me that there are two answers:
1. Accept K2 (because it's WebPKI certified).
2. Reject K2 (because it doesn't match the TLSA record).
Given that these have exactly the opposite effect, it seems like
the first thing we need to do is clarify what the expected behavior.
It seems like there are three things we could do:
1. Forbid clients from applying TLSA records received in one TLS
connection to another TLS connection. This would seem to violate
the spirit of "this is just another way to deliver DNS records".
2. Require/encourage (for some 2119 level) that clients apply TLSA
records for as long as tehy remain valid.
3. Say nothing.
We don't think (3) is acceptable. It's not OK for the servers not to
have any idea how clients behave as it can break things. Specifically,
if clients aren't forbidden to do this, some clients might which means
servers have to expect it. We should start by addressing this issue.
Moreover, it's pretty unobvious that things might behave this way. We
need to decide on the behavior here.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
