On Wed, 4 Apr 2018, Joseph Salowey wrote:
This is a consensus call on how to progress this document. Please answer the
following questions:
1) Do you support publication of the document as is, leaving these two issues
to potentially be addressed
in follow-up work?
I do NOT support publication of the document as-is.
If the answer to 1) is no then please indicate if you think the working group
should work on the document to
include
A) Recommendation of adding denial of existence proofs in the chain provided by
the extension
B) Adding signaling to require the use of this extension for a period of time
(Pinning with TTL)
C) Both
These options need a bit of clarification.
If you do A) then by publishing the proof of non-existance records, you
can cancel any outstanding kind of pin done. And you would not need B)
But that requires the server farm consistently send the TLS extension at all
times. If they stop doing this, you have to somehow determine if this is
an attack or an administrative discontinuation. Doing a pin as per B)
would help identify if this is an attack or not. And a pin whose value
meants "no commitment" would allow for a farm of TLS servers where not
all servers have the extension (obviously at a price of reduced security)
So to support all cases, I would say C) but I think B) would get us
pretty far on a lot of deployments.
The document's intension is clearly to staple DNSSEC answers for the
TLSA query on the TLS handshake. Omiting proof of non-existence means
it fails to achieve its specified goal and makes this TLS extension
completely useless[*]
Paul
[*] The only use case would to accept WebPKI _or_ DNSSEC, which only
reduces the currently available security levels instead of increasing
it.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
