updated security considerations and extensibility #19

kaduk · 2018-06-01T19:30:47Z

Attempt to describe the actual properties of the protocol, the risks, and leave a space to address them in the future.

Also change MUST use DANE when TLSA records are present to SHOULD use DANE when TLSA records are present AND "usable". With the protocol subject to downgrade attacks, the MUST does not afford any downgrade resistance. The client may do as it pleases and the server is none the wiser.

kaduk · 2018-06-01T19:33:55Z

(still quite rough, but hopefully enough to get a sense of the intent)

vdukhovni · 2018-06-05T03:02:37Z

draft-ietf-tls-dnssec-chain-extension-08.xml

  <section title="DANE and Traditional PKIX Interoperation" anchor="pkix-interop">

    <t>
      When DANE is being introduced incrementally into an existing
      PKIX environment, there may be scenarios in which DANE
      authentication for a server fails but PKIX succeeds, or vice versa.
+      Some consequences of such scenarios are further discussed in
+      <xref target="increasing-trust" />
      What happens here depends on TLS client policy. If DANE authentication
      fails, the client may decide to fallback to traditional PKIX


FWIW "fallback" in the original text should be "fall back", the single word is a noun.

vdukhovni · 2018-06-05T04:22:48Z

draft-ietf-tls-dnssec-chain-extension-08.xml

+      <figure>
+        <artwork>
+example.com. IN NSEC (www.example.com.
+    DNSKEY SOA NS NSEC RRSIG)


The above NSEC record is not the right one to deny existence of _443._tcp and the wildcard * below www.example.com, which is assumed here to be the last name in the zone. The correct NSEC record for that instead asserts the zone apex example.com to be the successor of the last node www.example.com. Thus the correct record is:

; covers _tcp.www.example.com and *.www.example.com. www.example.com. IN NSEC (example.com A NSEC RRSIG)

I think I just took this from your (@vdukhovni ) other pull request -- is there a fixed version somewhere that I should grab instead?

I pushed a fixup. Replacing the record and associated RRSIG.

ekr

I can understand the appeal of a compromise here, but I don't think this really works. In particular, there just isn't any current setting where it's sensible to send authenticated denial of existence (because you don't pin). Either we should just restrict this to additive cases, in which case we don't need authenticated denial of existence, or we should take it back to the drawing board and seriously discuss a real pinning solution

ekr · 2018-06-05T07:13:39Z

draft-ietf-tls-dnssec-chain-extension-08.xml

-      associated latency penalty. It also provides the
+      associated latency penalty, but inherent difficulties
+      with having multiple distinct trust hierarchies can limit
+      its applicability in some situations. It also provides the


I don't understand what this text means.

The Denial of Existence is still needed for this mentioned use case:

Green field applications that are designed to always employ this extension, could of course unconditionally mandate its use (whether or not to the exclusion of PKIX authentication).

Sorry, that comment means "this text needs to be rewritten so that it's clear"

The specific point is that requiring the extension is not the same as requiring TLSA records. Some servers might not have TLSA records or DNSSEC. Indeed with DNSSEC adoption still comparatively low (~9 million out of ~400 million domains) servers without DNSSEC can still participate in the green fields applications, which increases their usable scope while adoption of DNSSEC ramps up (or stalls).
Thus denial of existence is actually useful to avoid limiting applications to just the DNSSEC-signed server domains.
The green fields case is an a-priori pin for t ∈ (-∞, ∞)

Rather than discussing this in comments, someone should add text.

I would normally want to take a crack at it, but am rather behind in telechat prep for this week, so we'd likely be waiting until Friday for that to happen. So, feel free to propose something.

I've taken a stab at it in: vdukhovni@5716384

Pushed an update for a typo noticed by Paul: vdukhovni@74e11c5

Address comments from Nico: vdukhovni@f57a151

The idea I had in mind with this chunk was that "[this extension] lets you do DANE authentication, but it's not perfect and the limitations that make it not perfect are rather inherent to the architecture" (because there are two distinct (sets of) trust anchors that are not trusted to make statements about the others' PKI). This is the Introduction, so details are not super-appropriate, but it does seem appropriate to set out the scope that this mechanism has some inherent limitations.

It kind of seems like a lot of the discussion in this thread may have been intended to go on a different line?

ekr · 2018-06-05T07:14:55Z

draft-ietf-tls-dnssec-chain-extension-08.xml

@@ -311,10 +322,19 @@
      <figure>
        <artwork>

+          opaque Reserved&lt;0..255&gt;


If we're going to leave a placeholder -- something I'm not super-excited about -- it should not be an opaque Reserved with no semantics but rather a TLS Extensions block.

I don't think there's any precedent for recursive Extensions. How would that even look in the IANA registry -- we'd have to make a new "allowed field" symbol for "DNSSEC chain extension extensions", which is pretty awkward.

I'm viewing this as allowing for a one-time "version 1.5" of this extension without needing to do a full-blown "version 2.0" and allocate a new extension number. I could maybe see someone making an argument that such an approach is dumb and we should only do "version 1" and "version 2" with distinct codepoints, but I don't think there's a very strong argument for putting full-fledged Extensions within an extension.

There's also no real precedent for reserved fields with no semantics.

There's also no real precedent for reserved fields with no semantics

Er, within what scope? Within TLS, maybe, but certainly not within the IETF as a whole.

I assumed we were talking about TLS. If we're not, then we're just quibbling about names, as there is plenty of precedent for TLVs within TLVs. For instance, OSPF calls them sub-TLVs.

And IIRC we can have sub-TLVs within sub-TLVs, which can be confusing to wrap the brain around, and I'd prefer to not go that route. Are you proposing that we create a subExtensions with the same semantics as Extensions but with a dedicated codepoint space per containing Extension?

I'm not proposing it. I'm saying that that's much more consistent with TLS practice than what you propose to do here.

My meagre input on this issue is that Melinda was concerned about implementation complexity, and we argued that that a two byte unsigned integer, initially zero had negligible implementation cost. Parsing a list of extensions inside this extension is starting to look costly. Yes, it is more general, but probably too much so. We still expect just a time value to be all that's applicable.

ekr · 2018-06-05T07:15:51Z

draft-ietf-tls-dnssec-chain-extension-08.xml

+        If at some point along the alias chain the
+        target of an alias leads to an unsigned zone, the response will include a
+        denial of existence response proving insecure delegation of that
+        zone.  DNAME chains SHOULD omit unsigned CNAME records that may have


What are the semantics of this from the client's perspective?

(Assuming I understand the question correctly) If the client doing DANE opportunistically (when TLSA records are present), then denial of existence would return the client to the status quo ante, where it does WebPKI or whatever it would have done otherwise. If DANE is mandatory, then the client will abort the connection.

letoams · 2018-06-11T14:08:34Z

On Mon, 11 Jun 2018, Viktor Dukhovni wrote: + opaque Reserved<0..255> My meagre input on this issue is that Melinda was concerned about implementation complexity, and we argued that that a two byte unsigned integer, initially zero had negligible implementation cost. Parsing a list of extensions inside this extension is starting to look costly. Yes, it is more general, but probably too much so. We still expect just a time value to be all that's applicable.

I agree. Although I think this discussion is more appropriate to have on the TLS mailing list, as we aren't wordsmithing trivia but are going back to the entire issue of whether or not to include anything and in what form. Or otherwise perhaps we should have a teleconference and then send a write up to the TLS list. Paul

ekr · 2018-06-11T14:12:34Z

At this point, I think what would be appropriate is simply to have this on the agenda for Montreal. On Mon, Jun 11, 2018 at 7:08 AM, Paul Wouters (libreswan) < [email protected]> wrote:

…

On Mon, 11 Jun 2018, Viktor Dukhovni wrote: > + opaque Reserved<0..255> > > My meagre input on this issue is that Melinda was concerned about implementation complexity, and we argued that that a two byte unsigned integer, > initially zero had negligible implementation cost. Parsing a list of extensions inside this extension is starting to look costly. Yes, it is more general, > but probably too much so. We still expect just a time value to be all that's applicable. I agree. Although I think this discussion is more appropriate to have on the TLS mailing list, as we aren't wordsmithing trivia but are going back to the entire issue of whether or not to include anything and in what form. Or otherwise perhaps we should have a teleconference and then send a write up to the TLS list. Paul — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1oYTB_dz0jSlI6FaTbIOwuGIGSI0nks5t7nnlgaJpZM4UXNBo> .

letoams · 2018-06-11T14:21:00Z

On Mon, 11 Jun 2018, ekr wrote: At this point, I think what would be appropriate is simply to have this on the agenda for Montreal.

Viktor and Nico won't be able to make it to Montreal. Also, the last meeting adding mostly uninformed humms and it was still the same very few people who actually spend time thinking about this issue. So I think it is more valuable to discuss this on the TLS list and not postpone this to Montreal. Or as I suggested before, an interim meeting on this with the people actually active on this topic. That said, I guess I could present our points to the WG, since last time that was not handled correctly. Paul

ekr · 2018-06-11T14:24:41Z

I'm fine discussing this on-list, though I suspect that will turn into "discuss in Montreal" On Mon, Jun 11, 2018 at 7:21 AM, Paul Wouters (libreswan) < [email protected]> wrote:

…

On Mon, 11 Jun 2018, ekr wrote: > At this point, I think what would be appropriate is simply to have this on > the agenda for Montreal. Viktor and Nico won't be able to make it to Montreal. Also, the last meeting adding mostly uninformed humms and it was still the same very few people who actually spend time thinking about this issue. So I think it is more valuable to discuss this on the TLS list and not postpone this to Montreal. Or as I suggested before, an interim meeting on this with the people actually active on this topic. That said, I guess I could present our points to the WG, since last time that was not handled correctly. Paul — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1oaAdnSXkx5Y-A4bKPzYg8GVOvi9Dks5t7nzOgaJpZM4UXNBo> .

vdukhovni · 2018-06-11T14:26:42Z

I'd rather not lose another month. Let's move this forward, after posting the new security consideration's text and related updates as motivating background.

kaduk · 2018-06-11T14:27:55Z

Yeah, I don't see much reason to "give up" and punt to Montreal just yet. (Though, as ekr notes, on-list discussion may end up turning into that anyway.)

vdukhovni · 2018-06-11T14:29:13Z

Perhaps push a version with the updated security considerations, denial of existence clarifications, ...
Get that settled and pick up the final obstacle at that point.

paulehoffman · 2018-06-18T18:57:56Z

I have just skimmed this lengthy change, and noticed a bad use of DNS terminology. Starting at line 675, it says:

DNS responses have associated TTLs, and clients MAY cache
DNS responses obtained via this extension for the duration of
the validated (negative, for denial of existence records) TTL.

That last bit is a misuse of the term "negative TTL". The sentence should be rephrased as:

DNS responses have associated TTLs, and clients MAY cache
DNS responses obtained via this extension for the duration of
the TTL for positive or negative records.

letoams · 2018-06-18T19:22:02Z

On Mon, 18 Jun 2018, Paul Hoffman wrote: I have just skimmed this lengthy change, and noticed a bad use of DNS terminology. Starting at line 675, it says: DNS responses have associated TTLs, and clients MAY cache DNS responses obtained via this extension for the duration of the validated (negative, for denial of existence records) TTL. That last bit is a misuse of the term "negative TTL". The sentence should be rephrased as: DNS responses have associated TTLs, and clients MAY cache DNS responses obtained via this extension for the duration of the TTL for positive or negative records.

That is still not correct. If a client sets up 10 https connections to the same server, and it receives the same pubkey, and the TLSA record has a TTL=0 or TTL=1, the client might want to use it longer then the TTL without re-doing the DNS validation. Or even when the chain blob is unmodified it might skip redoing the validation. I have offered suggestions in the past along the lines of "normal DNS processing and caching" instead of putting all these incomplete or wrongish details in this document. But the focus was on minimizing changes this late into the process. Paul

paulehoffman · 2018-06-18T19:29:34Z

Putting known-wrong wording in the draft during the RFC Editor process seems like a bad idea, even "this late into the process". The change I propose (or the one you propose) would be better.

vdukhovni · 2018-06-18T20:51:22Z

@paulehoffman [...] The change I propose (or the one you propose) would be better.

Either works for me. Ben, do you need a pull request from Paul? Or can you incorporate the changes he posted to the list?

kaduk · 2018-06-19T03:27:41Z

Putting known-wrong wording in the draft during the RFC Editor process

Just something of a process note, that the WG has full change control at the moment and the document should not really be considered to be "in the RFC Editor process". How to proceed once the WG has made its changes will be determined based on the magnitude of those changes.

kaduk · 2018-06-19T03:29:15Z

Either works for me. Ben, do you need a pull request from Paul? Or can you incorporate the changes he posted to the list?

A pull request from Paul could work, though honestly I'd consider just passing change control over to someone else (maybe Shumon?) wholesale. I don't feel a need to be driving the fine details of the change; I just wanted to toss out some broad-stroke ideas and see what kind of response they got.

vdukhovni · 2018-06-19T03:53:14Z

Sure. Is Shumon aware of this?

vdukhovni · 2018-06-19T03:54:38Z

@shuque have you been lurking in this discussion? Or is this the first time you're seeing this?

kaduk · 2018-06-19T13:22:17Z

(I guess I had assumed that being a 'watcher' on the repo would produce enough notifications to bring some awareness, but I don't know for sure that that is true.)

vdukhovni · 2018-06-22T15:30:43Z

@shuque Any chance of finding some cycles?
@kaduk How do we make forward progress?

jsalowey · 2018-06-22T17:30:50Z

This discussion needs to be taken to the list. I'll work with Ben on this.

Viktor Dukhovni and others added 4 commits May 29, 2018 17:31

Editorial adjustments to previous commit

cde7fd9

revamp'd security considerations, extensible reserved field

c94c15a

remove unused RFC7120 entity+reference

f477952

vdukhovni reviewed Jun 5, 2018

View reviewed changes

ekr requested changes Jun 5, 2018

View reviewed changes

updated security considerations and extensibility #19

Are you sure you want to change the base?

updated security considerations and extensibility #19

Conversation

kaduk commented Jun 1, 2018

kaduk commented Jun 1, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ekr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

letoams commented Jun 11, 2018 via email

ekr commented Jun 11, 2018 via email

letoams commented Jun 11, 2018 via email

ekr commented Jun 11, 2018 via email

vdukhovni commented Jun 11, 2018

kaduk commented Jun 11, 2018

vdukhovni commented Jun 11, 2018

paulehoffman commented Jun 18, 2018

letoams commented Jun 18, 2018 via email

paulehoffman commented Jun 18, 2018

vdukhovni commented Jun 18, 2018

kaduk commented Jun 19, 2018

kaduk commented Jun 19, 2018

vdukhovni commented Jun 19, 2018

vdukhovni commented Jun 19, 2018

kaduk commented Jun 19, 2018

vdukhovni commented Jun 22, 2018

jsalowey commented Jun 22, 2018