Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS

[Ted Lemon]

Not an argument in favor of the proposal, but the issue with firewall certs
is not that we would want to override local security policy, but that
firewall certs *can* in principle override local security policy, and in
principle DANE could be used to prevent that.   What is meant by a firewall
cert is a cert that's able to sign for any domain; such certs can in
principle be obtained by entities other than the operator of the local
firewall.   We're calling them firewall certs because that's the ostensible
reason for their existence, but we shouldn't assume that the name has any
power to restrict how they are used. :)

On Tue, Oct 16, 2018 at 3:45 AM Ryan Sleevi  wrote:

>
>
> On Mon, Oct 15, 2018 at 4:50 PM Viktor Dukhovni 
> wrote:
>
>> Though I am generally an advocate for DANE, and have done much work to
>> further its adoption, this is not a realistic proposal.  DANE adoption
>> in TLS will be incremental and will not be accomplished via a mandate.
>>
>> > On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics
>>  wrote:
>> >
>> > TLS is prone to Man-In-The-Middle attacks with unjustly obtained
>> intermediate certificates (e.g. firewall appliances).
>> > The DNSSEC KSK-rollover worked like a charm.
>> >
>> > So I suggest to make DANE-TLS mandatory for TLS to prevent
>> Man-In-The-Middle attacks with unjustly obtained intermediate certificates.
>>
>
> I think there's another criticism to be leveled at this proposal, and it's
> suitability for this WG - the motivation stated (firewall appliances) is a
> question about local policy. I admit my own ignorance here, in that I'm not
> sure how https://tools.ietf.org/html/draft-nottingham-for-the-users has
> been progressing as a comparable alternative to the HTML Priority of
> Constituencies. However, as engineers, we need to recognize that no matter
> what is memorialized by the IETF, if you have control over the machine - as
> these enterprises inevitably do to install their firewall appliance - all
> bets are off. We should not pretend we will prevent that, nor should we
> increase costs for the ecosystem in pursuit of that effort.
> ___
> 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] Make DANE-TLS (RFC 6698) mandatory for TLS

[Rene 'Renne' Bartsch, B.Sc. Informatics]

Unjust certificates can be bought for 150,- $ in the darknet which makes TLS 
snake-oil. And you never know if the internet provider is hostile or hacked.
So we should act in the favor of end-users. If we don't have the position to 
make DANE mandatory, yet, we should at least try to encourage browser vendors
to support DANE. Just think about all the online-banking websites without 
DNSSEC/DANE protection.


Am 15.10.18 um 22:49 schrieb Viktor Dukhovni:

Though I am generally an advocate for DANE, and have done much work to
further its adoption, this is not a realistic proposal.  DANE adoption
in TLS will be incremental and will not be accomplished via a mandate.


On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics 
 wrote:

TLS is prone to Man-In-The-Middle attacks with unjustly obtained intermediate 
certificates (e.g. firewall appliances).
The DNSSEC KSK-rollover worked like a charm.

So I suggest to make DANE-TLS mandatory for TLS to prevent Man-In-The-Middle 
attacks with unjustly obtained intermediate certificates.


If you want to see more DANE deployment, work on tooling to ease
DNSSEC deployment, convince registries to support CDS and CDS0,
simplify zone signing and key rollover interfaces in nameserver
implementations, develop monitoring tools, ...  Get efforts to
improve the tools funded, ...

There is much work to be done, before we can expect ubiquitous
DNSSEC support, let alone DANE.  DNSSEC deployment is concentrated
at domains hosted by providers who have invested in automating it.
To bring it to the masses, it must be something that works out of
the box.

Until then it should be possible to use DNSSEC and DANE with TLS,
but we're quite far from being in a position to mandate their use.



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

Re: [TLS] Make DANE-TLS (RFC 6698) mandatory for TLS

[Richard Barnes]

On Tue, Oct 16, 2018 at 10:02 AM Rene 'Renne' Bartsch, B.Sc. Informatics
 wrote:

> Unjust certificates can be bought for 150,- $


[citation-needed]

https://xkcd.com/285/

I'm sure if you could produce such a certificates, the root programs would
be happy to investigate how it was caused to be issued.

--Richard


> in the darknet which makes TLS snake-oil. And you never know if the
> internet provider is hostile or hacked.
> So we should act in the favor of end-users. If we don't have the position
> to make DANE mandatory, yet, we should at least try to encourage browser
> vendors
> to support DANE. Just think about all the online-banking websites without
> DNSSEC/DANE protection.
>
>
> Am 15.10.18 um 22:49 schrieb Viktor Dukhovni:
> > Though I am generally an advocate for DANE, and have done much work to
> > further its adoption, this is not a realistic proposal.  DANE adoption
> > in TLS will be incremental and will not be accomplished via a mandate.
> >
> >> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics
>  wrote:
> >>
> >> TLS is prone to Man-In-The-Middle attacks with unjustly obtained
> intermediate certificates (e.g. firewall appliances).
> >> The DNSSEC KSK-rollover worked like a charm.
> >>
> >> So I suggest to make DANE-TLS mandatory for TLS to prevent
> Man-In-The-Middle attacks with unjustly obtained intermediate certificates.
> >
> > If you want to see more DANE deployment, work on tooling to ease
> > DNSSEC deployment, convince registries to support CDS and CDS0,
> > simplify zone signing and key rollover interfaces in nameserver
> > implementations, develop monitoring tools, ...  Get efforts to
> > improve the tools funded, ...
> >
> > There is much work to be done, before we can expect ubiquitous
> > DNSSEC support, let alone DANE.  DNSSEC deployment is concentrated
> > at domains hosted by providers who have invested in automating it.
> > To bring it to the masses, it must be something that works out of
> > the box.
> >
> > Until then it should be possible to use DNSSEC and DANE with TLS,
> > but we're quite far from being in a position to mandate their use.
> >
>
> ___
> 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] Make DANE-TLS (RFC 6698) mandatory for TLS

[Ted Lemon]

Can you provide a citation for that statement?   Not doubting you,
particularly, but this is news to me, and probably to some others on this
list, if true.

On Tue, Oct 16, 2018 at 4:01 PM Rene 'Renne' Bartsch, B.Sc. Informatics
 wrote:

> Unjust certificates can be bought for 150,- $ in the darknet which makes
> TLS snake-oil. And you never know if the internet provider is hostile or
> hacked.
> So we should act in the favor of end-users. If we don't have the position
> to make DANE mandatory, yet, we should at least try to encourage browser
> vendors
> to support DANE. Just think about all the online-banking websites without
> DNSSEC/DANE protection.
>
>
> Am 15.10.18 um 22:49 schrieb Viktor Dukhovni:
> > Though I am generally an advocate for DANE, and have done much work to
> > further its adoption, this is not a realistic proposal.  DANE adoption
> > in TLS will be incremental and will not be accomplished via a mandate.
> >
> >> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics
>  wrote:
> >>
> >> TLS is prone to Man-In-The-Middle attacks with unjustly obtained
> intermediate certificates (e.g. firewall appliances).
> >> The DNSSEC KSK-rollover worked like a charm.
> >>
> >> So I suggest to make DANE-TLS mandatory for TLS to prevent
> Man-In-The-Middle attacks with unjustly obtained intermediate certificates.
> >
> > If you want to see more DANE deployment, work on tooling to ease
> > DNSSEC deployment, convince registries to support CDS and CDS0,
> > simplify zone signing and key rollover interfaces in nameserver
> > implementations, develop monitoring tools, ...  Get efforts to
> > improve the tools funded, ...
> >
> > There is much work to be done, before we can expect ubiquitous
> > DNSSEC support, let alone DANE.  DNSSEC deployment is concentrated
> > at domains hosted by providers who have invested in automating it.
> > To bring it to the masses, it must be something that works out of
> > the box.
> >
> > Until then it should be possible to use DNSSEC and DANE with TLS,
> > but we're quite far from being in a position to mandate their use.
> >
>
> ___
> 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] Make DANE-TLS (RFC 6698) mandatory for TLS

[Rene 'Renne' Bartsch, B.Sc. Informatics]

I haven't found the article with 150,- $, yet, but this isn't good either:

https://www.bankinfosecurity.com/study-finds-custom-market-for-bogus-tls-certificates-a-10680

and Mozilla makes it worse:

https://blog.mozilla.org/security/2018/10/10/delaying-further-symantec-tls-certificate-distrust/


Am 16.10.18 um 16:06 schrieb Ted Lemon:

Can you provide a citation for that statement?   Not doubting you, 
particularly, but this is news to me, and probably to some others on this list, 
if true.

On Tue, Oct 16, 2018 at 4:01 PM Rene 'Renne' Bartsch, B.Sc. Informatics 
mailto:40bartschnet...@dmarc.ietf.org>> 
wrote:

Unjust certificates can be bought for 150,- $ in the darknet which makes 
TLS snake-oil. And you never know if the internet provider is hostile or hacked.
So we should act in the favor of end-users. If we don't have the position 
to make DANE mandatory, yet, we should at least try to encourage browser vendors
to support DANE. Just think about all the online-banking websites without 
DNSSEC/DANE protection.


Am 15.10.18 um 22:49 schrieb Viktor Dukhovni:
 > Though I am generally an advocate for DANE, and have done much work to
 > further its adoption, this is not a realistic proposal.  DANE adoption
 > in TLS will be incremental and will not be accomplished via a mandate.
 >
 >> On Oct 15, 2018, at 4:20 PM, Rene 'Renne' Bartsch, B.Sc. Informatics 
mailto:40bartschnet...@dmarc.ietf.org>> wrote:
 >>
 >> TLS is prone to Man-In-The-Middle attacks with unjustly obtained 
intermediate certificates (e.g. firewall appliances).
 >> The DNSSEC KSK-rollover worked like a charm.
 >>
 >> So I suggest to make DANE-TLS mandatory for TLS to prevent 
Man-In-The-Middle attacks with unjustly obtained intermediate certificates.
 >
 > If you want to see more DANE deployment, work on tooling to ease
 > DNSSEC deployment, convince registries to support CDS and CDS0,
 > simplify zone signing and key rollover interfaces in nameserver
 > implementations, develop monitoring tools, ...  Get efforts to
 > improve the tools funded, ...
 >
 > There is much work to be done, before we can expect ubiquitous
 > DNSSEC support, let alone DANE.  DNSSEC deployment is concentrated
 > at domains hosted by providers who have invested in automating it.
 > To bring it to the masses, it must be something that works out of
 > the box.
 >
 > Until then it should be possible to use DNSSEC and DANE with TLS,
 > but we're quite far from being in a position to mandate their use.
 >

___
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] Make DANE-TLS (RFC 6698) mandatory for TLS

[Ryan Sleevi]

On Tue, Oct 16, 2018 at 11:00 AM Rene 'Renne' Bartsch, B.Sc. Informatics
 wrote:

> I haven't found the article with 150,- $, yet, but this isn't good either:
>
>
> https://www.bankinfosecurity.com/study-finds-custom-market-for-bogus-tls-certificates-a-10680
>
> and Mozilla makes it worse:
>
>
> https://blog.mozilla.org/security/2018/10/10/delaying-further-symantec-tls-certificate-distrust/


I'm afraid that taking that article and extrapolating that it undermines
SSL is, unfortunately, a bit unsupported.

It's certainly true that "bad actors" are able to misrepresent and
circumvent a number of CAs' "Extended Validation" practices. This can range
from CAs using unreliable datasources (like Dun & Bradstreet) or to CAs
having poor practices regarding acceptable documentation. However, in the
examples mentioned in that article (and related, as I recall when that came
out), the attack is not that the attacker bypasses the domain name
verification process. Instead, the attacker fully controls their own domain
name, and they fool the CA into providing additional assertions about that
domain name that aren't legitimate - such as what company or entity is
operating that domain name. The same applies for EV Code Signing
certificates (which aren't bound to domains, but organizations) - by
fooling the organization vetting process, systems that rely on the
organization information - not the domain name - are the ones put at risk.

DANE/DNSSEC would not address that concern, because its largely orthogonal
to such extended validation. Indeed, what DANE/DNSSEC would address is
exactly the thing that's working and not been compromised - the domain
validation part (especially in light of CAA).

If your goal is to minimize risk, then I think a key takeaways would be not
to rely on organization information in certificates - and instead focus on
the domain name. Similarly, rather than promoting DANE/DNSSEC in browsers,
you could encourage browsers to adopt solutions like Apple has done in
Safari on macOS Mojave - no longer present extended validation UI to users
( https://www.troyhunt.com/extended-validation-certificates-are-dead/ ), so
that they can instead reliably use the domain name.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] HELLO_VERIFY_REQUEST during abbreviated handshake (session resumption)

[Eric Rescorla]

Hi Simon,

I don't think we specified a concrete recommendation, but I think the
answer is probably no. The reason is that:

(a) a resumed handshake is very cheap, so it's not really saving CPU
(b) the server's first flight is small in resumption, so amplification
isn't much of an issue.

Maybe I'm missing something though.

-Ekr




On Wed, Oct 3, 2018 at 7:05 AM Simon Bernard 
wrote:

> Hi,
>
> In DTLS 1.2 over UDP, I would like to know what is the
> recommendation about using HELLO_VERIFY_REQUEST during an abbreviated
> handshake.
>
> Should we send it all the time ? or could we avoid to send it if
> SESSION ID is known ?
>
> Thx,
>
>
> Simon
>
> ___
> 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] [Errata Rejected] RFC6176 (5520)

[Eugène Adell]

@Florian

The document is about the SSL 2.0 security deficiencies, particularly the
ones that brought its prohibition. The solutions to these deficiencies
might also have their own problems, as it's often the case in security
related topics which look like a never-ending debate (a problem, a
solution, a new problem), and they would logically be discussed in their
own threads or we would easily make anachronistic comments. The mitigation
of a root authority has a huge impact, and requires time to solve, that's
what said at that time, although it happened much later to some issuers.
In practice we see that direct signed certificates for Internet use were
abandoned, without anyone returning back to them. Also, the HSMs are
getting more widely used, and it gives more protection to the keying
material (which is an answer to the "overexposed keys").


@Ryan

Thanks. There's also that link
https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ which is
almost saying the same. But at the same time RFC6176 is not exactly a
protocol description, it's a limited update to existing protocols that had
warned us this update would be published one day. Submitting an update for
a non technical part of this RFC doesn't make much sense too, maybe no more
than a rejected errata.

Le mar. 16 oct. 2018 à 08:12, Florian Weimer  a écrit :

> * RFC Errata System:
>
> > Corrected Text
> > --
>
> >o  The root certificate authority keys are overexposed. The server
> >   sends only one certificate signed by a root certificate authority,
> >   which means a frequent use of this authority keys for signing new
> >   certificates. This use can lead to key loss and the compromise of
> >   all certificates previously signed including the root certificate..
> >
> > Notes
> > -
> > Adding a deficiency.
> > Recent history showed that well-known authorities could loose their keys
> and it had a wide impact on security.
> > SSL 2.0 limits the certificate handshake message to one single
> certificate, thus making it impossible to send a certificate chain.
> > A certificate chain doesn't completely prevent key loss, but it gives
> more protection to the root certificate keys which can be stored and hidden
> until we need them again, which is much less often than without chaining.
> >
> >
> >
> >  --VERIFIER NOTES--
> >This isn't an error in the original document. It's new text you want
> to add.
>
> I think it's also historically incorrect.  More security problems were
> caused by the ability to introduce arbitrary intermediate certificates
> by CAs than by too many direct signing operations with a root CA key.
> At least for web use, the original model (which does not allow
> delegation of trust on the CA side) might actually have been more
> approriate.  (On the RA side, delegation is of course technically
> possible under any model, and it had its share of problems, too.)
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[Daniel Kahn Gillmor]

Hi all--

I'm disappointed in how long this WG is taking to get
draft-ietf-tls-dnssec-chain-extension out the door.

I agree with both Tom and Viktor that the current draft seems to be
misaligned between the goals and the stated scope.

I wanted the draft to be done by now because i think it will be useful
in "greenfield" scenarios -- ones where the use case itself can mandate
the extension without negotiation, but i understand Viktor's point that
without any sort of negotiated pinning mechanism, the draft is probably
not useful for non-greenfield scenarios (without pinning the existence
of the extension, it cannot reduce the attack surface represented by the
CAs, and instead only represents an additional vector of attack).

I can understand why people want to be able to make this useful for
non-greenfield scenarios, but it appears that we're hung up on the
pinning details.  I actually don't think that extension pinning needs to
be particularly hard, and i don't think it's as dangerous as HPKP's
pinning, but i won't go too far into the weeds here.  Just a quick
summary of my understanding:

 * The existence of a pin only requires that the service operator
   maintain the ability to respond to this extension in the future -- it
   doesn't require specific keys, or even the use of DANE itself.  It is
   not nearly as large a risk as HPKP's pins were.

 * Pinning fears are based on two scenarios: (a) footgun, where the
   service operator makes a mistake, or (b) a malicious pin is set by an
   adversary who has owned your domain.  (a) is overwhelmingly more
   common, and is what we should focus on.  In the (a) scenario, the
   admin has already deployed the extension, so there is no risk.  The
   (b) scenario only matters if a service cannot deploy the extension as
   intended, which is more of a chicken/egg problem of deployment and
   implementation.  I don't think that's a huge risk but if we really
   want to try to cover it, i think there are ways that we could
   minimize it as well.

That said, it sounds like negotiating the details of how to do this
pinning is the main blocker, and i'm sick of this proposal being blocked
(because i want it for "greenfield" implementations last year).

So one way forward would be to complete this extension without the
pinning (explicitly acknowledging that it will not be useful for
non-greenfield implementations on its own) and get it out the door.
Then we can subsequently create a new extension that is only a
"how-to-pin-dnssec-chain-extension".

This is an approach that would expose at the protocol layer the ugly
truth about how hard it is to get something through the IETF process,
but if it helps to break the impasse, i'd be all for it.  I'm willing to
provide text for why this is only useful for greenfield implementations,
if asked.

Alternately, if people could agree on a simple and clear pinning scheme
that we could get out the door all in one piece, i'd be happy with that
too.

I will be sad if we manage to not get anything at all completed for
another year.

   --dkg, tired of waiting


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] WGLC for draft-ietf-tls-sni-encryption

[Sean Turner]

All,

This is the working group last call for the "Issues and Requirements for SNI 
Encryption in TLS" draft available at 
http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/.  Please review 
the document and send your comments to the list by 2359 UTC on 31 October 2018.

Thanks your chairs: C-J-S
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-sni-encryption

[Sean Turner]

All,

I ran I-D nits before hitting the appropriate buttons to place this draft in 
WGLC.  I figured we could address the following before we send the draft to Ben:

  == Outdated reference: draft-ietf-tls-tls13 has been
   published as RFC 8446

  == Outdated reference: A later version (-14) exists of
   draft-ietf-doh-dns-over-https-08

  == Outdated reference: A later version (-15) exists of
   draft-ietf-quic-tls-11

  == Outdated reference: A later version (-28) exists of
   draft-ietf-tls-dtls13-26

  == Outdated reference: draft-mm-wg-effect-encrypt has
   been published as RFC 8404

To answer the other 5 I-D nits questions "Obsolete informational reference (is 
this intentional?)” - the answer is yes.

spt

> On Oct 16, 2018, at 18:43, Sean Turner  wrote:
> 
> All,
> 
> This is the working group last call for the "Issues and Requirements for SNI 
> Encryption in TLS" draft available at 
> http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/.  Please 
> review the document and send your comments to the list by 2359 UTC on 31 
> October 2018.
> 
> Thanks your chairs: C-J-S

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

Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[Viktor Dukhovni]

> On Oct 16, 2018, at 6:16 PM, Daniel Kahn Gillmor  
> wrote:
> 
> Just a quick summary of my understanding:
> 
> * The existence of a pin only requires that the service operator
>   maintain the ability to respond to this extension in the future -- it
>   doesn't require specific keys, or even the use of DANE itself.  It is
>   not nearly as large a risk as HPKP's pins were.
> 
> * Pinning fears are based on two scenarios: (a) footgun, where the
>   service operator makes a mistake, or (b) a malicious pin is set by an
>   adversary who has owned your domain.  (a) is overwhelmingly more
>   common, and is what we should focus on.  In the (a) scenario, the
>   admin has already deployed the extension, so there is no risk.  The
>   (b) scenario only matters if a service cannot deploy the extension as
>   intended, which is more of a chicken/egg problem of deployment and
>   implementation.  I don't think that's a huge risk but if we really
>   want to try to cover it, i think there are ways that we could
>   minimize it as well.

Thanks, that summary looks quite accurate.

> That said, it sounds like negotiating the details of how to do this
> pinning is the main blocker, and i'm sick of this proposal being blocked
> (because i want it for "greenfield" implementations last year).

To be fair, the present delays date back to just March/April.  Until
that time the draft was blocking waiting for TLS 1.3 to be finished
first.  So it has only been a few months.

> So one way forward would be to complete this extension without the
> pinning (explicitly acknowledging that it will not be useful for
> non-greenfield implementations on its own) and get it out the door.
> Then we can subsequently create a new extension that is only a
> "how-to-pin-dnssec-chain-extension".

At this point, I think that would be a mistake. The draft still needs
much work.  Though pinning has been a blocker, it has many other smaller
defects that have to be addressed, now that it is back for revision.

The draft fails to specify correct semantics for SNI, and leaves out
the port number from the client extension, but it is needed.

The draft fails to explain the server's responsibility to decrement
RRset TTLs if the server is providing previous cached data.

The draft fails to describe how virtual hosting should be handled.
The RRset ordering is unnecessary, and complicates the exposition.

Bottom line, there isn't a document that can (or at least should)
land back in the IESG queue with minimal changes.  It needs a bunch
of changes, and so we should really also resolve the pinning issue,
it is NOT that difficult.  It has been a series of misperceptions
all along.

> Alternately, if people could agree on a simple and clear pinning scheme
> that we could get out the door all in one piece, i'd be happy with that
> too.

The proposed extension lifetime field is all it takes, there is no
feasibility or need for a testing mode (because there's no way to
authenticate such a mode, or else we again lose downgrade protection,
and the analogy with HTTP STS is imperfect, and does not carry over).

There's also no need for "reporting URIs", failure signaling is
much better done in-band, via a suitable TLS alert.

All that's left to iron out is the maximum duration for the pin
lifetime, and whether we need to gradually scale it up as a function
of RFC lifetime, giving sites more protection from hijack DoS (if
that's really considered important enough to complicate the design).

-- 
Viktor.

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

Re: [TLS] WGLC for draft-ietf-tls-sni-encryption

[Martin Thomson]

This is a pretty good piece of information that is very nearly done.

Regarding the idnits results, DoH is done, but DTLS and QUIC are still
a way off.  Would we prefer publication with downref or waiting?  For
me, this depends somewhat on the maturity of the documents that depend
on this.  I'd be willing to wait until those documents would have to
wait for this one.

3.6 mentions attack by the fronting server or the multiplexed server.
But the multiplexed server is the desired endpoint.  I think that you
can drop any reference to the multiplexed server here.  It might
require some reframing.

3.8.1 says that it "is thus desirable that SNI Encryption mechanisms
be also able hide the ALPN."  I think that we ultimately decided that
while the techniques might be usable, it would be preferable to
encrypt these independently.  (Noting that SNI encryption as specified
is rather bulky...)

3.9 suggests that parameters might be stripped from the ClientHello:

   When designing SNI encryption schemes, we have to take into account
   attacks that strip parameters from the Client Hello, or replay
   attacks.  In both cases, the desired behavior is to fall back to a
   connection with the fronting server, so there is no visble difference
   between a regular connection to that server and an attempt to reach
   the hidden server.

But any attack that modifies the ClientHello will cause the handshake
to fail when the client receives the Finished from the server (i.e.,
immediately). Not to mention the server certificate being for a name
the client doesn't expect.

The problem is that you can construct scenarios with controlled
release of a spoofed server flight to test whether a client is willing
to continue the connection.  Note that you can't do a controlled
release of a real flight from a server because any modification to the
ClientHello will result in different handshake keys.

(Note also the typo: visble)

I don't know what was really intended by this section, but it needs work.

4 fails to acknowledge other work in this area, like
draft-ietf-httpbis-http2-secondary-certs and the ORIGIN frame (RFC
8336).

Nits:

The document contains a mix of title- and sentence- case headings.

Terms are inconsistently capitalized throughout (like Fronting Server).

2.1 list construction requires "and" or "or"
   o  Enterprise firewalls blocking web sites not deemed appropriate for
  work, +and+

2.3 missing "of"
   Deploying SNI encryption will help thwarting most +of+ the "unanticipated"

3.8 subject object disagreement
   The SNI encryption requirement do+es+ not stop with HTTP over TLS.

3.9.  Fail to fronting <- not sure what this phrase means

3.9 also has inconsistent use of "client hello" vs. "Client Hello".  I
think that it's supposed to be "ClientHello".

4 just drop "/some-content" from the example, it doesn't help (and
it's badly wrapped)
4 mismatched quotes on 'co-tenant"

On Wed, Oct 17, 2018 at 10:04 AM Sean Turner  wrote:
>
> All,
>
> I ran I-D nits before hitting the appropriate buttons to place this draft in 
> WGLC.  I figured we could address the following before we send the draft to 
> Ben:
>
>   == Outdated reference: draft-ietf-tls-tls13 has been
>published as RFC 8446
>
>   == Outdated reference: A later version (-14) exists of
>draft-ietf-doh-dns-over-https-08
>
>   == Outdated reference: A later version (-15) exists of
>draft-ietf-quic-tls-11
>
>   == Outdated reference: A later version (-28) exists of
>draft-ietf-tls-dtls13-26
>
>   == Outdated reference: draft-mm-wg-effect-encrypt has
>been published as RFC 8404
>
> To answer the other 5 I-D nits questions "Obsolete informational reference 
> (is this intentional?)” - the answer is yes.
>
> spt
>
> > On Oct 16, 2018, at 18:43, Sean Turner  wrote:
> >
> > All,
> >
> > This is the working group last call for the "Issues and Requirements for 
> > SNI Encryption in TLS" draft available at 
> > http://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/.  Please 
> > review the document and send your comments to the list by 2359 UTC on 31 
> > October 2018.
> >
> > Thanks your chairs: C-J-S
>
> ___
> 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] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[John Levine]

Hi from DNS land.

>pinning, but i won't go too far into the weeds here.  Just a quick
>summary of my understanding:
>
> * The existence of a pin only requires that the service operator
>   maintain the ability to respond to this extension in the future -- it
>   doesn't require specific keys, or even the use of DANE itself.  It is
>   not nearly as large a risk as HPKP's pins were.
>
> * Pinning fears are based on two scenarios: (a) footgun, where the
>   service operator makes a mistake, or (b) a malicious pin is set by an
>   adversary who has owned your domain.  (a) is overwhelmingly more
>   common, and is what we should focus on.  In the (a) scenario, the
>   admin has already deployed the extension, so there is no risk.  The
>   (b) scenario only matters if a service cannot deploy the extension as
>   intended, which is more of a chicken/egg problem of deployment and
>   implementation.  I don't think that's a huge risk but if we really
>   want to try to cover it, i think there are ways that we could
>   minimize it as well.

Something like "require DANE certs until time N" should be plenty.

Remember that you can also unpin by publishing a signed NXDOMAIN or
NODATA.  Since you need to have DNSSEC working to get the pin in the
first place, that doesn't seem unduly onerous.

If your system goes totally kerflooie and your DNS was signed
yesterday and for some reason you can't sign it today, you have a
problem, but that doesn't sound like a very likely problem.  It it
does happen, it's as likely as not an attack in which case you'd want
attempts to unpin to fail.

R's,
John

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

Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[Benjamin Kaduk]

On Tue, Oct 16, 2018 at 06:16:22PM -0400, Daniel Kahn Gillmor wrote:
> 
> I agree with both Tom and Viktor that the current draft seems to be
> misaligned between the goals and the stated scope.

I also agree that there is some misalignment of this nature.

My attempt at a root cause analysis would be that the current text in
the Introduction is essentially saying "let clients in bad networks do
DANE", but "doing DANE" is a fairly nebulous thing, and if different
people are focusing on "doing DANE" in different ways, we can get into
conflict about whether a specific proposed mechanism advances our
particular goals.


So what is "doing DANE", then?  In the course of the on-list, off-list,
side meeting and interim discussions, I've benefited greatly from
hearing from a lot of experts, and I deeply appreciate the patience and
persistence that the participants thereof have shown in working to
advance a document in this space.  It was not always easy, but I think
we are making progress.

In the context of this discussion, I propose that DANE is a way to allow
a TLS server operator[1] to indicate to a TLS client information about
how the server would like to be authenticated.  The practical effect of
this new source of information depends on what the client would be doing
*without* the DANE information, though, since we have this large
deployed base that is currently not doing DANE but could do DANE in the
future.  If we want to analyze the (security and other) properties of
adding DANE, we must consider both the starting point and the end state.

I suggest that if we limit the stated scope from an open-ended "doing
DANE" to also state which cases of "doing DANE" we have analyzed
(leaving open the possibility for future analysis to confirm the
mechanisms we define as usable in other cases), then we can get a clear
answer on whether the proposed mechanism meets the requirements of each
listed case, without introducing negative externalities for either the
protocol participants or the Internet as a whole.  This is not to
exclude the "greenfield" case, of course -- a list of cases to consider
might include things like:

- client does not currently exist, and insists on receiving DANE records
  via TLS extension; server wants to use TLSA with PKIX-{TA,EE}

- client does not currently exist, and insists on receiving DANE records
  via TLS extension; server wants to use TLSA with DANE-{TA,EE}

- client currently accepts "Web PKI" certificates but is willing to do
  DANE; server wants to use TLSA with PKIX-{TA,EE}

- client currently accepts "Web PKI" certificates but is willing to do
  DANE; server wants to use TLSA with DANE-{TA,EE}

- client currently will opportunistically accept any certificate but is
  willing to apply DANE restrictions; server wants to use TLSA with
  DANE-{TA,EE}

- client currently will opportunistically accept any certificate but is
  willing to apply DANE restrictions; server wants to use TLSA with
  PKIX-{TA,EE}

where I separate out the DANE- and PKIX- usage values since they may
require a separate security analysis.  (If they don't; great, we can
consolidate them in the document.)

I don't think we would necessarily need to come to consensus on which of
these cases are "most important", so long as we can provide a mechanism
that will satisfy the requirements of all cases that we want to list in
the document.

> I wanted the draft to be done by now because i think it will be useful
> in "greenfield" scenarios -- ones where the use case itself can mandate
> the extension without negotiation, but i understand Viktor's point that
> without any sort of negotiated pinning mechanism, the draft is probably
> not useful for non-greenfield scenarios (without pinning the existence
> of the extension, it cannot reduce the attack surface represented by the
> CAs, and instead only represents an additional vector of attack).

Right -- if the client is currently willing to do Web PKI (or worse), an
attacker that can get a bogus Web PKI (or self-signed) certificate could
keep the client ignorant of the true server's preference and get the
client to errenously complete a handshake.  We would like a way to
deprive the attacker of such a capability, though in at least some
situations we cannot do so with 100% reliability.  We could perhaps have
a success criteria for this TLS extension (as a security mechanism),
that it both:

(1) provides a channel for DANE records that is reliable in the absence of
an attack

and

(2) reduces the ability of an attacker to cause the client to ignore the
server's authentication preference

I think that just meeting the above two conditions could provide enough
value to merit publishing, even without attempting to add something
like:

(3) allows the client to realistically hard-fail connections where DNSSEC
validation returns bogus or indeterminate.

Getting (1) is probably trivial (though with middleboxes you never
know), and it seems fairly clear that a pinning 

Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[Viktor Dukhovni]

> On Oct 16, 2018, at 9:07 PM, John Levine  wrote:
> 
> Something like "require DANE certs until time N" should be plenty.
> 
> Remember that you can also unpin by publishing a signed NXDOMAIN or
> NODATA.  Since you need to have DNSSEC working to get the pin in the
> first place, that doesn't seem unduly onerous.

To be clear the "require DANE certs" above only holds so long as the
TLSA records remain published.  Since providing proof of non-existence
clears the pin, what's really pinned is the extension (and even then,
many clients will be able to recover by making independent DNS lookups).

So there's no discord here between "require DANE certs" and "just
pin the extension", the two are equivalent, because the former
really means "require the extension and if signed TLSA records are
present require DANE, else, with valid denial of existence, clear
the pin".

So regardless of how we frame it, the behaviour after first contact is
the same, that is:

  * Apply DANE in a downgrade-resistant manner when published
  * Drop pins and revert to default behaviour given valid denial of
existence.

So far, no substantive issues have been noted with the proposed pinning
approach to downgrade resistance (which bears no resemblance to HPKP).

All that remains is agreement on a maximum time limit (by setting the time
unit to max_time/2^16), and perhaps some sort of gradual scaling up of
that limit (if concerns about hijacking before the extension is widely
available in server software are deemed sufficiently compelling).

-- 
Viktor.

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

Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[Paul Wouters]

On Tue, 16 Oct 2018, Daniel Kahn Gillmor wrote:


That said, it sounds like negotiating the details of how to do this
pinning is the main blocker, and i'm sick of this proposal being blocked
(because i want it for "greenfield" implementations last year).


Imagine how sick I will be when I try to do this later in a separate
docment, where the WG might not even accept it as a WG item. I am not
confident enough that pinning would be resolved in a later document at
all, leaving me with my use case dead in the water forever.

So for me it is useful to have the pressure of release for those people
who have a greenfield application to want this to happen to push for
resolving the downgrade attack. It forces the parties to the table to
resolve the conflict. But also, we already had a suggestion on how
to postpone the pinning solution to another document, but to do that
sanely this document needed some placeholder or else you end up with
a pinning extension that pins itself _and_ another extension, or a
placeholder for the meaning of a pin, and both situations were deemed
worse then just working out everything in one document. So in effect
we already tried what you are proposing.

Finally, as Viktor said, our discussions offlist an onlist, found
other issues. While Viktor and I are happy to write text to fix these
other issues in the document, it seems we are currently stuck in a
role of spending a lot of effort writing text, only to see no new
draft version on even the things everyone agrees on, such as denial
of existence. Since Viktor and I put in a lot of effort to write text
that isn't being accepted or rejected, we don't feel very motivated
to fix all these other things we found.

In my opinion, this document needs more active authors proposing and
writing text. It seems none of the original authors is willing or
able to do this anymore. If nothing has changed at the next IETF, I
have planned to propose adding one or two new authors to the document
to try and get it unstuck.

I also want to note that Ben has done a very admirable job of talking
to everyone and moving towards consensus.

Paul

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

Re: [TLS] Interim notes and draft-ietf-tls-dnssec-chain-extension next steps

[Viktor Dukhovni]

On Wed, Oct 17, 2018 at 01:46:20AM -0400, Paul Wouters wrote:

> On Tue, 16 Oct 2018, Daniel Kahn Gillmor wrote:
> 
> > That said, it sounds like negotiating the details of how to do this
> > pinning is the main blocker, and i'm sick of this proposal being blocked
> > (because i want it for "greenfield" implementations last year).
> 
> Imagine how sick I will be when I try to do this later in a separate
> docment, where the WG might not even accept it as a WG item. I am not
> confident enough that pinning would be resolved in a later document at
> all, leaving me with my use case dead in the water forever.

Agreed, but at the same time in DKG's response, beyond the frustration
with the process, I see real signs of potential progress in the
form of broad agreement with the points we'ev made about the need
for and the nature of the proposed pinning approach.

So frankly, barring strong evidence to the contrary, I think we're
finally seeing an emerging consensus in support of the proposed
approach, be it so long as the deadlock is ultimately resolved.

Well, if rough consensus emerges for a non-deadlocked pinning design,
with no substantive unaddressed objections, then the deadlock goes
away, and we get to move forward to writing the consensus text,
with a bit of the usual bikeshedding, and will soon be done.

-- 
Viktor.

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