Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

[Tom Ritter <[e-mail]>]

On 15 May 2018 at 22:14, Viktor Dukhovni <[e-mail]> wrote:
> I therefore appeal to the readers who've so far stayed silent on this
> issue, to lend support to paving the way for a more broadly applicable
> downgrade-resistant protocol, by supporting the inclusion of a two byte
> field for that purpose.

Sorry; but it's disingenuous to ask people who have stayed silent to
only speak up if they support you. I have not followed this draft due
to lack of time. I've tried to read up on the pinning issue. As I
understand it:

i) A server can send a Trust-Anchor-less cert with this extension, and
a supporting client can validate the DNSSEC chain and accept the
certificate.
ii) A server can send a chain of certs with a Trust Anchor, and since
this is how TLS on the Web works today, clients will accept the
certificate.
iii) An attacker can get a fraudulently issued certificate from a
Trust Anchor, and use that to impersonate a server who implements (i),
even though they tried to ignore the WebPKI.

To prevent the attack, Viktor and others propose allowing a server to
pin the extension for a period of time; so that clients will not
accept such an attack. They argue for allocating two bytes to specify
pinning; and say they will have a later draft that explains what they
mean.

There's a lot of emails on this topic; but I haven't seen how you
would fit the supported lifetime into a uint16. Can't be seconds (only
18 hours)... Minutes? (45 Days limit?) I would not care for anything
more complicated like some sort of double-like
reduced-precision-as-your-magnitude-increased.


I find ekr's characterization of the usage of this draft apt:

> 1. Assertive: To avoid having to engage with the WebPKI
> 2. Restrictive: To protect yourself from compromise of the WebPKI.


The objections to the uint16 solution to the concern seem to be:
a) no one's said they're going to implement that feature
b) it's more complicated for people to implement the draft
c) we can add a new extension to do pinning
d) generally pinning specifies a lot of additional fields that are not
present here (report-only mode, report-uri, includeSubDomains)
e) it's easy to brick oneself
f) it's possible for attackers to brick you
g) This draft is intended to address Use Case 1; not 2.


I am very sympathetic to the concern raised. I agree the attack is
real and considerable and it should be protected against.


I am entirely unswayed by arguments (a), (b), and (g).

Bricking (e) and (f) is a real concern. While web browsers have a
mechanism to automatically resolve bricked sites in significant
situations (it's not a pleasent one, it's a whole browser update)
non-browsers do not. Presumably forward-thinking developers would make
it realtively easy for admins to do so ('run this command' or delete
the line from this .txt file') - it still requires administrative
action and there's a long tail where that won't happen.

I am most swayed by (d). I think any pinning mechanism needs a report
only mode and a reporting mechanism. The comment

> There is no role here for bells/whistles like "testing" modes, because
> there's no way to authenticate a "testing" mode, that'd be just another
> downgrade vector.

Seems to miss the point of a testing mode: it's not for when you're
attacked; it's so you can confirm your deployment isn't messed up in
some unanticipated way. I only partially agree that a testing mode in
DANE makes sense - in the same way that a testing mode for HTTPS makes
sense. When deploying HTTPS (no HSTS, no HPKP) we rely on tools like
SSL Labs to tell us that our cipher configuration doesn't brick Java 6
and we're sending the right intermediates. A Report Mode for clients
might be able to tell us the same information. I don't fault DANE for
not doing this any more than I fault HTTPS. HSTS' failure to do was
covered up by CSP. But we should repeat the mistake because we made it
before and things eventually seemed to work out.


Painfully, there is no effort for pinning in this WG. There's
draft-sheffer-tls-pinning-ticket which looks quite clever to me; but
it looks like it was last discussed in early 2017 and no clear support
for it emerged. An argument could be made that if we're going to have
a pinning extension, it should work for all forms of key agreement in
TLS: Certificate, DNSSEC, Raw Public Key, PSK (maybe? that might not
make sense.) That argument would effectively make the work of such an
extension a few orders of magnitude as great and probably kill the
effort.



On the balance, I support adding the two bytes.

I would argue that the top-most or bottom-most bit should be used as a
testing bit (0 = Testing, 1 = Enforcement), and that the draft (or a
second draft) specifying the policy should add a generic
problem-reporting extension that allows one to post a description of
errors encountered. But these arguments do not hinge my support of two
bytes.

I have no expectation or opinion about how this should affect WG
proceedings. There was a Last Call, I don't know IETF process where
there's disagreement like this, people are arguing about what
constitutes consensus, I don't know if this email 'counts'.

-tom