When your revisions are ready please post them to the list in OLD and NEW
format so the working group can evaluate them.
Thanks,
Joe
On Wed, Apr 18, 2018 at 1:20 PM, Melinda Shore wrote:
> On 4/18/18 10:22 AM, Joseph Salowey wrote:
> > Concerns have been raised about the trade-offs associated
> On Apr 20, 2018, at 12:09 AM, Joseph Salowey wrote:
>
> [Joe] This can also be done with a new extension code point that defines a
> replacement extension that adds the pinning policy. This seems like viable
> possibility, we are not running short on extension code points.
This looks li
On Wed, Apr 18, 2018 at 1:42 PM, Paul Wouters wrote:
>
>
> 4. Re-submit the document for publication and start work on a separate
>> extension that supports pinning
>>
>
> While we agree we can move pinning to a separate document, it makes much
> less sense for this to become an additional ful
On Wed, Apr 18, 2018 at 11:34:14PM -0400, Viktor Dukhovni wrote:
> > On Apr 18, 2018, at 11:25 PM, Peter Gutmann
> > wrote:
> >> That's just silly. Really, 7.5 years (relative, not absolute) measured in
> >> hours is plenty good enough, and more than outlives current device
> >> obsolescence. T
> On Apr 18, 2018, at 11:25 PM, Peter Gutmann wrote:
>
>> That's just silly. Really, 7.5 years (relative, not absolute) measured in
>> hours is plenty good enough, and more than outlives current device
>> obsolescence. This isn't subject to Moore's law or anything like it.
>
> I don't know w
Nico Williams writes:
>That's just silly. Really, 7.5 years (relative, not absolute) measured in
>hours is plenty good enough, and more than outlives current device
>obsolescence. This isn't subject to Moore's law or anything like it.
I don't know what devices you work with, but for the ones w
On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters wrote:
>
> 2. Explicitly allow (but do not require) DoE be included
>>
>
> The document does not currently allow the extension to be empty. So if
> there is no TLSA record and the extension would be present, it therefore
> can only contain a DoE chai
> On Apr 18, 2018, at 5:03 PM, Richard Barnes wrote:
>
> The only "reserved" in RFC 5246 is a few code points that are reserved for
> private use. No reserved fields.
The field is NOT reserved, it carries an "extension support lifetime" of
16-bits whose zero value means "DO NOT PIN". Other
On Wed, Apr 18, 2018 at 05:01:54PM -0400, Richard Barnes wrote:
> On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni
> wrote:
> > > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote:
> > >
> > > Secondary point. Still don't think we should deliberately include
> > undefined fields, e.g., because p
On Wed, Apr 18, 2018 at 4:56 PM, Nico Williams
wrote:
> On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote:
> > On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni >
> > wrote:
> >
> > >
> > >
> > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote:
> > > >
> > > > I do not support a
On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote:
> >
> > Secondary point. Still don't think we should deliberately include
> undefined fields, e.g., because part of the discussion is whether 16 bits
> is the right size.
>
> 16 bi
On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote:
> On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni
> wrote:
>
> >
> >
> > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote:
> > >
> > > I do not support adding a field to the protocol with semantics to be
> > defined later. Espe
> On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote:
>
> Secondary point. Still don't think we should deliberately include undefined
> fields, e.g., because part of the discussion is whether 16 bits is the right
> size.
16 bits is clearly enough. If the units are hours that gets you ~7.5 y
> On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote:
>
> I do not support adding a field to the protocol with semantics to be defined
> later.
And the semantics are defined. The server must send zero, and the client must
read it as zero. The propose semantics PROHIBIT pinning, which is wh
On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote:
> >
> > I do not support adding a field to the protocol with semantics to be
> defined later. Especially a 16-byte field, which is a fair bit of cruft to
> carry around.
>
> The 16
> On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote:
>
> I do not support adding a field to the protocol with semantics to be defined
> later. Especially a 16-byte field, which is a fair bit of cruft to carry
> around.
The 16-byte is a typo. It was supposed to be 16-bit. My fault. Sorry.
On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters wrote:
> On Wed, 18 Apr 2018, Joseph Salowey wrote:
>
> This is a combined response of Viktor, Nico and Paul.
>
> Concerns have been raised about the trade-offs associated with pinning
>> and I
>> do not think we currently have consensus to add
>>
On Wed, 18 Apr 2018, Joseph Salowey wrote:
This is a combined response of Viktor, Nico and Paul.
Concerns have been raised about the trade-offs associated with pinning and I
do not think we currently have consensus to add
pinning. While I think it may be possible to come to consensus on pin
On 4/18/18 10:22 AM, Joseph Salowey wrote:
> Concerns have been raised about the trade-offs associated with pinning
> and I do not think we currently have consensus to add pinning. While I
> think it may be possible to come to consensus on pinning I think it may
> take some time. I believe we can
On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey wrote:
> We've had a lot of discussion on this thread that has pointed out that
> there are enough issues with the current document that we should recommend
> that the AD pull it back from the RFC editor.
>
> Concerns have been raised about the trad
We've had a lot of discussion on this thread that has pointed out that
there are enough issues with the current document that we should recommend
that the AD pull it back from the RFC editor.
Concerns have been raised about the trade-offs associated with pinning and
I do not think we currently hav
On Mon, Apr 16, 2018 at 04:21:27PM -0400, Paul Wouters wrote:
> On Mon, 16 Apr 2018, Viktor Dukhovni wrote:
> >>* We might want to say that if the TTL is zero then the clients MUST NOT
> >> pin and must clear any pin. And we might do this in spite of not
> >> describing any pinning semantics -- ex
> On Apr 16, 2018, at 4:21 PM, Paul Wouters wrote:
>
> This seems dangerous. If an attacker can re-route and get a rogue
> cert, they can set TTL to 0, negating a previously set TTL, without
> requiring proof by presenting the denial-of-existence of the TLSA
> record. That is also a downgrade a
On Mon, 16 Apr 2018, Viktor Dukhovni wrote:
* We might want to say that if the TTL is zero then the clients MUST NOT
pin and must clear any pin. And we might do this in spite of not
describing any pinning semantics -- explicitly leaving pinning
semantics to a future document.
Exactly. I'd
On 4/16/18 at 9:31 AM, n...@cryptonector.com (Nico Williams) wrote:
I wouldn't mind a (C'): a variant of (C) where we get denial of
existence and a one- or two-byte TTL (one by count of weeks or two-byte
count of hours) with de minimis text about it, leaving pinning semantics
to a separate docum
> On Apr 16, 2018, at 12:31 PM, Nico Williams wrote:
>
> I wouldn't mind a (C'): a variant of (C) where we get denial of
> existence and a one- or two-byte TTL (one by count of weeks or two-byte
> count of hours) with de minimis text about it, leaving pinning semantics
> to a separate document.
On Fri, Apr 13, 2018 at 12:16:43PM -0700, Jim Fenton wrote:
> From reading the abstract and introduction to this draft, it appears to
> be proposing mostly a performance improvement for retrieving web pages
> using DANE authentication. There is some security improvement, but that
> seems to be inci
On Fri, Apr 13, 2018 at 04:38:55PM -0400, Richard Barnes wrote:
> On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams
> wrote:
> > It's better to send the denial of existence than no extension -- the
> > client could just as well be pinning (because the I-D said it could, or
> > because the client does
On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams
wrote:
> On Thu, Apr 12, 2018 at 04:10:27PM -0700, Eric Rescorla wrote:
> > On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni >
> > wrote:
> > > Proposed text:
> > >
> > >When the server has DNSSEC-signed TLSA records, the first RRset in
> > >
On Thu, Apr 12, 2018 at 04:10:27PM -0700, Eric Rescorla wrote:
> On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni
> wrote:
> > Proposed text:
> >
> >When the server has DNSSEC-signed TLSA records, the first RRset in
> >the chain MUST contain the TLSA record set being presented.
> >Howe
On Thu, Apr 12, 2018 at 09:51:12PM -0700, Eric Rescorla wrote:
> On Thu, Apr 12, 2018 at 9:40 PM, Viktor Dukhovni
> wrote:
> > > On Apr 13, 2018, at 12:07 AM, Melinda Shore <
> > melinda.sh...@nomountain.net> wrote:
> > >
> > > I'm okay with putting denial-of-existence in there as a should,
> > >
I haven't been following this WG closely but read the draft and
discussion to see what this was all about, so here's an opinion from a
somewhat external reviewer, not in the room in London:
On 4/4/18 10:50 AM, Joseph Salowey wrote:
> Hi Folks,
>
> Some objections were raised late during the review
On Thu, Apr 12, 2018 at 04:40:25AM -0400, Paul Wouters wrote:
> On Wed, 11 Apr 2018, Benjamin Kaduk wrote:
>
> >I don't really agree with that characterization. To state my understanding,
> >as responsible AD, of the status of this document: this document is in the
> >RFC Editor's queue being pro
I realize I'm not following the TLS working group. I was asked to
review this issue by someone who was confused and hurt by the current
process and was asking for a less involved opinion. Since I took the
trouble to review the document, to review a good chunk of the current
list discussion, I de
> On Apr 13, 2018, at 12:51 AM, Eric Rescorla wrote:
>
> Thanks for pointing this out. I agree that this text is likely to cause
> interop problems and should be removed or at least scoped out in
> the case where client and server are unrelated. I regret that I didn't
> catch it during my IESG
On Thu, Apr 12, 2018 at 9:40 PM, Viktor Dukhovni
wrote:
>
> > On Apr 13, 2018, at 12:07 AM, Melinda Shore <
> melinda.sh...@nomountain.net> wrote:
> >
> > I'm okay with putting denial-of-existence in there as a should,
> > but I do feel strongly that pinning belongs in a separate document.
> > As
> On Apr 13, 2018, at 12:07 AM, Melinda Shore
> wrote:
>
> I'm okay with putting denial-of-existence in there as a should,
> but I do feel strongly that pinning belongs in a separate document.
> As I said earlier, I have a problem with putting features in protocols
> that nobody intends to us
On 4/12/18 6:55 PM, Viktor Dukhovni wrote:
> If you'd like me to craft revised option (A) text, that includes a suitable
> caveat, I can try.
I'm okay with putting denial-of-existence in there as a should,
but I do feel strongly that pinning belongs in a separate document.
As I said earlier, I
> On Apr 12, 2018, at 7:47 PM, Eric Rescorla wrote:
>
> In the current document, there is no expectation that clients will pin the
> server's use of TLSA and therefore the server can safely stop using
> TLSA (or run a mixed server farm). However, because this text implies
> that the client *cou
> On Apr 12, 2018, at 7:47 PM, Eric Rescorla wrote:
>
> In the current document, there is no expectation that clients will pin the
> server's use of TLSA and therefore the server can safely stop using
> TLSA (or run a mixed server farm). However, because this text implies
> that the client *cou
On Thu, Apr 12, 2018 at 4:14 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 12, 2018, at 7:10 PM, Eric Rescorla wrote:
> >
> > The difficulty here is what the server knows about the clients behavior.
> > Specifically, if the server serves TLSA records and then ceases doing
> > without serving authent
> On Apr 12, 2018, at 7:10 PM, Eric Rescorla wrote:
>
> The difficulty here is what the server knows about the clients behavior.
> Specifically, if the server serves TLSA records and then ceases doing
> without serving authenticated denial of existence, then it is unable to
> determine if this
> On Apr 12, 2018, at 6:34 PM, Shumon Huque wrote:
>
> Implementers that are opposed to pinning would then just ignore this second
> draft (and not bother with the authenticated denial part of the first draft).
The pin hint is NOT an obligation on the client or the server. It is OPTIONAL.
Se
On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 12, 2018, at 6:44 PM, Willem Toorop wrote:
> >
> > Well... I find it unfortunate that the line you were quoting from
> > section 3.4 could be interpreted as prohibiting the possibility of
> > denial of existence. So I am ope
On Thu, Apr 12, 2018 at 3:09 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 12, 2018, at 5:47 PM, Martin Thomson
> wrote:
> >
> > If this is indeed about adding [goo], what prevents Viktor or Paul
> > from proposing a new addition to the protocol in the form of a new I-D
> > that enacts the changes t
> On Apr 12, 2018, at 6:44 PM, Willem Toorop wrote:
>
> Well... I find it unfortunate that the line you were quoting from
> section 3.4 could be interpreted as prohibiting the possibility of
> denial of existence. So I am open to relaxing that text so that it can
> not be interpreted as such a
> "RB" == Richard Barnes writes:
RB> It seems noteworthy, however, that nobody is chiming in on the list who was
RB> not also part of the discussion in the room.
Not true.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
___
TLS mailing
Op 13-04-18 om 00:09 schreef Viktor Dukhovni:
> The protocol as described prohibits denial of existence responses. Willem
> acknowledged (thus far in an off-list message) that that's an oversight that
> should be corrected, and such a correction is the substance of option (A).
Well... I find it u
On Fri, Apr 13, 2018 at 8:09 AM, Viktor Dukhovni wrote:
>> On Apr 12, 2018, at 5:47 PM, Martin Thomson wrote:
>>
>> If this is indeed about adding [goo], what prevents Viktor or Paul
>> from proposing a new addition to the protocol in the form of a new I-D
>> that enacts the changes they wish to
On Thu, Apr 12, 2018 at 6:09 PM, Viktor Dukhovni
wrote:
>
>
> > On Apr 12, 2018, at 5:47 PM, Martin Thomson
> wrote:
> >
> > If this is indeed about adding [goo], what prevents Viktor or Paul
> > from proposing a new addition to the protocol in the form of a new I-D
> > that enacts the changes t
> On Apr 12, 2018, at 5:47 PM, Martin Thomson wrote:
>
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the protocol in the form of a new I-D
> that enacts the changes they wish to see?
Why publish a crippled specification that needs immed
On 4/12/18 1:47 PM, Martin Thomson wrote:
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the protocol in the form of a new I-D
> that enacts the changes they wish to see?
Clearly nothing, and I think this would be a reasonable way forward.
This is in fact what I proposed in the room in London. Let's publish draft
this as-is, and handle what they want as a follow-on.
On Thu, Apr 12, 2018 at 5:47 PM, Martin Thomson
wrote:
> If this is indeed about adding [goo], what prevents Viktor or Paul
> from proposing a new addition to the pro
If this is indeed about adding [goo], what prevents Viktor or Paul
from proposing a new addition to the protocol in the form of a new I-D
that enacts the changes they wish to see?
On Fri, Apr 13, 2018 at 7:41 AM, Melinda Shore
wrote:
> On 4/12/18 9:54 AM, Benjamin Kaduk wrote:
>> I'm waiting to s
On 4/12/18 9:54 AM, Benjamin Kaduk wrote:
> I'm waiting to see if anything else comes out of this thread.
> In particular, I am hoping that some authors/proponents of leaving the
> document in the RFC Editor queue would speak to the question of the
> target scope, given the arguments that have been
On Thu, Apr 12, 2018 at 08:20:22PM +0200, Willem Toorop wrote:
> Sorry for being confusing. I meant to say full Denial of Existing is in
> the draft implicitly already (because of the reference to DANE
> authentication according to RFC6698 and RFC7671 (which do mention it) in
> Section 6).
>
>
>
> On Apr 12, 2018, at 2:20 PM, Willem Toorop wrote:
>
> I notice that existing STS documents (HSTS [RFC6797] and MTA-STS
> [draft-ietf-uta-mta-sts]) are all one layer above TLS. Is a STS TTL
> conveyed in a ServerHello message secure when it would be just for SSL?
The reason for that of cours
> On Apr 4, 2018, at 1:50 PM, Joseph Salowey wrote:
>
> If the answer to 1) is no then please indicate if you think the working group
> should work on the document to include
>
> A) Recommendation of adding denial of existence proofs in the chain provided
> by the extension
> B) Adding sign
Sorry for being confusing. I meant to say full Denial of Existing is in
the draft implicitly already (because of the reference to DANE
authentication according to RFC6698 and RFC7671 (which do mention it) in
Section 6).
I do like the idea of STS for this extension (and augment it with the
more r
On Thu, Apr 12, 2018 at 09:50:20AM -0400, Kathleen Moriarty wrote:
> There's a few steps Paul is missing in his summary of the process.
>
> On Thu, Apr 12, 2018 at 8:58 AM, Richard Barnes wrote:
> >
> >
> > On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote:
> >>
> >> On Wed, 11 Apr 2018, Benja
There's a few steps Paul is missing in his summary of the process.
On Thu, Apr 12, 2018 at 8:58 AM, Richard Barnes wrote:
>
>
> On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote:
>>
>> On Wed, 11 Apr 2018, Benjamin Kaduk wrote:
>>
>>> I don't really agree with that characterization. To state
On Thu, Apr 12, 2018 at 9:46 AM, Paul Wouters wrote:
> On Thu, 12 Apr 2018, Richard Barnes wrote:
>
> The question Ben was asking, though, is whether the impact of that process
>> mistake is serious enough to merit pulling back the doc from the RFC editor.
>>
>
> That can only be answered after t
On Thu, 12 Apr 2018, Richard Barnes wrote:
The question Ben was asking, though, is whether the impact of that process
mistake is serious enough to merit pulling back the doc from the RFC editor.
That can only be answered after the consensus call. I don't think anyone
is really objecting as lo
On Thu, Apr 12, 2018 at 4:40 AM, Paul Wouters wrote:
> On Wed, 11 Apr 2018, Benjamin Kaduk wrote:
>
> I don't really agree with that characterization. To state my
>> understanding,
>> as responsible AD, of the status of this document: this document is in the
>> RFC Editor's queue being processed
On Wed, 11 Apr 2018, Benjamin Kaduk wrote:
I don't really agree with that characterization. To state my understanding,
as responsible AD, of the status of this document: this document is in the
RFC Editor's queue being processed.
That was a process mistake.
1) ekr filed a DISCUSS
2) other pe
> On Apr 11, 2018, at 1:33 PM, Benjamin Kaduk wrote:
>
> You say this, but to me it seems a relevant factor when determining the
> target scope for the spec. That is, if some individual believes that
> DANE is amazing and the Web PKI is crap, then that individual is likely
> to want to see DANE
On Tue, Apr 10, 2018 at 06:53:21PM -0500, Nico Williams wrote:
> On Tue, Apr 10, 2018 at 09:48:24AM -0400, Shumon Huque wrote:
>
> Assertion of facts not in evidence. We're here because there is a
That argument cuts in many directions, of course.
> question as to consensus (and/or process). We
> On Apr 10, 2018, at 8:17 PM, Melinda Shore
> wrote:
>
> There's an unfortunate number of IETF protocols that
> people worked on for years and that never saw implementation, and
> it seems to me that we ought to be trying to minimize the chances
> of that happening with the protocols we're wo
On Tue, Apr 10, 2018 at 04:17:14PM -0800, Melinda Shore wrote:
> On 4/10/18 3:53 PM, Nico Williams wrote:
> > The earlier consensus is not just applicable, as if it were, we would
> > not be having this LC.
>
> I have no idea what that even means, to be honest. We're through
> last call, and it's
On Tue, Apr 10, 2018 at 11:48:58AM -0500, Benjamin Kaduk wrote:
> On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote:
> > > On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote:
> > > But I would also like to publish a document that has the solid
> > > consensus of the community that is on
On 4/10/18 3:53 PM, Nico Williams wrote:
> The earlier consensus is not just applicable, as if it were, we would
> not be having this LC.
I have no idea what that even means, to be honest. We're through
last call, and it's not that the earlier wg consensus isn't
"applicable," it's that you've rai
On Tue, Apr 10, 2018 at 09:48:24AM -0400, Shumon Huque wrote:
> Yes. I support the publication of the document as is.
>
> and would like to explain my position a bit.
>
> I'm very sympathetic to Viktor's desire to enhance this protocol
> to provide downgrade resistance against PKIX attacks, and I
[I only have part of the thread available, and so am replying to the
last message I see.]
I agree that the draft MUST explicitly support chains corresponding to
a NXDOMAIN or NODATA responses to have sufficient value.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
___
On Tue, Apr 10, 2018 at 11:22 AM, Paul Wouters wrote:
> On Tue, 10 Apr 2018, Willem Toorop wrote:
>
> I just want to clarify one misconception in Willem's statement. See my
> previous emails to thist list for my full arguments on this issue.
>
> The chain extension already contains verification o
On Tue, Apr 10, 2018 at 01:25:02PM -0400, Shumon Huque wrote:
> On Tue, Apr 10, 2018 at 12:48 PM, Benjamin Kaduk wrote:
> [...]
>
> > I concede that it remains useful to consider what the client will do
> > with the received DANE records or denial thereof, so as to not unduly
> > block off future
On Tue, Apr 10, 2018 at 12:48 PM, Benjamin Kaduk wrote:
[...]
> I concede that it remains useful to consider what the client will do
> with the received DANE records or denial thereof, so as to not unduly
> block off future routes for development. But it seems at least possible
> to take
> a ver
Hi Viktor,
With no hats.
On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote:
>
>
> > On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote:
> >
> > But I would also like to publish a document that has the solid
> > consensus of the community that is one of key potential target
> > cons
> On Apr 10, 2018, at 11:22 AM, Paul Wouters wrote:
>
> This hints at returning the proof of non-existence, but clearly even the
> authors are now saying they did not mean this and a server is not
> required to do this. Clearly the text needs clarification, and if it
> then leaves out denial of
On Tue, 10 Apr 2018, Willem Toorop wrote:
I just want to clarify one misconception in Willem's statement. See my
previous emails to thist list for my full arguments on this issue.
The chain extension already contains verification of Denial Of Existence
proofs, because that is needed for verifyi
analysis posted
earlier in this thread, please post a correction.
From: Martin Thomson
Date: Thu, 5 Apr 2018 12:07:57 +1000
To: TLS WG
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
[skepticism re pinning, addressed in follow-ups]
Your cost benefit analysi
On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey wrote:
> Hi Folks,
>
> Some objections were raised late during the review of
> the draft-ietf-tls-dnssec-chain-extension. The question before the
> working group is either to publish the document as is or to bring the
> document back into the working
I support separation of concerns: publish as is, and start new work to
extend existing Strict Transport Security mechanisms to include DANE
authenticated TLS.
Currently the draft is describing only a single mechanism: Letting
owners of a (DNSSEC signed) domain vouch for their own TLS services.
Not
> 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.
Uniformed specul
> 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 thi
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 th
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
> 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 app
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 h
> 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
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.
>
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 T
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
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 techn
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 al
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 WebP
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
> 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 dem
On Thu, Apr 5, 2018 at 1:09 PM, Nico Williams 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.
Do you have both clients and servers that are interested in this
pa
On Wed, Apr 4, 2018 at 8:09 PM, Nico Williams wrote:
> On Wed, Apr 04, 2018 at 08:06:42PM -0700, Eric Rescorla wrote:
> > On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams
> wrote:
> >
> > > > HPKP had a TTL and yet as a practical matter, people found it very
> > > > problematic.
> > >
> > > I can s
On Wed, Apr 04, 2018 at 08:06:42PM -0700, Eric Rescorla wrote:
> On Wed, Apr 4, 2018 at 7:34 PM, Nico Williams wrote:
>
> > > HPKP had a TTL and yet as a practical matter, people found it very
> > > problematic.
> >
> > I can see why: you have to commit to one certificate in the chain not
> > cha
1 - 100 of 122 matches
Mail list logo
