On Tue, 15 May 2018, Eric Rescorla wrote:
[ On advise of Eric, replaced the large CC: list with the TLS WG list ]
I think I've been pretty clear about my position, but in case it's not clear:
- I'm not sure pinning is a great idea for the reasons I've already mentioned
in the thread (i.e., I think it has a high risk of causing the same problems
we saw with HPKP.
Written on May 5th in one of our large group CC: messages:
Viktor: If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension
containing a valid NSEC proof of non-existence overrides the previous
TTL/PIN.'
EKR: Thanks. This is a good point that I agree does not apply to HPKP.
So I believe we had reached consensus on this alleged "high risk" not
being an issue. Furthermore, other then the transport, this is basically
how RFC 6698 just works.
- If pinning is a good idea,
That's not the real question. The question is "Is having a full downgrade
attack within a security protocol a good idea". Do you have an alternative
solution to prevent the downgrade attack?
- I suspect that any pinning design is going to need to be more complicated
than just a lifetime.
And as explained before as well, due to this being DNSSEC based TLSA
records or their Denial of Existence, there is nothing more complicated
involved. DNSSEC provides you with extension pinning updates within
the TTL of your own choosing. If you think pinning the TLS extension to
commit to feeding up to date DNSSEC data is a problem, you should file
an errata against RFC 6698. The only difference here is the transport
protocol (port 53 DNS versus the TLS extension body of the same signed
data)
Furthermore, if you have a different method to weighing in the risk of
deploying this TLS extension, our proposal allows you to set the pin to
0 as long as you want. That is, our solution does not prevent you from
doing what you want. However, your solution is preventing us to do what
we want (and which is a security issue on top of that)
For these reasons, don't think a lifetime placeholder in TLS is a good idea.
Again, I feel none of these stand up to scrutiny based on my above answers.
You are rejecting a solution to a security problem, but are not
addressing the actual security issue. A downgrade attack is a serious
attack rendering the entire TLS extension useless. So far your
motivation for not solving it is "it might be a hard problem", which
I think would be insufficient to proceed with publication of this
document as is with a security hole in it.
The only arguments left are "we are too far in the process" and "it is ugly".
Viktor and I proposed a solution for "too far in the process" that ensures
this extension moves forward now with the pinning details postponed to
a new document updating this document.
I have also shown that "it is ugly" prevents an even uglier draft
that is required to solve the downgrade attack left in this document if
we suggest what you do and leave the downgrade attack in this document
without any scaffolding for pinning:
https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00
At this time, there's clearly not consensus to make the change you
want. Therefore, if you want to make that change, you need to persuade
the WG.
Ok, I CC:ed the WG back into this discussion.
This still leaves my question unanswerd:
Do you believe that consensus may outweight an undisputed
security problem that voids the entire use case of the document?
Let me clarify that I would like to hear your answer in your role as Security
Area Director.
Paul
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
