On 10/11/14 09:03, Hodges, Jeff wrote:
On 11/7/14, 7:14 AM, "Hanno Böck" <[email protected]> wrote:
But I am pretty sure that no matter what, the underlying cause needs to
be fixed.
Strongly agreed.
A reliable time plays a role in a number of cases in TLS.
HPKP is basically vulnerable to the same kind of attack. Certificate
validity times/expirations are vulnerable.
Yes, there's a plethora of protocols that contain timestampes of one sort
or another. Thus to some degree or another, they rely upo systems' time,
and if that time is corrupted by an attacker then the system and its users
may be in trouble.
I don't think it's feasible, or in all or most cases a good design, to go
back and 'patch' those protocols to try to guard against NTP-based attacks
(as one example of how system time may be corrupted), rather, platforms
should (as AGL noted in a earlier thread "NTP vs. HSTS" on [1]) "fix the
clock" (I.e. Address NTP and other clock vulns).
<wg chair hat= off>
I agree with Jeff. It would better to aim fixing the clock issue (or the
relying on fake clocks), than trying to give "infinite" to all kinds of
protocol parameters.
Tobias
=JeffH
[1] W3C Web App Security WG <[email protected]>
http://lists.w3.org/Archives/Public/public-webappsec/
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
