Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Viktor Dukhovni]

> On Apr 1, 2018, at 10:37 AM, Salz, Rich  wrote:
> 
>>   Possibly, if you consider being able to say "Invalid length encoding in
>preferred-ECC-curves extension" in Tswana is mission-critical to debugging 
> a
>TLS handshake failure.
> 
> I so love your messages, Peter.  Honestly I do.
> 
> Perhaps not Tswana, but perhaps China may care to pick a counter-example.

For debugging messages, I'm with Peter, they'll only be implemented if they're
simple enough to support.  I can't see having to have localization files on the
server for debug messages that might be requested by a client is some other 
locale
and only when debug is enabled, and the consumer is a developer and not an 
end-user.

-- 
Viktor.

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

Re: [TLS] Genart last call review of draft-ietf-tls-tls13-24

[Dale R. Worley]

Bill Frantz  writes:
> We have always avoided the long form error messages in TLS 
> because they can be of great help to attackers as well as 
> debuggers. I think this objection is much weaker if we write the 
> long form error messages into a log that is kept with other 
> server logs.

I'd not considered textual messages.  What struck me is that the draft
has dozens, maybe more than 100, conditions that must be satisfied, and
only a few different error codes.  It strikes me that each particular
rule could be assigned an error number, so an implementation could point
out which of the dozens of rules was violated in a particular handshake.

Dale

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

Re: [TLS] Expanded alert codes. [Was Re: Genart last call review of draft-ietf-tls-tls13-24]

[Dale R. Worley]

Eric Rescorla  writes:
> I guess there might be some intermediate category 1.5 that's kind of in
> production so you don't want to print out complete logs, but you'd like
> more detail than you would probably want to expose in general, but my
> experience is that that's not super-common.

My expectation is that the useful case is when there *aren't* any logs,
or what logging is done does not tell the specific reasons that
particular interactions were rejected.  That's pretty common in SIP
systems.

Of course, anything like this would be an extension.  But would it be
reasonable for one endpoint to present a "debug password" in its request
which, if it matched the debug password set in the other endpoint, would
cause the other endpoint to provide fuller error information?  That
would allow a "debug window" that could be exploited only between
endpoints that had some sort of administrative coordination.

Dale

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

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

[Viktor Dukhovni]

> On Apr 5, 2018, at 10:54 AM, Nico Williams  wrote:
> 
> We could mitigate the DoS by saying that the pin TTL must be coerced to
> zero (or maybe 1) if the extension only bore an authenticated denial of
> existence.  I would prefer to not have to do this, but I'd accept it.

When we get past this consensus call, and get to craft the actual text
describing the pin TTL, I would expect a non-zero PIN to only be possible
when proving TLSA records.  A denial of existence should not be able to
set a new pin TTL, and should clear any previous pin TTL.  If DANE is not
actually deployed, there's little reason to pin the extension, and clearing
the pin via denial of existence is a useful mechanism.

A client might then lose access to continued denial of existence until
it again sees actual TLSA records with a non-zero pin, but that seems
OK to me.

-- 
Viktor.

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

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

[Nico Williams]

On Wed, Apr 04, 2018 at 08:39:37PM -0700, Eric Rescorla wrote:
> On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams  wrote:
> > Either way it's the same impact: you cannot roll that key over.
> >
> > Whereas with pin-to-DANE there's no such problem.  I thought I made that
> > clear.
> 
> Yes, I agree that you're relying on a different guarantee from your
> parent zone, I just don't think it's particularly obvious that that
> guarantee is easier to ensure, for the reasons I indicated previously.

Sure it is.  As long as the root zone is signed you can use this
extension and prove that you are / are not using DANE.

> > > And, of course, if you're concerned with hijacking attacks, the
> > > > > hijacker will just advertise a very long TTL.
> > > >
> > > > But it's a TOFU-ish thing.  The server impersonator has to have the
> > > > right timing or else be detected -- that's very risky for them, and a
> > > > deterrent to even trying.  It's not fool-proof, but it's not nothing
> > > > either.
> > >
> > > Given that the motivation for this kind of hijacking was generally
> > > expected to be vandalism or ransom, this doesn't seem very comforting.
> >
> > The motivation for opportunistically using this is to be able to
> > incrementally deploy DANE for HTTPS (and browsers).  Without that it
> > won't get deployed at all for HTTPS.
> 
> I don't see how this is responsive to the concern that this technique will
> be used for hijacking.

You're right.  I believe this has been answered now separately by
others, and also by me.

This is not a pin-to-DANE feature we're asking for, but a
pin-to-using-this-extension.  I shouldn't have called it pin-to-DANE,
but I did because it's short -- short, but not sufficiently pithy :(

Now, it's true that an impersonator could force you to use this
extension when you were not ready to, and that's a DoS, though an easy
one to fix, relatively.  I'll take that DoS over a downgrade attack.

We could mitigate the DoS by saying that the pin TTL must be coerced to
zero (or maybe 1) if the extension only bore an authenticated denial of
existence.  I would prefer to not have to do this, but I'd accept it.

Nico
-- 

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

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

[Nico Williams]

On Thu, Apr 05, 2018 at 06:33:10AM -0700, Eric Rescorla wrote:
> On Thu, Apr 5, 2018 at 2:02 AM, Paul Wouters  wrote:
> > On Wed, 4 Apr 2018, Eric Rescorla wrote:
> >> HPKP had a TTL and yet as a practical matter, people found it very
> >> problematic.
> >> And, of course, if you're concerned with hijacking attacks, the
> >> hijacker will just advertise a very long TTL.
> >
> > By publising DANE records with either a TLSA record or a denial of
> > existence proof, you can override any longterm TTL.
> >
> > If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension
> > containing a valid NSEC proof of non-existence overrides the
> > previous TTL/PIN.'
> 
> Thanks. This is a good point that I agree does not apply to HPKP.
> 
> However, that doesn't mean that hijacking isn't a problem (though I
> agree a less serious one). If I have no provisions for DNSSEC at all
> and the attacker does pin hijacking I could be offline for hours to
> days while I figure out how to get and serve them.

I've been calling this pin-to-DANE because it's short, but, really, it's
pin-to-using-this-extension.

You can use this extension even if your domain is not signed because the
proof that it isn't signed would be delivered in this extension.

I believe the only way pinning to this extension can cause the hijacking
you propose is if the root zone stops being signed as then there would
be no way to prove that you're no longer using DANE :)

Nico
-- 

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

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

[Viktor Dukhovni]

> On Apr 5, 2018, at 10:20 AM, Eric Rescorla  wrote:
> 
> 
> Yes, so quite possibly I need to upgrade my entire server farm, which might 
> be running
> on some software which has no version which implements this extension. This 
> could
> be an enormous effort.

Yes, module hijack.  The same applied with STS, if the server farm had no TLS 
support,
or insufficient capacity to handle the load with TLS.  This is not substantially
different, other than that TLS support is fairly mainstream now.

Note that the hijack would also need obtain WebPKI certificates (as I would 
expect
DANE for browsers to insist on the restrictive PKIX-TA(0) / PKIX-EE(1)).  So the
that would be a full takeover of the domain, and the affected clients would have
to have visited the hijacked site during the time it was controlled by the 
malicious
party.

Note also that clients that support the extension will also be rare for some 
time,
so the impact of any hijack that improbably pins the extension will be modest.

So, if some users running early adopter browsers that support the extension have
to manually clear the pin after a domain hijack, and visiting the hijacked site,
potentially disclosing sensitive information to the wrong party, etc. then 
becoming
aware of that when the browser warns them about missing extension support seems 
like
a feature and not a bug.  They can and probably should contact the legitimate 
site's
help desk and figure out what to do to secure their account, change passwords, 
...

This scenario is not impossible, but a rather low risk, and would initially, as
server support ramps up, affect few users.  The pin can be cleared by the user
in such a situation, and having the user be aware of the fact that he/she 
visited
a hijacked site is not a bad thing.

-- 
Viktor.

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

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

[Eric Rescorla]

On Thu, Apr 5, 2018 at 7:08 AM, Viktor Dukhovni 
wrote:

>
>
> > On Apr 5, 2018, at 9:33 AM, Eric Rescorla  wrote:
> >
> > However, that doesn't mean that hijacking isn't a problem (though I
> agree a less
> > serious one). If I have no provisions for DNSSEC at all and the attacker
> does
> > pin hijacking I could be offline for hours to days while I figure out
> how to get
> > and serve them.
>
> Perhaps you did not see my explanation of why the pin imposes no
> obligation beyond
> supporting the extension in the server software.  A server for an unsigned
> domain
> can just serve denial of existence of the domain's (or a parent's) DS
> record.
>

Yes, so quite possibly I need to upgrade my entire server farm, which might
be running
on some software which has no version which implements this extension. This
could
be an enormous effort.

-Ekr


-

>
> So you don't need to "get and serve them", you just need to forward
> whatever is
> the true data in DNS about the server's domain.  Only the capability to
> present
> the actual DNS chain is required.
>
> * If server's zone is not DNSSEC-signed, forward NSEC records
> showing
>   existence of NS and non-existence of DS at or above the
> requested:
>
>  _443._tcp.server-fqdn.example
>
>   domain and the requisite signatures up to the root.
>
> * If server's zone is DNSSEC-signed, but no TLSA records are
> present, serve
>   NSEC records proving non-existence (or NODATA) of the requested
>
> _443._tcp.server-fqdn.example IN TLSA ?
>
>   records and the requisite signatures up to the root.
>
> * If the server's zone is DNSSEC-signed, and TLSA records are
> present, serve
>   the requested TLSA records along with the requisite signatures
> up to the root.
>
> All three of these would be obtained and cached (up to most of the
> advertised TTL) in
> the same way from a suitable resolver that supports chain queries, it is
> up to that
> resolver to return the appropriate response each of the above cases, the
> server can
> treat the data as opaque, modulo determining the time for which it may
> cache the
> response so that the chain need not be re-fetched for each client
> connection.
>
> If one is worried about hijack by someone who can cause the domain to be
> signed
> with TLSA records published (so as to set a non-zero pin), then one might
> be
> motivated to have server software that is capable of returning the
> extension.
> Just as with STS one might need software that supports TLS if the hijacker
> deployed STS.  I don't think that such hijacking is a major risk, but if
> that
> risks drives adoption of the extension (without any other changes in tbe
> domain's practices wrt. DNSSEC or DANE adoption) all the better. :-)
> The domain might need the extension some day for more than just hijack
> recovery,
> and it will already be available.
>
> --
> Viktor.
>
> ___
> 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

[Viktor Dukhovni]

> On Apr 5, 2018, at 9:33 AM, Eric Rescorla  wrote:
> 
> However, that doesn't mean that hijacking isn't a problem (though I agree a 
> less
> serious one). If I have no provisions for DNSSEC at all and the attacker does
> pin hijacking I could be offline for hours to days while I figure out how to 
> get
> and serve them.

Perhaps you did not see my explanation of why the pin imposes no obligation 
beyond
supporting the extension in the server software.  A server for an unsigned 
domain
can just serve denial of existence of the domain's (or a parent's) DS record.

So you don't need to "get and serve them", you just need to forward whatever is
the true data in DNS about the server's domain.  Only the capability to present
the actual DNS chain is required.

* If server's zone is not DNSSEC-signed, forward NSEC records showing
  existence of NS and non-existence of DS at or above the requested:

 _443._tcp.server-fqdn.example

  domain and the requisite signatures up to the root.

* If server's zone is DNSSEC-signed, but no TLSA records are present, 
serve
  NSEC records proving non-existence (or NODATA) of the requested

_443._tcp.server-fqdn.example IN TLSA ?

  records and the requisite signatures up to the root.

* If the server's zone is DNSSEC-signed, and TLSA records are present, 
serve
  the requested TLSA records along with the requisite signatures up to 
the root.

All three of these would be obtained and cached (up to most of the advertised 
TTL) in
the same way from a suitable resolver that supports chain queries, it is up to 
that
resolver to return the appropriate response each of the above cases, the server 
can
treat the data as opaque, modulo determining the time for which it may cache the
response so that the chain need not be re-fetched for each client connection.

If one is worried about hijack by someone who can cause the domain to be signed
with TLSA records published (so as to set a non-zero pin), then one might be
motivated to have server software that is capable of returning the extension.
Just as with STS one might need software that supports TLS if the hijacker
deployed STS.  I don't think that such hijacking is a major risk, but if that
risks drives adoption of the extension (without any other changes in tbe
domain's practices wrt. DNSSEC or DANE adoption) all the better. :-)
The domain might need the extension some day for more than just hijack recovery,
and it will already be available.

-- 
Viktor.

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

Re: [TLS] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT)

[Martin Vigoureux]

Martin,

thanks for the quick reply. That clarifies.
I asked because the paragraph above that sentence somehow already 
implies that clients may continue advertise the "max_fragment_length" 
(at least that's ow I understand it), so I felt that this sentence must 
mean something different.


-m

Le 2018-04-05 à 12:28, Martin Thomson a écrit :

On Thu, Apr 5, 2018 at 7:31 PM, Martin Vigoureux
 wrote:

Hello, I'm not a TLS expert so please disregard if this is irrelevant.
Document says:
Clients that depend on having a small record size MAY continue to
advertise the "max_fragment_length".

Do you mean:
Clients that depend on having a small record size MAY continue to
advertise the "max_fragment_length" *only*.


It's "also".  The idea being that if you aren't sure if the server
supports the new thing, you might offer the old thing in addition to
the new thing in the hopes that if the new thing isn't supported, the
old thing might be.


If so, what would be the behaviour of a server that supports both
"max_fragment_length" and "record_size_limit" in that situation?


If you don't include record_size_limit, you can't use it.  If the
client includes both, then the text from the preceding paragraph
applies: "A server that supports the record_size_limit extension MUST
ignore a max_fragment_length that appears in a ClientHello if both
extensions appear."



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

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

[Eric Rescorla]

On Thu, Apr 5, 2018 at 2:06 AM, Paul Wouters  wrote:

> On Wed, 4 Apr 2018, Eric Rescorla wrote:
>
> 1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's
>> a pain). This rationale was stronger back before Let's Encrypt, but
>> I suppose some people may still feel that way.
>>
>> 2. Restrictive: To protect yourself from compromise of the WebPKI.
>>
>> Yes, if your motivation is #2, then the flow you suggest is a real
>> problem,
>> but it's not a problem for #1. While not an author of this document, I'd
>> understood it's primary motivation to be #1, and that's what Richard's
>> earlier notes have said as well.
>>
>
> The primary use case of the author's is not relevant. The document is a
> working group document, and people who have contributed to this document
> from the start also have valid use cases.
>

Of course. I'm merely responding here to the claim that the document is
useless
as-is.

-Ekr


> For example, I proposed to use the DNS wire format early on and the WG
> made that change. My use case was never to create a "DANE or WebPKI is
> enough" security model, as I do not think that model helps anyone.
>
> Paul
>
>
> ___
> 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

[Eric Rescorla]

On Thu, Apr 5, 2018 at 2:02 AM, Paul Wouters  wrote:

> On Wed, 4 Apr 2018, Eric Rescorla wrote:
>
> HPKP had a TTL and yet as a practical matter, people found it very
>> problematic.
>> And, of course, if you're concerned with hijacking attacks, the hijacker
>> will
>> just advertise a very long TTL.
>>
>
> By publising DANE records with either a TLSA record or a denial of
> existence proof, you can override any longterm TTL.
>
> If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension
> containing a valid NSEC proof of non-existence overrides the previous
> TTL/PIN.'


Thanks. This is a good point that I agree does not apply to HPKP.

However, that doesn't mean that hijacking isn't a problem (though I agree a
less
serious one). If I have no provisions for DNSSEC at all and the attacker
does
pin hijacking I could be offline for hours to days while I figure out how
to get
and serve them.

-Ekr




> In fact, this is one of the reasons the WG should decide to fix the
> current draft to include proofs of denial of existence.
>
> Paul
>
>
> ___
> 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] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT)

[Martin Thomson]

On Thu, Apr 5, 2018 at 7:31 PM, Martin Vigoureux
 wrote:
> Hello, I'm not a TLS expert so please disregard if this is irrelevant.
> Document says:
>Clients that depend on having a small record size MAY continue to
>advertise the "max_fragment_length".
>
> Do you mean:
>Clients that depend on having a small record size MAY continue to
>advertise the "max_fragment_length" *only*.

It's "also".  The idea being that if you aren't sure if the server
supports the new thing, you might offer the old thing in addition to
the new thing in the hopes that if the new thing isn't supported, the
old thing might be.

> If so, what would be the behaviour of a server that supports both
> "max_fragment_length" and "record_size_limit" in that situation?

If you don't include record_size_limit, you can't use it.  If the
client includes both, then the text from the preceding paragraph
applies: "A server that supports the record_size_limit extension MUST
ignore a max_fragment_length that appears in a ClientHello if both
extensions appear."

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

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

[Ilari Liusvaara]

On Thu, Apr 05, 2018 at 02:46:12AM -0400, Viktor Dukhovni wrote:
> 
> 
> > On Apr 4, 2018, at 1:50 PM, Joseph Salowey  wrote:
> > 
> > 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
> 
> Therefore, the real choice before us is (C) or not (C), the choices of (A) 
> alone or (B)
> alone are unsound half-measures.

I agree that both (A) and (B) are bad idea, while (C) is sound idea.
 
> (C) is essentially STS for dane chains over TLS with downgrade protection 
> after first
> contact, and imposes no burden on the present implementors.  If they were 
> willing to
> implement without a pin or denial of existence, they can ignore the pin TTL 
> and never
> transmit denial of existence (which their clients would not expect to 
> process).

If one wants to save bandwidth in "cancel pin" case, one could add
a flag into request that tells the server if it should transmit DoE
or not (if it has actual chain, that should be transmitted anyway).

That way, the cancel would only need to be transmitted once to each
client, instead of potentially multiple times, and clients that do
not support pinning would not waste downstream bandwidth downloading
cancels they would ignore anyway.


-Ilari

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

[TLS] Martin Vigoureux's No Objection on draft-ietf-tls-record-limit-02: (with COMMENT)

[Martin Vigoureux]

Martin Vigoureux has entered the following ballot position for
draft-ietf-tls-record-limit-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-record-limit/



--
COMMENT:
--

Hello, I'm not a TLS expert so please disregard if this is irrelevant.
Document says:
   Clients that depend on having a small record size MAY continue to
   advertise the "max_fragment_length".

Do you mean:
   Clients that depend on having a small record size MAY continue to
   advertise the "max_fragment_length" *only*.

If so, what would be the behaviour of a server that supports both
"max_fragment_length" and "record_size_limit" in that situation?


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

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

[Paul Wouters]

On Wed, 4 Apr 2018, Eric Rescorla wrote:


  The motivation for opportunistically using this is to be able to
  incrementally deploy DANE for HTTPS (and browsers).  Without that it
  won't get deployed at all for HTTPS.

I don't see how this is responsive to the concern that this technique will
be used for hijacking.


To hijack a DANE TLSA record, an attacker has to take over the DNS
domain. Controlling the DNS is equally fatal for the webpki, as you
can just ACME a new certificate at that point. So the hijacking case
is not made worse at all. But the compromise/coercion of only 1 of
600+ (sub)CA's is actually protected against, making DANE a stronger
authentication alternative.

Additionally, in the case of forced domain transfer in relation to an
ownership dispute being litigated, the DANE based pinning is actually
superior to any other kind of pinning, because it gives the (new) domain
owner full control to cancel any outstanding long term pins distributed
by the old/previous/malicious owner.

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

[Paul Wouters]

On Thu, 5 Apr 2018, Richard Barnes wrote:


And just to be clear, by "downgrade attack", you mean "normal PKI authentication 
that we rely on today".  There's nothing in here that degrades security


You mean other then LetsEncrypt destroying the ecosystem and leading to
a "one key to rule them all" situation?

The webpki is changing dramatically. The amount of CAB/forum violations
seems to be increasing, partially as a result of these violations getting
exposed by certificate transparancy and perhaps partially because of
the financial strain caused by the free LetsEncrypt. Allowing people to
deploy another PKI is not harmful - forcing people to stick with the
webpki could prove harmful.


That doesn't mean there's not still some utility to be had. 


Your tls-extension use case can be supported regardless of the outcome
of this consensus call. That is not at stake today. Other people's valid
use cases are the ones that are at stake now.

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

[Paul Wouters]

On Wed, 4 Apr 2018, Eric Rescorla wrote:


1. Assertive: To avoid having to engage with the WebPKI (e.g., because it's
a pain). This rationale was stronger back before Let's Encrypt, but
I suppose some people may still feel that way.

2. Restrictive: To protect yourself from compromise of the WebPKI.

Yes, if your motivation is #2, then the flow you suggest is a real problem,
but it's not a problem for #1. While not an author of this document, I'd
understood it's primary motivation to be #1, and that's what Richard's
earlier notes have said as well.


The primary use case of the author's is not relevant. The document is a
working group document, and people who have contributed to this document
from the start also have valid use cases.

For example, I proposed to use the DNS wire format early on and the WG
made that change. My use case was never to create a "DANE or WebPKI is
enough" security model, as I do not think that model helps anyone.

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

[Paul Wouters]

On Wed, 4 Apr 2018, Eric Rescorla wrote:


HPKP had a TTL and yet as a practical matter, people found it very problematic.
And, of course, if you're concerned with hijacking attacks, the hijacker will
just advertise a very long TTL.


By publising DANE records with either a TLSA record or a denial of
existence proof, you can override any longterm TTL.

If an attacker puts in a 1 year PIN/TTL, any TLS-dnssec extension
containing a valid NSEC proof of non-existence overrides the previous
TTL/PIN.

In fact, this is one of the reasons the WG should decide to fix the
current draft to include proofs of denial of existence.

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

[Viktor Dukhovni]

> On Apr 4, 2018, at 1:50 PM, Joseph Salowey  wrote:
> 
> 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

The discussion so far has demonstrated the need for an important clarification 
about the nature of the pinning in B):

  * The pin would not require *anything* more than continuing support for the 
extension.
  * In particular, it would not require continued presence of TLSA records, nor 
even
continued DNSSEC support by the server's domain.
  * This is because the server can respond with denial of existence of either 
its TLSA
records, or even of the the DS records for its domain or some parent domain.

This is why my claim that this is essentially like STS, and nothing like HPKP 
is valid.

A corollary of the above is that (B) requires (A).  Just (B) alone is not 
sufficient,
it is too limited a mechanism without denial of existence.

If support for the extension itself is mandatory in some application context 
(implicit
unbounded pin), then of course (A) alone is enough, but we should note that 
such implicit
indefinite pinning is fragile during partial deployment and does not protect 
applications
where the implicit requirement is not an option (incremental deployment).

Therefore, the real choice before us is (C) or not (C), the choices of (A) 
alone or (B)
alone are unsound half-measures.

(C) is essentially STS for dane chains over TLS with downgrade protection after 
first
contact, and imposes no burden on the present implementors.  If they were 
willing to
implement without a pin or denial of existence, they can ignore the pin TTL and 
never
transmit denial of existence (which their clients would not expect to process).

On the other hand, they may find after some experience that the proposed 
features
are actually useful, and might add them to their application logic.  I don't 
know
whether DANE is mandatory with DPRIV or is just an "additive" alternative to 
WebPKI.
If the latter, with the present draft it is trivially stripped, and again there 
is
little incentive to not just use WebPKI, especially if DANE support is not 
required
from all clients (thus servers need at least WebPKI).

Looking at RFC8310, I see hints of support for both WebPKI and DANE, with no 
guidance
as to how a client is to choose between them, accept either both, avoid 
downgrades
to one when the other is preferred, ...

So I rather suspect that even the DPRIV use-case, which supposedly does not need
the proposed changes, actually does need them for meaningful security from using
DANE, and we've not just not looked at the details closely enough yet.  It may
well turn out not substantially different from the browser use-case that is not
adequately met by the current draft.

Can someone explain briefly how DPRIV avoids the same downgrade issues, and
negative adoption incentives (cost-benfit comparison)?  If it turns out that
no adequate explanation is possible, and indeed the same issues are present,
then the proposed changes (which are still needed elsewhere) are all the
more pressing.

-- 
Viktor.

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