Hi all,
I do not know whether Wednesday's discussions will end up in a place where
these thoughts will be useful, but in the spirit of having discussions on
the list, I decided to write up some thoughts I've been pondering for a
while. Hopefully the written form will be more clear than if I had to try
to express them in the mic line, and perhaps they will even inspire
thoughts from other people as well.
That said, I recognize that I am posting this pretty late and the one day
between now and then is already packed with meeting sessions, so I do not
expect to have a complete discussion on the list before the Wednesday
session. (As always, happy to be proven wrong.) So...
Once we start talking about pinning of any sort, we move from this
extension just being "transport some DNS records" into conveying some
sort of additional semantics.
It seems that we have not really had a structured discussion about what
semantics and information flows we might or might not want to convey in
this extension (in one or both directions!), and I'm reluctant to consider
adding such semantics without such a discussion.
If we accept the premise that the intention of DANE as relevant in this
space is to allow the server to convey to the client the server's
preferences for how the client should authenticate the server, we may also
want to consider the case where a server operator wants to eventually get
to a DANE-only state where it can ignore the web PKI. (There may not be
many or any servers that actually end up wanting to do this, but it's not
unreasonable to consider the possibility.) In order for a server to do
that, the server needs to know that all clients are not only willing to do
DANE, but able to get the records they need, whether via this extension or
otherwise! Without such information, the server risks breaking clients
with the transition, and not knowing what population of clients have been
broken.
Doing some brainstorming on what the client might be able to tell the
server in this space, I can come up with things like:
(1) the client is willing to use DANE to authenticate the server
(2) the client already has the DANE records it needs to do (1)
(3) the client needs the server to give it the DANE records to do (1)
(4) the client requires the server to be DANE authenticated
(5) the client already has the DANE records it needs to do (4)
(6) the client needs the server to give it the DANE records to do (4)
(7) the client is willing to commit to one or more of the above for some
time period
Similarly, the server may want to indicate things like:
(a) the server wants to be authenticated via DANE (yes, this is just the
contents of the DNS)
(b) the server can provide DANE/DoE records in a TLS extension
(c) the server will commit to (a) for some time
(d) the server will commit to (b) for some time
Some of these might be always a consequence of or very strongly implied by
the presence of some information (e.g, sending the extension probably
implies (1), and having TLSA records at all probably implies (a)). My
understanding is that the pinning proponents want a field in the server
response that conveys (d). Note that this does not necessarily imply (a)
or (c), at least not with the same timer!
I deliberately am not trying to come to a conclusion in this message, as I
am not confident that I have even come up with all the potential semantics
worth thinking about, and I think that any motion in this space should only
be taken with WG consensus.
I would love to hear others' thoughts on what I am missing from the above
lists, reasoning for/against including protocol elements to indicate
the listed semantics, and whether/which existing protocol elements already
convey which of the enumerated semantics.
Thanks,
Ben
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
