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 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 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:
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
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
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 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 depe
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 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.
>
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
> 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 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 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 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 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 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
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 expect
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
> 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.
>
19 matches
Mail list logo
