On Wed, 7 Nov 2018, Tim Wicinski wrote:
My question would be "what will the HTTP community do if they find this whole
process unwieldy and long"? Answer They will come up with a
solution that does nothing with DANE.
They dont need to do anything to not have DANE. They already not have it.
On Tue, 6 Nov 2018, Benjamin Kaduk wrote:
I think I'm confused about what you mean by "the downgrade-resistance
that DNSSEC gives automatically".
You cannot filter DNSSEC without the target being aware of being
filtered (where filtering == downgrading)
Paul
__
We've had a couple of conference calls to discuss the I-D.
One call ended up causing the consensus on the I-D to collapse.
The second call ended too soon, but it was not unproductive. Indeed, I
think at that call and in the subsequent off-list threads we identified
the concerns with pinning:
-
On Tue, Nov 06, 2018 at 10:05:14AM -0600, Benjamin Kaduk wrote:
> Of course! But if we don't precisely specify those semantics, we expect
> to get DISCUSS positions at IESG evaluation (as "not interoperably
> implementable").
Yes, that's why the draft once updated will need to explain the
semant
My question would be "what will the HTTP community do if they find this
whole process unwieldy and long"?
Answer They will come up with a solution that does nothing with DANE.
is that an excuse to do something less than perfect for the better good, or
do we live in the world of smug satisfaction
On Mon, Nov 05, 2018 at 09:00:29AM -0500, Viktor Dukhovni wrote:
> > On Nov 5, 2018, at 8:01 AM, Benjamin Kaduk wrote:
> >
> > Once we start talking about pinning of any sort, we move from this
> > extension just being "transport some DNS records" into conveying some
> > sort of additional semant
On Tue, Nov 06, 2018 at 12:01:52AM -0500, Paul Wouters wrote:
> On Mon, 5 Nov 2018, Benjamin Kaduk wrote:
>
> >>The draft tries to enable a trust model based on DNSSEC, but due to
> >>missing pinning, fails to deliver that.
> >>
> >>A better way is saying the draft enables a trust model that restr
> On Nov 5, 2018, at 10:27 PM, Benjamin Kaduk wrote:
>
> This seems to suggest that we may need more precise text in the
> document about what it is (and is not) trying to do. The slides Sean
> posted for the Wednesday session note that fairly early in the timeline
> we thought:
>
>Primaril
On Mon, 5 Nov 2018, Benjamin Kaduk wrote:
The draft tries to enable a trust model based on DNSSEC, but due to
missing pinning, fails to deliver that.
A better way is saying the draft enables a trust model that restricts
the webpki, addressing the problems of too many unrestricted root CA
player
On Mon, Nov 05, 2018 at 09:54:19PM -0500, Paul Wouters wrote:
> On Mon, 5 Nov 2018, Salz, Rich wrote:
>
> >Is it fair to describe the draft as enabling a trust model based on DNSSEC,
> >rather than the default X.509 hierarchy and trust store which is implemented
> >by default?
>
> The draft tri
On Mon, 5 Nov 2018, Salz, Rich wrote:
Is it fair to describe the draft as enabling a trust model based on DNSSEC,
rather than the default X.509 hierarchy and trust store which is implemented by
default?
The draft tries to enable a trust model based on DNSSEC, but due to
missing pinning, fail
> On Nov 5, 2018, at 1:22 PM, Salz, Rich wrote:
>
> I need to review things some more, but FYI I believe I will say that mixing
> trust models is a bad idea, and opportunistic fallback seems both premature
> optimization and adding in the risk. I would support bringing back -07
> semantics.
On Mon, Nov 05, 2018 at 07:01:57AM -0600, Benjamin Kaduk wrote:
> Once we start talking about pinning of any sort, we move from this
> extension just being "transport some DNS records" into conveying some
> sort of additional semantics.
The I-D lost consensus over one issue. We should resolve tha
[ I hope the below is short enough...]
> On Nov 5, 2018, at 9:37 AM, Salz, Rich wrote:
>
> Is it fair to describe the draft as enabling a trust model based on DNSSEC,
> rather than the default X.509 hierarchy and trust store which is implemented
> by default?
>
> Please try very hard to keep
On Mon, Nov 05, 2018 at 02:37:26PM +, Salz, Rich wrote:
> Is it fair to describe the draft as enabling a trust model based on DNSSEC,
> rather than the default X.509 hierarchy and trust store which is implemented
> by default?
>
> Please try very hard to keep the answer brief.
In my mind th
Is it fair to describe the draft as enabling a trust model based on DNSSEC,
rather than the default X.509 hierarchy and trust store which is implemented by
default?
Please try very hard to keep the answer brief.
___
TLS mailing list
TLS@ietf.org
htt
> On Nov 5, 2018, at 8:01 AM, Benjamin Kaduk wrote:
>
> Once we start talking about pinning of any sort, we move from this
> extension just being "transport some DNS records" into conveying some
> sort of additional semantics.
Transporting some bits *always* carries additional semantics, otherwi
Hi all,
I do not know whether Wednesday's discussions will end up in a place where
these thoughts will be useful, but in the spirit of having discussions on
the list, I decided to write up some thoughts I've been pondering for a
while. Hopefully the written form will be more clear than if I had t
18 matches
Mail list logo
