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

[Eric Rescorla]

Yeah this doesn't seem unreasonable

-Ekr


On Thu, Feb 8, 2018 at 8:35 AM, Viktor Dukhovni 
wrote:

>
>
> > On Feb 8, 2018, at 9:49 AM, Eric Rescorla  wrote:
> >
> >> This depends on the mode of DANE in use (i.e. the Certificate Usage
> >> field of the TLSA record). If I recall correctly, this should all be
> >> covered in detail in RFC 7671 ("DANE Updates and Operational Guidance").
> >>
> >> * With DANE-EE, only the EE certificate is matched against the
> >>   certificate data/hash in the TLSA record. There is no CRL/OCSP
> >>   style revocation. Revocation would be performed by removing the
> >>   TLSA record from the DNS.
> >>
> >> * With DANE-TA, the indicated CA certificate referenced in the TLSA
> >>   record may have advertised revocation mechanisms that need to be
> >>   consulted.
> >>
> >> * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation
> mechanisms
> >>   need to be consulted and honored.
> >
> > Well, neither of these modes is useful here, as an attacker will simply
> ignore the
> > extension.
>
> Good point.
>
> Well, if a server publishes "CA constraint" (PKIX-TA(0)) or "service
> certificate constraint" (PKIX-EE(1)) TLSA records, presumably it is
> precisely because they believe that PKIX alone is not enough, and
> would like to require at least one of the specified constraints to
> be satisfied.
>
> So if the records do make it to the client, the client should
> probably honour them if it is doing DANE-based authentication.
>
> However, as you correctly observe, with this in-band TLSA record
> delivery mechanism, an attacker who is able to able PKIX-verifiable
> certificates and keys for the target domain can simply not respond
> with the extension and deliver just the PKIX key material.  So if
> a client is willing to go with just PKIX for servers that don't
> support the extension, then it subject to a "dane-stripping"
> downgrade attack when using this mechanism.
>
> We should also note that clients might cache the obtained TLSA
> records, and so might not accept just PKIX while cached records
> are available, even if TLSA records are stripped on a subsequent
> connection.
>
> But the key question boils down to whether the client is configured
> to *require* DANE for the connection (in which case just PKIX is
> clearly not enough), or whether it is doing a form of "opportunistic
> DANE" (for lack of a better term in this message) with the server
> optionally providing the records, but otherwise the client resorts
> to using just PKIX.
>
> In the "opportunistic DANE" case one might argue that, when PKIX-TA(0)
> or PKIX-EE(1) fail, but PKIX alone would otherwise succeed, the client
> should accept PKIX alone, since a downgrade attack can typically strip
> DANE.  But if the client is caching previously seen TLSA records, then
> the downgrade attack is partially mitigated (for the TTL of the cached
> records).  The client may elect to request new TLSA records before the
> expiration of the previous ones are expired, extending such protection
> until it stops communicating with the server sufficiently regularly to
> be able to keep a copy of unexpired TLSA records in its cache.
>
> So all in all, I think there may be enough merit in rejecting on DANE
> failure, subject to local policy, but the client might elect to trust
> bare PKIX.
>
> For clients that do reject PKIX success based on DANE failure, and
> cache obtained TLSA records, it might have been good to recommend
> refreshing the TLSA records while the cached data is still valid
> (say the smaller of some refresh time or 50% of TTL has expired).
> That way, for a client that keeps communicating regularly may be
> (partially) protected against downgrades.  Perhaps it is too late
> to make such a change at this stage in the document's life-cycle.
>
> Summary as I see it:
>
>   * Mandatory DANE:
>   MUST Refuse absence of TLSA RRs or failure
> of PKIX-TA(0) and PKIX-EE(1).  Must fail when no TLSA RRs
> are cache and the server does not present the extension.
>
>   * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1)
> if caching replies, and SHOULD attempt to refresh cache before
> expiration to reduce opportunity for downgrades.  Non-caching
> clients don't really gain security by refusing valid PKIX on
> DANE failure, and MAY choose to continue.
>
> --
> Viktor.
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt

[Alessandro Ghedini]

On Wed, Jan 31, 2018 at 03:41:34PM -0600, Benjamin Kaduk wrote:
> On 01/30/2018 04:02 PM, Victor Vasiliev wrote:
> > I also wondered whether there was any sense in reserving codepoint
> > 0 (of
> > CertificateCompressionAlgorithm) for "uncompressed".  I guess not,
> > since
> > support for uncompressed certificates is implicit by means of not
> > using
> > the extension.  But sometimes keeping value 0 (basically) reserved is
> > still useful.
> >
> >
> > I've considered that, but decided that this would just introduce two
> > ways to do
> > the same thing (send certificate uncompressed), so I decided against it.
> 
> Sure.  I don't see a reason to add a code point for uncompressed, but
> maybe there is an aesthetic argument for leaving 0 reserved entirely. 
> But I definitely do not insist on anything.

Yeah, makes sense to keep 0 reserved. I made a PR for this:
https://github.com/tlswg/certificate-compression/pull/12

and looks like Victor already merged it.

Cheers

___
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)

[Viktor Dukhovni]

> On Feb 8, 2018, at 9:49 AM, Eric Rescorla  wrote:
> 
>> This depends on the mode of DANE in use (i.e. the Certificate Usage
>> field of the TLSA record). If I recall correctly, this should all be
>> covered in detail in RFC 7671 ("DANE Updates and Operational Guidance").
>> 
>> * With DANE-EE, only the EE certificate is matched against the
>>   certificate data/hash in the TLSA record. There is no CRL/OCSP
>>   style revocation. Revocation would be performed by removing the
>>   TLSA record from the DNS.
>> 
>> * With DANE-TA, the indicated CA certificate referenced in the TLSA
>>   record may have advertised revocation mechanisms that need to be
>>   consulted.
>> 
>> * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation mechanisms
>>   need to be consulted and honored.
> 
> Well, neither of these modes is useful here, as an attacker will simply 
> ignore the
> extension.

Good point.

Well, if a server publishes "CA constraint" (PKIX-TA(0)) or "service
certificate constraint" (PKIX-EE(1)) TLSA records, presumably it is
precisely because they believe that PKIX alone is not enough, and
would like to require at least one of the specified constraints to
be satisfied.

So if the records do make it to the client, the client should
probably honour them if it is doing DANE-based authentication.

However, as you correctly observe, with this in-band TLSA record
delivery mechanism, an attacker who is able to able PKIX-verifiable
certificates and keys for the target domain can simply not respond
with the extension and deliver just the PKIX key material.  So if
a client is willing to go with just PKIX for servers that don't
support the extension, then it subject to a "dane-stripping"
downgrade attack when using this mechanism.

We should also note that clients might cache the obtained TLSA
records, and so might not accept just PKIX while cached records
are available, even if TLSA records are stripped on a subsequent
connection.

But the key question boils down to whether the client is configured
to *require* DANE for the connection (in which case just PKIX is
clearly not enough), or whether it is doing a form of "opportunistic
DANE" (for lack of a better term in this message) with the server
optionally providing the records, but otherwise the client resorts
to using just PKIX.

In the "opportunistic DANE" case one might argue that, when PKIX-TA(0)
or PKIX-EE(1) fail, but PKIX alone would otherwise succeed, the client
should accept PKIX alone, since a downgrade attack can typically strip
DANE.  But if the client is caching previously seen TLSA records, then
the downgrade attack is partially mitigated (for the TTL of the cached
records).  The client may elect to request new TLSA records before the
expiration of the previous ones are expired, extending such protection
until it stops communicating with the server sufficiently regularly to
be able to keep a copy of unexpired TLSA records in its cache.

So all in all, I think there may be enough merit in rejecting on DANE
failure, subject to local policy, but the client might elect to trust
bare PKIX.

For clients that do reject PKIX success based on DANE failure, and
cache obtained TLSA records, it might have been good to recommend
refreshing the TLSA records while the cached data is still valid
(say the smaller of some refresh time or 50% of TTL has expired).
That way, for a client that keeps communicating regularly may be
(partially) protected against downgrades.  Perhaps it is too late
to make such a change at this stage in the document's life-cycle.

Summary as I see it:

  * Mandatory DANE:
 MUST Refuse absence of TLSA RRs or failure
of PKIX-TA(0) and PKIX-EE(1).  Must fail when no TLSA RRs
are cache and the server does not present the extension.

  * "Opportunistic DANE": MAY refuse failed PKIX-TA(0) and PKIX(1)
if caching replies, and SHOULD attempt to refresh cache before
expiration to reduce opportunity for downgrades.  Non-caching
clients don't really gain security by refusing valid PKIX on
DANE failure, and MAY choose to continue.

-- 
Viktor.

___
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)

[Eric Rescorla]

On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque  wrote:

> On Wed, Feb 7, 2018 at 9:34 AM, Eric Rescorla  wrote:
>
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-tls-dnssec-chain-extension-06: Discuss
>>
>
> Thanks Eric for your detailed review and comments.
>
> > This draft seems generally sound, but I believe there are pieces that
> > are still underspecified. These should be easy to fix.
> >
> > the Signer's Name field in canonical form and the signature field
> >excluded.
> >
> > IMPORTANT: I'm not sure that this is actually sufficient to allow an
> > independent implementation without referring to the other documents. I
> > mean, I think I pretty clearly can't validate this chain from the
> > above.
>
> We could add an explicit reference here to the DNS protocol document(s)
> and sections within them that define the canonical form of domain
> names (RFC 4034, Section 6 probably is the best reference), or even
> excerpt the relevant text from that document. Would this satisfy your
> concern?
>

Well, and remove your text about it being possible to implement solely from
this
document.


We deliberately didn't include in this document a detailed description
> of the DNSSEC validation algorithm. The algorithm is sufficiently
> complicated (and lengthy to describe) that those details are best left
> to the relevant DNSSEC RFCs. I think it would be helpful to point
> specifically to which documents and sections here though (mainly
> RFC 4035 Section 5, and RFC 5155 Section 8). We could also include a
> brief synopsis of the algorithm and refer to these documents for
> further details.
>

It's not the algorithm. I don't believe this document is sufficient to
parse the
structure.


Otherwise, can you suggest more specifically what level of additional
> detail you'd like to see in this document?
>

See above.


> Similarly, although I think this is enough to break apart the
> > RRSETs into RRs, it doesn't tell me how to separate the RRSETs from
> > each other. I think you need to either make this a lot more complete
> > or alternately stop saying it's sufficient.
>
> We can add some text about this. Basically the client would scan the chain
> reading RRs and group adjacent RRs that share the same RR name, type, and
> class into a distinct RRset.
>

I'd have to review your text to know if it was sufficient.


>
> >abort the connection, the server uses the domain name associated with
> >the server IP address to which the connection has been established.
> > IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple
> names for the same IP.
> >
>
> Yes, indeed. This sentence is dealing with the case where the client has
> not indicated to the server which name it wants to connect to, so the
> server is basically guessing anyway. Perhaps we could reword this to say
> something like, "the server picks one of its configured domain names for
> the associated IP address".
>

Yes, that would be fine.


(This situation could also have been avoided by mandating client use of
> the SNI extension).
>
> >DNSSEC authentication chain extension from a server, SHOULD use this
> >information to perform DANE authentication of the server.  In order
> >to do this, it uses the mechanism specified by the DNSSEC protocol
> >
> > IMPORTANT: What happens if the DANE validates but the cert is revoked
> > or alternately the cert validates but DANE does not?
>
> This depends on the mode of DANE in use (i.e. the Certificate Usage
> field of the TLSA record). If I recall correctly, this should all be
> covered in detail in RFC 7671 ("DANE Updates and Operational Guidance").
>
> * With DANE-EE, only the EE certificate is matched against the
>   certificate data/hash in the TLSA record. There is no CRL/OCSP
>   style revocation. Revocation would be performed by removing the
>   TLSA record from the DNS.
>
> * With DANE-TA, the indicated CA certificate referenced in the TLSA
>   record may have advertised revocation mechanisms that need to be
>   consulted.
>
> * With PKIX-EE and PKIX-TA modes, the standard PKIX revocation mechanisms
>   need to be consulted and honored.
>

Well, neither of these modes is useful here, as an attacker will simply
ignore the
extension.


Would you like us to discuss this in the draft? Or is referring to
> RFC 7671 sufficient?
>

I think you should discuss it in the draft as it is relevant to TLS
implementation.



On your last case, "cert validates but DANE does not", I assume
> you mean the cert validates via PKIX but not DANE? I'm not sure this
> is explicitly discussed in any other DANE document but presumably
> if DANE is being used, DANE must validate.
>

Why would that be so? This only is useful in DANE-EE and DANE-TA modes in
the first place, and so there is a possibilityt aht PKIX is valid.


 note, I believe most envisioned use cases of this draft
> will be for the DANE-* modes. The PKIX constraining modes 

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

[Shumon Huque]

On Thu, Feb 8, 2018 at 4:51 AM, Willem Toorop  wrote:

> Op 08-02-18 om 03:27 schreef Shumon Huque:
> > On Wed, Feb 7, 2018 at 8:21 AM, Mirja Kühlewind  > > 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).
>

Ah, thanks. I'd forgotten that it was so high!

I think my "relatively small" comment was recalling an earlier study (I
think by
Google) that saw a breakage of around ~ 5%, but I think that was just
measuring
the ability to lookup and obtain less common RR types and did not measure
ability
to perform full DNSSEC validation.

Shumon.
___
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)

[Shumon Huque]

On Wed, Feb 7, 2018 at 9:34 AM, Eric Rescorla  wrote:

> Eric Rescorla has entered the following ballot position for
> draft-ietf-tls-dnssec-chain-extension-06: Discuss
>

Thanks Eric for your detailed review and comments.

> This draft seems generally sound, but I believe there are pieces that
> are still underspecified. These should be easy to fix.
>
> the Signer's Name field in canonical form and the signature field
>excluded.
>
> IMPORTANT: I'm not sure that this is actually sufficient to allow an
> independent implementation without referring to the other documents. I
> mean, I think I pretty clearly can't validate this chain from the
> above.

We could add an explicit reference here to the DNS protocol document(s)
and sections within them that define the canonical form of domain
names (RFC 4034, Section 6 probably is the best reference), or even
excerpt the relevant text from that document. Would this satisfy your
concern?

We deliberately didn't include in this document a detailed description
of the DNSSEC validation algorithm. The algorithm is sufficiently
complicated (and lengthy to describe) that those details are best left
to the relevant DNSSEC RFCs. I think it would be helpful to point
specifically to which documents and sections here though (mainly
RFC 4035 Section 5, and RFC 5155 Section 8). We could also include a
brief synopsis of the algorithm and refer to these documents for
further details.

Otherwise, can you suggest more specifically what level of additional
detail you'd like to see in this document?

> Similarly, although I think this is enough to break apart the
> RRSETs into RRs, it doesn't tell me how to separate the RRSETs from
> each other. I think you need to either make this a lot more complete
> or alternately stop saying it's sufficient.

We can add some text about this. Basically the client would scan the chain
reading RRs and group adjacent RRs that share the same RR name, type, and
class into a distinct RRset.

>
>abort the connection, the server uses the domain name associated with
>the server IP address to which the connection has been established.
> IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple
names for the same IP.
>

Yes, indeed. This sentence is dealing with the case where the client has
not indicated to the server which name it wants to connect to, so the
server is basically guessing anyway. Perhaps we could reword this to say
something like, "the server picks one of its configured domain names for
the associated IP address".

(This situation could also have been avoided by mandating client use of
the SNI extension).

>DNSSEC authentication chain extension from a server, SHOULD use this
>information to perform DANE authentication of the server.  In order
>to do this, it uses the mechanism specified by the DNSSEC protocol
>
> IMPORTANT: What happens if the DANE validates but the cert is revoked
> or alternately the cert validates but DANE does not?

This depends on the mode of DANE in use (i.e. the Certificate Usage
field of the TLSA record). If I recall correctly, this should all be
covered in detail in RFC 7671 ("DANE Updates and Operational Guidance").

* With DANE-EE, only the EE certificate is matched against the
  certificate data/hash in the TLSA record. There is no CRL/OCSP
  style revocation. Revocation would be performed by removing the
  TLSA record from the DNS.

* With DANE-TA, the indicated CA certificate referenced in the TLSA
  record may have advertised revocation mechanisms that need to be
  consulted.

* With PKIX-EE and PKIX-TA modes, the standard PKIX revocation mechanisms
  need to be consulted and honored.

Would you like us to discuss this in the draft? Or is referring to
RFC 7671 sufficient?

On your last case, "cert validates but DANE does not", I assume
you mean the cert validates via PKIX but not DANE? I'm not sure this
is explicitly discussed in any other DANE document but presumably
if DANE is being used, DANE must validate. I suppose individual
application protocols could specify a fallback mode where the
client could fallback to normal PKIX if DANE failed.

On a related note, I believe most envisioned use cases of this draft
will be for the DANE-* modes. The PKIX constraining modes have the
issue that for them to work securely, the client must be able to
confirm the presence of DANE records, which leads to the issues of how
to mandate use of this mechanism (Section 8 of this document).


> [RFC4035] [RFC5155].  This mechanism is sometimes implemented in a
>DNSSEC validation engine or library.
> IMPORTANT: shouldn't it be a requirement to perform this validation?

Your question I assume is about the sentence preceding this:

   "A TLS client making use of this specification, and which receives a
   DNSSEC authentication chain extension from a server, SHOULD use this
   information to perform DANE authentication of the server."

Yes, I think I agree. If the client 

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  > 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