Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

[Willem Toorop]

Op 08-02-18 om 03:27 schreef Shumon Huque:
> On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind  <mailto:i...@kuehlewind.net>> wrote:
> 
> Mirja Kühlewind has entered the following ballot position for
> draft-ietf-tls-dnssec-chain-extension-06: No Objection
> 
> --
> COMMENT:
> --
> 
> Two minor, mostly editorial comments:
> 
> 1) Intro (sec 2): " It also provides the
>    ability to avoid potential problems with TLS clients being unable to
>    look up DANE records because of an interfering or broken middlebox on
>    the path between the client and a DNS server."
> Is that actually a well-known problem (can you provide a reference?)
> 
> 
> Some folks (at Google and NLnet Labs if I recall; maybe others) have done
> measurements to show this is an actual problem -- for a relatively small but
> still non-trivial fraction of clients. We'll try to see if we can dig up
> specific
> references to documents that could be cited.

I wouldn't call it a relatively small fraction :)  DNSSEC is severely
hampered for end-entities by broken infrastructure in many different
ways.  Sometimes an upstream resolver can be used for positive DNSSEC
answers (i.e. existing records), but not for non-existent or wildcard
answers, because it simply doesn't forward the NSEC(3) proof for it.


The last measurements we at NLnet Labs did was in July 2015:

Gorjón, Xavier Torrent, and Willem Toorop.
"Discovery method for a DNSSEC validating stub resolver."
(2015)

https://nlnetlabs.nl/pub/os3-2015-rp2-xavier-torrent-gorjon.pdf

Measurements were done with RIPE Atlas, with at the time +-8200 probes.
At the time only 56% of probes received enough DNSSEC data from their
upstreams to be able to perform DNSSEC validation for both positive and
non-existent answers (required for DANE).


There is a RFC that outlines detection and mitigation techniques on how
to deal with this from DNSSEC validation stub resolvers:

RFC8027  -  DNSSEC Roadblock Avoidance

Ultimately such a stub resolver has to be able to fallback to full
recursive resolving (i.e. iterating from the root).  Although even that
might fail...


Furthermore, hampered DNS (but not specifically DNSSEC), is the primary
motivation for the new DNS over HTTPS draft (and workgroup):

https://tools.ietf.org/html/draft-ietf-doh-dns-over-https

(DoH might be the ultimate final fallback in DNSSEC Roadblock Avoidance)

> 
> or would
> it be enough to say something like this: " It also provides the
>    ability to avoid potential problems with TLS clients being unable to
>    look up DANE records when DNS server is not reachable."
> 
> 
> Your rewording of this sentence would unfortunately not be accurate.
> It's usually not the DNS server that is unreachable, but that some middlebox
> has done something wrong, such as: not allow DANE queries or responses 
> through; not allow DNSSEC signatures through; not allow EDNS options
> that enable DNSSEC through, or engage in other misbehavior.
> 
> 
> 2) IANA Considerations should probably be updated.
> 
> 
> I guess you are suggesting that the last sentence is probably obsolete:
> 
>     "If the draft is adopted by the WG, the authors expect to make an
>      early allocation request as specified in [RFC7120]."
> 
> Agreed. It's a little late for that! :-)
> 
> We will remove it.
> 
> Shumon Huque
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Willem Toorop]

Op 22-02-18 om 16:44 schreef Shumon Huque:
> On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters  > wrote:
> 
> On Wed, 21 Feb 2018, Shumon Huque wrote:
> 
> Okay, got it. For people that have already implemented this, I think
> there has been an implicit understanding that the format of the
> chain
> data is a sequence of concatenated wire format RRs exactly as
> they appear
> in a DNS message section
> 
> 
> Note, I would not call it "sequence of concatenated wire format RRs", as
> it is simply the wireformat of a DNS message.
> 
> The fact that some parts
> are concatenated RR's is just part of the wireformat of the DNS reply
> message. That is, this isn't introducing some new form of concatenated
> content - it is _just_ a regular DNS wire format message, and the
> document should not go deeper into its explanation.
> 
> 
> It would _not_ be correct to say that this is a "DNS wire format
> message" - that 
> would mean there is a DNS header section with flags and response codes, 
> and other sections. The chain data structure as currently specified
> really is 
> concatenated wire-format RRs (as they appear _within_ a DNS message 
> _section_). Let me know if that is unclear in the draft (or my proposed
> edits).
> 
> I recall at one point way back there was a discussion about whether the
> chain
> data should just be a fully formed DNS message, but I don't believe that
> idea
> had much support in the working group (personally I would have been fine
> with 
> that choice too, if it did have support).

A DNS message is a 12 octet header followed by a question, followed by a
list of RRs.  The header does not contain any relevant information with
respect to the chain query.  The question is unnecessary, because only a
TLSA record for the name and port of the service (or a secure path from
the name of the service, via CNAME or DNAME to the name of the TLSA
RRset), is acceptable for a client, so a client would have to disregard
the question in a DNS message anyway.  The list of RRs remains and is
sufficient for the DNSSEC chain extension.

A response of a rfc7901 EDNS chain query can be used almost directly as
the content for the extension.  You just have to strip/skip the
irrelevant data from the front of the message (i.e. the 12 byte header,
the query name and 8 octets type/class/ttl).

> I noticed some discussion about the ordering of this content. I am not
> sure why that should be done. DNS doesn't care about the order, and
> neither should producers or consumers of this extension. DNS has no
> ordering inside its message.
> 
> 
> Yes, that is in fact where we ended up, roughly.
> 
> The draft does currently say that the answer record(s) appear first. And
> then
> the authentication chain records follow and that TLS client should be
> prepared
> to receive the authentication chain records in any order. 
> 
> Requiring the answer records first seems logical to me - it is what
> existing 
> libraries do, and also what the EDNS chain query spec does (answer records 
> appear first in the ANSWER section, and DNSSEC authentication chain records
> appear in the AUTHORITY section in any order).
> 
> There is some residual wording in the draft about ordering of CNAMEs etc in
> the answer records part. Assuming the WG agrees, I am fine with relaxing
> that requirement - that ended up in there because although there is no
> defined
> ordering of RRs within a DNS message section, as a practical matter CNAMEs
> are almost always ordered since there are some DNS queriers that get
> confused 
> otherwise. This is a new protocol though, so we can be more faithful to
> the DNS 
> spec.
> 
> I don't think getting unrelated DNSSEC records would be an issue. TLS
> has its maximum sizes for the handshake. In fact, it could allow the
> extension to have some useful data in the case of MX or SRV.  (and could
> be a feature to build a nice resolver over TLS using 1 tor circuit).
> 
> 
> The draft currently doesn't address the MX or SRV use case. I suggest
> that we tackle that in a future version.
> 
> I'm also not sure about the talking of unsigned CNAME records from
> DNAME. The above pseudo code (extended with special cases) should be
> in some DNS library, and that library will know what records to expect
> unsigned which are proven by the DNAME (or wildcard) synthesis and knows
> when/if to add it to the validated cache. I don't think that should be
> explained in this RFC at all. The DNS implementation does not need
> to be specified in this document and it should just focus on saying
> that "the DNS message response is validated and upon validation the
> content can be considered DANE validated".
> 
> 
> Where we ended up, is that WG participants asked for some level of DNSSEC
> detail to be included in this doc.
> 
> Shumon.
> 

_

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Willem Toorop]

Op 27-02-18 om 16:12 schreef Viktor Dukhovni:
> 
> 
>> On Feb 27, 2018, at 9:34 AM, Benjamin Kaduk  wrote:
>>
>> There doesn't seem to be much interest in pinning-like schemes for TLS
>> at this point (see also the "TLS server identity pinning" proposal from
>> the SAAG/secdispatch session at IETF 100).
>> And I do think the lack of authenticated denial of existence is
>> something the WG was aware of during our earlier discussions, so it's
>> unclear that there is a need to hold things up for this issue.
> 
> Awareness of is different from thinking through the full implications.
> I for one did not have the cycles to consider all the implications,
> and many others likely also focused on the data format, and may not
> have considered the use-cases with care.
> 
> Note that DANE-based "pinning" is fundamentally different from other
> "pinning" approaches, in that the client does not store the key
> digests for any significant length of time.  All it may do is
> cache the DANE TLSA records for a short time bounded by the DNS TTL.
> The digests that "pin" the server's (or issuing CA's) keys are managed
> in the server's DNS zone, and can be promptly updated by the server,
> and the client can learn of the change when presented with new TLSA
> records, OR as I now believe is essential for this specification to
> be at all useful, presented with authenticated denial of existence.
> 
> The only thing needed for denial of existence to be workable, is
> that the client cache a commitment by the server (a boolean value)
> to support the extension until such time as the server provides
> authenticated denial of existence of TLSA records.
> 
> This is much less brittle than client-side key pinning, with all
> its attended problems with stale data.
> 
> If this protocol has no denial of existence, I don't see any reason
> for anyone to deploy it.  Why publish something that's basically
> useless?

Well.. support of the option could be obligatory for new TLS services,
like DNS over TLS.  With DNS over TLS there is no user interaction
making third-party PKIX (i.e. a CA store) impractical.

Another possibility to authenticate DNS-over-TLS upstreams by clients,
is to setup the TLS without authentication, and then use that to do the
DANE queries over it (for privacy and to bypass hampering middle-boxes),
then authenticate the certificate and upgrade the connection to be
usable for all queries.  This works but is harder to implement and
causes a latency penalty because of the extra negotiations.

Note that the new initial draft (not WG yet) for encrypting the path
from the recursive to the authoritative, suggests DANE authentication of
the authoritative, and references the tls-dnssec-chain-extension draft
as the initial method -of acquiring the needed DNSSEC data- to try:

https://tools.ietf.org/html/draft-bortzmeyer-dprive-resolver-to-auth


Also, with DANE I like the fact that a DNS domain holder/owner can vouch
for it's own domain name instead of needing a third party.  And
although, opposed to DANE over DNSSEC, this extension doesn't add any
security, it still has that property.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Willem Toorop]

Op 01-03-18 om 22:50 schreef Viktor Dukhovni:
> 
> 
>> On Mar 1, 2018, at 2:13 PM, Shumon Huque  wrote:
>>
>>> On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams  
>>> wrote:
>>> IF there's an objection to modifying the extension in order to add a
>>> pin-to-DANE TTL field, I would propose the following instead:
>>>
>>> Make the pin-to-DANE be "forever" but make it so it can easily be
>>> cleared if DANE is undeployed for the service.
>>
>> This option is already covered in the draft. It doesn't use the term pinning,
>> but does mention caching the existence of DANE on first contact and 
>> requiring it subsequently (if clients want to do so).
>>
>> I do not know if the draft authors and/or WG have an appetite to do the much 
>> more major change suggested by Viktor (i.e in-protocol pinning TTL commitment
>> and requiring subsequent denial of existence proof if DANE is removed).
> 
> Avoiding an explicit TTL, and clients unilaterally assuming the DANE extension
> will always be available is not IMHO a good idea.>
> Websites that initially implement the extension should be able to eventually
> stop using it, if for some reason they decide that they no longer want to do
> so.  While the server can clear the caches of clients that see a denial of
> existence of the TLSA records, or proof an unsigned delegation from a parent
> domain, without a max TTL there are always clients that have not yet connected
> since the policy change, and will be broken indefinitely if the extension is 
> no
> longer delivered.
> 
> Therefore, any long-term caching of a destination's support for the extension
> should require server opt-in, and must have a maximum duration.

How do you (all) feel about using the expiry date on the RRSIG for the
TLSA to be used for this purpose?

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Willem Toorop]

Op 26-02-18 om 15:26 schreef Paul Wouters:
> On Thu, 22 Feb 2018, Shumon Huque wrote:
> 
>> On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters  wrote:
>>   On Wed, 21 Feb 2018, Shumon Huque wrote:
>>
>>     Okay, got it. For people that have already implemented
>> this, I think
>>     there has been an implicit understanding that the format
>> of the chain
>>     data is a sequence of concatenated wire format RRs exactly
>> as they appear
>>     in a DNS message section
>>
>>
>>   Note, I would not call it "sequence of concatenated wire format
>> RRs", as
>>   it is simply the wireformat of a DNS message.
>>
>>   The fact that some parts
>>   are concatenated RR's is just part of the wireformat of the DNS
>> reply
>>   message. That is, this isn't introducing some new form of
>> concatenated
>>   content - it is _just_ a regular DNS wire format message, and the
>>   document should not go deeper into its explanation.
>>
>>
>> It would _not_ be correct to say that this is a "DNS wire format
>> message" - that 
>> would mean there is a DNS header section with flags and response codes, 
>> and other sections. The chain data structure as currently specified
>> really is 
>> concatenated wire-format RRs (as they appear _within_ a DNS message 
>> _section_). Let me know if that is unclear in the draft (or my
>> proposed edits).
> 
> So it was decided to not use a full DNS packet format? And then since you
> miss the structure of the Answer Section and Additional/Authority
> Section, you require the "answer RR's" come first where you basically
> emulate an Answer Section?

No Paul, the division in sections is irrelevant for a verifier.  The
only bit of information in a DNS message that is used by a verifier is
the question.  From the question, validation starts and the relevant
records are followed and verified.  But the question section is also not
needed as the question can be derived from the name and port of the
service, i.e. ._tcp.. TLSA

The order described in the draft is both an optimization to reduce the
number of times a verifier has to go over the RRs, and it makes the
content easier to read (and understand) for humans too.

Also, for non existence answers, DNSSEC validators (and thus also a
verifier for the chain extension) simply ignore the DNS message header.
Proof of non-existence can and must be derived from the set of RRs in
the message body/sections too.

The extension already supports Denial of Existence proof b.t.w., because
it is also needed for wildcard expansions (which are supported).

Personally, I do not have very strong feelings whether or not the
extension content is a DNS message or not, but a verifier would ignore
the header and the question anyway, so why bother with that overhead?
Also, you *can* use the content of the RFC7901 chain query.  You just
have to skip the header and question section, and then include the rest.

> 
> Isn't that an indication that we should really use the wireformat of an
> entire DNS message here? Maybe some DNS library/tools people can chime
> in here to tell us if this matters much to them (assuming they are
> adding support for creating/consuming these chains of RRsets in wire
> format.
> 
> I am personally a little sad we cannot have a dig +chainquery command
> where we write out the entire answer packet format to a blob, to be
> loaded by
> the TLS server. And where a TLS client cannot just hand over the blob
> "as if it came in as a reply from a DNS server" to its DNS/cache
> receiving code path.
> 
>> I recall at one point way back there was a discussion about whether
>> the chain
>> data should just be a fully formed DNS message, but I don't believe
>> that idea
>> had much support in the working group (personally I would have been
>> fine with 
>> that choice too, if it did have support).
> 
> Do you remember why not? I'll see about checking the archives, but to me
> the hint that you are losing information and require some kind of
> ordering seems to suggest there is a need for using the full DNS message
> reply format
> 
>> There is some residual wording in the draft about ordering of CNAMEs
>> etc in
>> the answer records part. Assuming the WG agrees, I am fine with relaxing
>> that requirement - that ended up in there because although there is no
>> defined
>> ordering of RRs within a DNS message section, as a practical matter
>> CNAMEs
>> are almost always ordered since there are some DNS queriers that get
>> confused 
>> otherwise. This is a new protocol though, so we can be more faithful
>> to the DNS 
>> spec.
> 
> I would prefer the residual wording to go away. Any hints at order being
> important should be squashed.
> 
>>   I don't think getting unrelated DNSSEC records would be an
>> issue. TLS
>>   has its maximum sizes for the handshake. In fact, it could allow
>> the
>>   extension to have some useful data in the case of MX or SRV. 
>> (and could
>>   be a fe

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Willem Toorop]

I support separation of concerns: publish as is, and start new work to
extend existing Strict Transport Security mechanisms to include DANE
authenticated TLS.

Currently the draft is describing only a single mechanism: Letting
owners of a (DNSSEC signed) domain vouch for their own TLS services.
Not needing a third party for this is IMHO already valuable.

HTTP Strict Transport Security (HSTS) [RFC6797] is extensible with
directives.  A new document could provide a useDANE directive for HSTS.
That document could furthermore make more explicit, that when the chain
extension delivers a denial of existence proof or a proof of insecurity,
that a fallback to non-DANE PKIX has to be done.

The chain extension already contains verification of Denial Of Existence
proofs, because that is needed for verifying wildcard expansions.  It
does not explicitly mention the fallback to non-PKIX with a Denial of
Existence proof or insecurity proof for the TLSA record, because it is
(currently) irrelevant when the extension could simply be left out too.
However, it does implicitly by referring to the DANE RFCs in paragraph 2
of section 6. Verification:

>   If the authentication chain is correctly verified, the client then
>   performs DANE authentication of the server according to the DANE TLS
>   protocol [RFC6698] [RFC7671].

Because the current draft is describing only the embedding of DANE
records to authenticate the TLS service, it is quite short and to the
point.  I am afraid that built-in STS would bloat it with a lot of
concerns that are not specific for the simple mechanism of embedding DANE.

The extension as currently is does not add security like DANE over DNS
protocol would have. This is pointed out in in the draft in Section 8,
in which a mechanism like STS is also already suggested.

I have a few questions too.

Currently the extension contains only DNSSEC data, which can be verified
to be authentic and correct.  Is this also true for an additional TTL
value?  Is it safe to do STS at TLS ClientHello time?  Why is there not
a STS specification at TLS level already (which would also cover imaps,
pops etc.), but only for protocols one layer above TLS?


-- Willem

Op 04-04-18 om 19:50 schreef Joseph Salowey:
> Hi Folks,
> 
> Some objections were raised late during the review of
> the draft-ietf-tls-dnssec-chain-extension. The question before the
> working group is either to publish the document as is or to bring the
> document back into the working group to address the following issues:
> 
> - Recommendation of adding denial of existence proofs in the chain
> provided by the extension
> - Adding signaling to require the use of this extension for a period of
> time (Pinning with TTL)
> 
> 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?
> 
> 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
> 
> This call will be open until April 18, 2018.
> 
> Thanks,
> 
> Joe
> 
> 
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Willem Toorop]

Sorry for being confusing.  I meant to say full Denial of Existing is in
the draft implicitly already (because of the reference to DANE
authentication according to RFC6698 and RFC7671 (which do mention it) in
Section 6).


I do like the idea of STS for this extension (and augment it with the
more restrictive DANE use cases), but I'm unsure about the security of a
built-in version.

I notice that existing STS documents (HSTS [RFC6797] and MTA-STS
[draft-ietf-uta-mta-sts]) are all one layer above TLS.  Is a STS TTL
conveyed in a ServerHello message secure when it would be just for SSL?

I can see this might be different for the DANE use case because of the
signed statements that come alongside the TTL, but for example...
In case of built-in STS with the extension, what does a 0 TTL mean?

  - When 0 has been the only value seen ever, it is clear to me that the
mechanism is equivalent with what we have in the draft now, but..

  - When another value has been seen before, is a value of 0 then enough
to clear the pin?  Or would a DoE proof (or insecurity proof)
alongside it be necessary?

In case of the latter, what does that mean for sites that do have
DANE records, but no servers that support the extension?  Can they
be hampered (for an indefinite period) by a MiTM?  That would be
really bad for DANE deployment.


Op 10-04-18 om 17:22 schreef Paul Wouters:
> On Tue, 10 Apr 2018, Willem Toorop wrote:
> 
> I just want to clarify one misconception in Willem's statement. See my
> previous emails to thist list for my full arguments on this issue.
> 
>> The chain extension already contains verification of Denial Of Existence
>> proofs, because that is needed for verifying wildcard expansions.
> 
> This might confuse people. I am talking about denial of existence of any
> TLSA record. You are talking about proof of non-existance of other TLSA
> records besides the one you are returning. These are completely
> different issues. I just want to ensure people realise when I said we
> need proof of non-existence, that people do not read your line "already
> contains this" as me being wrong.
> 
> 
>> It does not explicitly mention the fallback to non-PKIX with a Denial of
>> Existence proof or insecurity proof for the TLSA record, because it is
>> (currently) irrelevant when the extension could simply be left out too.
> 
> So that's not one bug, but two bugs. Defining them out of scope is not
> what we should do. For instance, the document could already assume that
> the proof of TLS extension (pinning) is going to be solved elsewhere,
> and therefor a full denial of existence proof in this document would be
> valuable.
> 
> The document does not specify what to do when it does not find a TLSA
> record to include. It does state:
> 
>     If the server is configured for DANE
>    authentication, then it performs the appropriate DNS queries, builds
>    the authentication chain, and returns it to the client.
> 
> So if the server is configured for DANE, and it only finds denial of
> existence proofs of its own TLSA record, what is the expected behaviour?
> 
> This hints at returning the proof of non-existence, but clearly even the
> authors are now saying they did not mean this and a server is not
> required to do this. Clearly the text needs clarification, and if it
> then leaves out denial of existence, it needs a justification for that
> as well.
> 
> Paul

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Willem Toorop]

Op 13-04-18 om 00:09 schreef Viktor Dukhovni:
> The protocol as described prohibits denial of existence responses.  Willem
> acknowledged (thus far in an off-list message) that that's an oversight that
> should be corrected, and such a correction is the substance of option (A).

Well... I find it unfortunate that the line you were quoting from
section 3.4 could be interpreted as prohibiting the possibility of
denial of existence.  So I am open to relaxing that text so that it can
not be interpreted as such anymore yes.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Proposed text for dnsssec chain extension draft

[Willem Toorop]

Thanks for the suggestions,

Op 25-04-18 om 07:33 schreef Viktor Dukhovni:
> 
> I've been asked to write up proposed changes to the DNSSEC chain
> extension draft (with the 16-bit extension support lifetime field).
> In doing that I've discovered that adding the 16-bit field is a
> minor tweak to the document text, but, ironically, describing
> denial of existence, though a simple idea, requires extensive
> surgery to the document.  Below I do both, in the hope that either
> or both will prove useful.  Perhaps a concrete proposal will make it
> easier to reach a mutually-agreeable consensus position, and make it
> clear that the requested 16-bits are a reasonable consensus outcome.
> 
> I'm also willing to create a pull request against:
> 
>https://github.com/MelindaShore/dnssec-serialization

We're actually working on

https://github.com/tlswg/dnssec-chain-extension


> if there's interest in me doing that.  Below I list OLD/NEW text
> chunks with the name of the section in which they fit.

If you do, could you please make separate pull requests for denial of
existence and another one for the lifetime field.

Are you sure 16 bits is enough?  Other STS specs appear to use seconds
for the max-age directive.  They are also extensible with new directives
(which have been introduced too, to overcome initial unforeseen
limitations (i.e. preloading)).

Why do you require the SOA?  It is not needed for the denial of
existence (or insecurity) proof.  NSEC ttls tell how long to cache the
non-existence so it is not needed for the minimum field either.


> --- Change 1:  Section 2.  Introduction.
>   * Add denial of existence
> 
> OLD:
> 
>The extension described here allows a TLS client to request that the
>TLS server return the DNSSEC authentication chain corresponding to
>its DANE record.  If the server is configured for DANE
>authentication, then it performs the appropriate DNS queries, builds
>the authentication chain, and returns it to the client.  The server
>will usually use a previously cached authentication chain, but it
>will need to rebuild it periodically as described in Section 5.  The
>client then authenticates the chain using a pre-configured trust
>anchor.
> 
> NEW:
> 
>The extension described here allows a TLS client to request that the
>TLS server return the DNSSEC authentication chain corresponding to
>its DANE TLSA resource record set (RRset), or authenticated denial
>of existence of that RRset.  If the server supports this extension
>it performs the appropriate DNS queries, builds the authentication
>chain, and returns it to the client.  The server will usually
>use a previously cached authentication chain, but it will need
>to rebuild it periodically as described in Section 5.  The client
>then authenticates the chain using a pre-configured trust anchor.
> 
>When the requested TLSA RRset does not exist, and/or the containing
>DNS zone is not DNSSEC-signed, the server MAY return a chain of
>records that establish authenticated denial of existence of the
>TLSA RRset, or prove insecure delegation (an ancestor) of that domain.
>Alternatively, the server MAY simply not negotiate the extension.
> 
> 
> --- Change 2:  Section 3.4.  DNSSEC Authentication Chain Data
>   * Add 16-bit SupportLifetime field
> 
> OLD:
> 
>The "extension_data" field of the "dnssec_chain" extension MUST
>contain a DNSSEC Authentication Chain encoded in the following form:
> 
> 
>  opaque AuthenticationChain<1..2^16-1>
> 
> 
> NEW:
> 
>The "extension_data" field of the "dnssec_chain" extension MUST
>contain a DNSSEC Authentication Chain encoded in the following form:
> 
> struct {
>  uint16 SupportLifetime;
>  opaque AuthenticationChain<1..2^16-1>;
> } DnssecChainExtension;
> 
>A zero "SupportLifetime" prohibits the client from unilaterally
>requiring ongoing use of the extension based on prior observation
>of its use (pinning).
> 
>A future specification will define the semantics of non-zero
>values of the SupportLifetime field.  Servers implementing only
>the present specification MUST set the SupportLifetime element
>to zero.  Clients implementing only the present specification MUST
>treat any value received as though it were zero.
> 
> --- Change 3:  Section 3.4.  DNSSEC Authentication Chain Data
>   * Add denial of existence
> 
> OLD:
> 
>The first RRset in the chain MUST contain the TLSA record set being
>presented.  [...]
> 
>The subsequent RRsets MUST contain the full set of DNS records needed
>to authenticate the TLSA record set from the server's trust anchor.
>[...]
>
> NEW:
> 
>When the response contains validated TLSA records,
>the first RRset in the chain MUST contain the TLSA record set being
>presented.  [...]
> 
>When the response is an authenticated denial of existence, 

Re: [TLS] Proposed text for dnsssec chain extension draft

[Willem Toorop]

Op 25-04-18 om 07:33 schreef Viktor Dukhovni:
>The following is a TLSA RRset denial-of-existence example:
> 
>  example.com. IN SOA
>  RRSIG(example.com. SOA)
>  example.com. IN NSEC www.example.com. SOA NS MX A RRSIG NSEC

Hopefully the DNSKEY rrtype is included in this NSEC too :), so:

   example.com. IN NSEC www.example.com. A NS SOA MX RRSIG NSEC DNSKEY


>  RRSIG(example.com. NSEC)
>  example.com. DNSKEY
>  RRSIG(example.com. DNSKEY)
>  example.com. DS
>  RRSIG(example.com. DS)
>  com. DNSKEY
>  RRSIG(com. DNSKEY)
>  com. DS
>  RRSIG(com. DS)
>  . DNSKEY
>  RRSIG(. DNSKEY)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls