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
