Subject: [Gen-art] Gen-art LC review of draft-ietf-dane-ops-12

From: Elwyn Davies <[email-masked]>
Date: Mon, 22 Jun 2015 19:19:17 +0100

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dane-ops-12.txt
Reviewer: Elwyn Davies
Review Date: 2015/06/19
IETF LC End Date: 2015/06/24
IESG Telechat date: (if known) -

Summary: Almost ready.  There are a couple of minor issues, and I think 
the authors need to reassess whether all the cases where RFC 2119 
keywoDANE and rds are actually protocol requirements as opposed to 
operation best practice recommendations.  Caveat: I am not a DNSSEC 
expert and I can't really be sure about the interactions of DNSSEC and 
DANE.

Major issues:
None

Minor issues:
s3: I am not a security expert, but I suspect you may get some pushback 
on not making TLS 1.2 mandatory.
Also I wonder whether SSL 2.0 and SSL 3.0 should be explicitly ruled 
out? The SECDIR review may say something here.

s3:
> TLS clients and servers using DANE SHOULD support the
>     "Server Name Indication" (SNI) extension of TLS.
Under what circumstances would it be reasonable for a DANE/TLSA server 
not to support SNI?   Maybe I could see that a single domain server 
could do without it.  I think this needs to be spelt out - earlier text 
seems to indicate that SNI support was pretty much mandatory.... Ah! 
Later I see that s5.1 gives a case where SNI is not mandatory - a 
forward pointer would help.

s4.1:  I am not clear that this section adds any value to the discussion 
in s4.  Why should the protocol designer be less inclined to use PKIX-xx 
rather than DANE-xx when the protocol supports an OS mode as opposed to 
just fully authenticated or fully authenticated plus cleartext modes?  
Is there some positive advantage to the DANE-xx authentication failing 
when it comes to deciding whether to proceed with OS?  Otherwise it 
seems to me that this section just says that you can use DANE with an OS 
protocol and the s4 recommendation applies.  It is possible that I do 
not understand what is being said here.

Nits/editorial comments:
=====================

General: The use of 'we' in RFCs is generally deprecated.  There are 
about 20 examples in the draft that need remedying including:
s1, last para: s/In Section 12, we summarize/Section 12 summarizes/
s1.1, definition of Customer Domain:
OLD:
       We will refer to
       the domain name used to locate the service (prior to any
       redirection) as the "Customer Domain".
NEW:
       The domain name used to locate the service (prior to any
       redirection) will be referred to as the "Customer Domain".
END
s1.1, definition of TLSA parameters: s/in fourth/in the fourth/, s/we 
need/it is necessary/,
s/we will call the first three fields/the first three fields will be 
called/
s2, para 5:
OLD:
    We may think of TLSA Certificate Usage values 0 through 3 as a
    combination of two one-bit flags.
NEW:
    The TLSA Certificate Usage values 0 through 3 can be interpreted as a
    combination of two one-bit flags.
END
s5.1, para 1: s/We also extend [RFC6698]/[RFC6698] is also extended/
s6, next to last para: s/we describe an approach/an approach is described/
s8, para 1:
OLD:
    We describe a TLSA
    record update algorithm that ensures this requirement is met.
NEW:
    This document describes a TLSA
    record update algorithm that ensures this requirement is met.
END
s9, para 1:
OLD:
    We specify such a protocol below.
NEW:
    Such a protocol is specified below.
END
s12: Several instances of "we"...
- Bullets 1 - 3: s/we update [RFC6698]/[RFC6698] is updated/
- Bullet 4: s/we explain/explains/
- Bullet 4: s/With usage PKIX-TA(0) we note that/Note that with the 
usage of PKIX-TA(0)/, s/processes/process/
- Bullets 5 and 8: s/In Section x, we recommend/Section x recommends/
- Bullets 6 and 7: s/In Section x we specify/Section x specifies/
----------------

General: I am dubious about the usage of RFC 2119 keywords for 
constraints that are recommendations for operational usage rather than 
protocol on the wire constraints.  In each case, I think the question 
you have to consider is "If the client
or server violates the constraint could the box at the other end of the 
wire tell that the constraint had been violated?"  If the far end can't 
tell then RFC 2119 language is probably inappropriate. AFAICS in at 
least some of the instances this needs to be rechecked - I can't be sure 
in several of the cases.  Examples include:
s4, next to last and last paras:  I think the "MAY" in the last para 
should be "may" - if not probably the "recommends" in the previous para 
should be RECOMMENDS.
s4.1: Again this is an operational suggestion, so s/SHOULD NOT/should 
not/ as the implementation can't really tell it is wrongly used.
s5.1, para 6: s/SHOULD/should/ - operational practice rather than 
protocol specification again.
s5.1, paras 7 and 8:  Probably s/SHOULD NOT/should not/ - I think (but 
am not certain in these cases) that these are again operational practice 
rather than something that is checked in the protocol.
s5.2, paras 1 and 4:  Again the usage of RFC 2118 keywords needs to be 
checked.
----------------------------

Other editorial nits:

s1:  Probably worth repeating that TLSA is not an acronym.

s1: Perhaps worth repeating the expansion of DANE here.

s1, para 1: Need to expand DNSSEC on first use.

s1: Need to expand TLS on first use (currently it happens later).

s1.1, definition of SNI: suggest s/(i.e., "secure virtual 
hosting")./(i.e., provide "secure virtual hosting")./

s2, next to last para:  ASN.1 DER needs a reference - to X.690 (as in 
RFC 6698).

s4.2: I would be inclined to emphasize that RFC 6962 is experimental so 
that this is not an issue that would arise in current operational 
practice - and maybe that a standards track version of CT would be 
better integrated.  Maybe update para 1:
OLD:

    Certificate Transparency (CT) [RFC6962  <https://tools.ietf.org/html/rfc6962>] defines an approach to
    mitigate the risk of rogue or compromised public CAs issuing
    unauthorized certificates.  This section clarifies the interaction of
    CT and DANE.
NEW:
    Certificate Transparency (CT) [RFC6962] defines an experimental approach
    that could be used to mitigate the risk of rogue or compromised public
    CAs issuing unauthorized certificates.  This section clarifies the
    interaction of the experimental CT and DANE.  This interaction may need
    to be revisited in the event that a standards track version of CT is
    developed in future.
END

s4.3:  There appears to be a conflict between the title and second 
sentences vs. the  third sentence:
> When transitioning between PKIX-TA/PKIX-EE and
>     DANE-TA/DANE-EE, clients begin to enable support for the new
>     certificate usage values.
and
> If the new preferred certificate usages
>     are PKIX-TA/EE this requires installing and managing the appropriate
>     set of CA trust anchors.
I don't see why 'new' appears in the third sentence if the scenario is 
transitioning away from PKIX-TA/PKIX-EE.
Am I confused?

s5, title: s/Certificate-Usage/Certificate Usage/ for consistency with 
the rest of the section.

s5.1, para 4: The term "server's primary certificate" does not appear to 
be defined.  I think I can probably guess (something associated with the 
physical host rather than any virtual hosts?) but defining it explicitly 
would be good.

s8.3, para 1: s/each combinations/each combination/

s9, para 3: Expand acronym "MTA".

s9, last para: If it is decided that this is a protocol requirement: 
s/SHOULD not/SHOULD NOT/

s11, para 2: Expand acronym "gTLD".

s17.2: I think RFC7250 is probably normative.

s17.2: I can't decide whether I would like RFC6781 to be normative. It 
would of course be a downref.  This is always going to be a problem 
since the draft is combining operational considerations and protocol 
updates.   The one explicit reference indicates you have to know 
something about how to run DNSSEC to run DANE - in practice I think you 
have to know a great deal about how to run DNSSEC if you are going to 
run DANE so I would be inclined to make this normative (and maybe refer 
to it in the introduction as well).

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 22 Jun 2015 18:52:40 +0000

On Mon, Jun 22, 2015 at 07:19:17PM +0100, Elwyn Davies wrote:

> the authors need to reassess whether all the cases where RFC 2119 keyworrds
> are actually protocol requirements as opposed to operation best practice
> recommendations.

Thanks, will double-check the SHOULDS/MUSTS/...

> s3: I am not a security expert, but I suspect you may get some pushback on
> not making TLS 1.2 mandatory.

We'll see what happens.  The most widely deployed use of DANE is
with opportunistic TLS in SMTP, and requiring TLS 1.2 seems like
an unnecessary restriction for an opportunistic protocol.  However,
non-support of TLS 1.2 is getting increasingly less common, so if
push comes to shove, we can "require" TLS 1.2.  Of course with no
Internet Police to enforce this, the requirement will likely make
little difference in practice.

> Under what circumstances would it be reasonable for a DANE/TLSA server not
> to support SNI?   Maybe I could see that a single domain server could do
> without it.

That's the primary use case, a server with a single certificate,
and a "3 1 1" TLSA record has no need to support SNI.  It can just
respond with the same default certificate, regardless of the SNI
extension value sent by the client.

> I think this needs to be spelt out - earlier text seems to
> indicate that SNI support was pretty much mandatory.... Ah! Later I see that
> s5.1 gives a case where SNI is not mandatory - a forward pointer would help.

Thanks, will try to make the text more consistent throughout.

> s4.1:  I am not clear that this section adds any value to the discussion in
> s4.  Why should the protocol designer be less inclined to use PKIX-xx rather
> than DANE-xx when the protocol supports an OS mode as opposed to just fully
> authenticated or fully authenticated plus cleartext modes?

The basic principle is based on RFC7435.  The issue is that PKIX
is more brittle, the client and server must happen to agree on a
mutually trusted CA, but with OS the client is just trying to
protect the communication at the request of the server, and would
otherwise be willing to use cleartext or unauthenticated TLS.  Use
of fragile mechanisms (like public CA authentication for some
unspecified set of trusted CAs) is not sufficiently reliable.

Since the OS client is basing the decision to employ DANE on the
presence of TLSA RRs in DNS, no additional security is gained via
the PKIX usages unless they are the only ones supported by the
application protocol (the attacker who compromises DNS can just
inject "3 1 1" records instead).  So DANE-xx is more reliable
at no security loss.  Thus PKIX-xx is just a needless opportunity
to fail that should be avoided.

> Nits/editorial comments:

Will review those... thanks.

> s17.2: I can't decide whether I would like RFC6781 to be normative. It would
> of course be a downref.  This is always going to be a problem since the
> draft is combining operational considerations and protocol updates.   The
> one explicit reference indicates you have to know something about how to run
> DNSSEC to run DANE - in practice I think you have to know a great deal about
> how to run DNSSEC if you are going to run DANE so I would be inclined to
> make this normative (and maybe refer to it in the introduction as well).

Not sure what if anything to do about that.

-- 
	Viktor.

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 23 Jun 2015 13:41:23 +0100

Hi, Viktor.

Thanks for the quick response.  I'll wait for the revised draft to 
revisit the RFC 2118 stuff.

I think the TLS1.2 point and the reference to RFC6781 probably need to 
be discussed with Stephen as your AD.  I can't see that you can operate 
DANE without a good understanding of how to operate DNSSEC (particularly 
on the rekeying aspects) and you explicitly call out timeout issues 
discussed in RFC6781.  Whether this needs to administrative hassle of 
the downref is another matter.

There is a bit about the OS issue in line below.

Cheers,
Elwyn

> to fail that should be avoided.
Maybe I have misunderstood how OS is intended to behave.  I thought I 
understood that if the client was able to handle OS and it was not able 
to authenticate the server then it would potentially try for encryption 
only.  Is the problem that there is a difference between there being no 
authentication available for a domain and an attempted authentication 
failing (aside from any explicit policy declared by server or client) 
when using OS?  Otherwise I can't see that there is a difference between 
OS and the general case - in either case, using PKIX-xx is reckoned to 
be fragile and the process takes more resources without gaining 
anything.  I can see the downside, but it appears to be general - is 
there an upside for OS in positively going for DANE-xx or is the 
downside further down in the case of OS? Otherwise there doesn't seem to 
be a lot of point in being more damning for the OS case (apart from it 
being a current topic of development :-) ).

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 23 Jun 2015 13:42:27 +0000

On Tue, Jun 23, 2015 at 01:41:23PM +0100, Elwyn Davies wrote:

> understood that if the client was able to handle OS and it was not able to
> authenticate the server then it would potentially try for encryption only.

No, that is not the case.  With opportunistic DANE TLS, when usable
secure (i.e. DNSSEC validated) TLSA records are present, but
authentication fails, there is typically no fallback to unauthenticated
TLS (mitigate downgrade attacks), for example:

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-3.2

> Is the problem that there is a difference between there being no
> failing (aside from any explicit policy declared by server or client) when
> using OS?

Yes, when no usable secure DANE TLSA records are absent, unauthenticated
TLS is used if possible, and if not perhaps even cleartext.  However,
when TLSA records are published authentication must succeed.  Thus
PKIX-xx auth are to be avoided, because outside the browser space,
there is no pre-ordained canon of trusted CAs, and in any case
there is no value in using them when DANE-xx usages are also
supported.  For most application protocols there should be a clear
statement of which of the two pairs apply (DANE-xx or PKIX-xx) and
the other pair should not be used.

-- 
	Viktor.

---

From: Elwyn Davies <[email-masked]>
Date: Tue, 23 Jun 2015 15:59:20 +0100

Hi, Viktor.

Thanks for clearing up my misunderstanding.

I think it would be worth a sentence or two along the lines of what you 
have written below to clarify why OS is potentially more badly affected 
by fragile PKIX-xx behaviour.

Cheers,
Elwyn