I have analyzed the two mechanisms proposed in the draft, with specific focus
on the impact of middleboxes.
Assumptions:
The middlebox is deployed inline, between the client and the fronting server,
and is allowed to intercept TLS sessions. The middlebox is policy-driven, and
uses SNI as
I think that the current behavior is fine, but we might add text to
suggest that identities be self-authenticating to avoid this sort of
enumeration. Note that in common practice, this sort of enumeration
would be over an infeasibly large space, it's only where identities
are more easily enumerabl
Thanks Éric.
https://github.com/tlswg/tls-record-limit/pull/16 fixes your nit.
On Thu, Feb 22, 2018 at 12:46 AM, Éric Vyncke wrote:
> Reviewer: Éric Vyncke
> Review result: Has Nits
>
> Reviewer: Eric Vyncke
> Review results: has nits
>
> Hello Martin,
>
> I have reviewed this document as part o
On Wed, Feb 21, 2018 at 11:21 AM, Paul Wouters wrote:
> On Thu, 8 Feb 2018, Viktor Dukhovni wrote:
>
> For clients that do reject PKIX success based on DANE failure, and
>> cache obtained TLSA records, it might have been good to recommend
>> refreshing the TLSA records while the cached data is st
> On Feb 21, 2018, at 2:21 PM, Paul Wouters wrote:
>
>> For clients that do reject PKIX success based on DANE failure, and
>> cache obtained TLSA records, it might have been good to recommend
>> refreshing the TLSA records while the cached data is still valid
>> (say the smaller of some refresh
On Wed, 21 Feb 2018, Shumon Huque wrote:
Okay, got it. For people that have already implemented this, I think
there has been an implicit understanding that the format of the chain
data is a sequence of concatenated wire format RRs exactly as they appear
in a DNS message section
Note, I would n
On Thu, 8 Feb 2018, Viktor Dukhovni wrote:
For clients that do reject PKIX success based on DANE failure, and
cache obtained TLSA records, it might have been good to recommend
refreshing the TLSA records while the cached data is still valid
(say the smaller of some refresh time or 50% of TTL has
> On Feb 21, 2018, at 11:00 AM, Shumon Huque wrote:
>
> On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson
> wrote:
> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
> wrote:
>> What's the behavior when the middlebox is a proxy, let's say existing
>> a managed network? I presume from from s
On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque wrote:
> Sorry for my belated follow-up. Was temporarily overwhelmed by the
> day job ..
>
>
> On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla wrote:
> > On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote:
> >
> > > > IMPORTANT: I'm not sure that this
On Wed, Feb 21, 2018 at 12:05 PM, Viktor Dukhovni
wrote:
>
>
> > On Feb 21, 2018, at 10:57 AM, Shumon Huque wrote:
> >
> > On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni
> wrote:
> >
> > Summary as I see it:
> >
> > * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure
> > of PKI
> On Feb 21, 2018, at 10:57 AM, Shumon Huque wrote:
>
> On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni
> wrote:
>
> Summary as I see it:
>
> * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure
> of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs
> are cache and t
On Wed, Feb 7, 2018 at 9:05 PM, Shumon Huque wrote:
> On Wed, Feb 7, 2018 at 1:22 PM, Alexey Melnikov
> wrote:
>
>> Alexey Melnikov has entered the following ballot position for
>> draft-ietf-tls-dnssec-chain-extension-06: Discuss
>>
>> ---
On Wed, Feb 21, 2018 at 11:00 AM, Shumon Huque wrote:
> On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson
> wrote:
>>
>> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
>> wrote:
>> > What's the behavior when the middlebox is a proxy, let's say existing
>> > a managed network? I presume from f
On Tue, Feb 13, 2018 at 5:50 PM, Martin Thomson
wrote:
> On Wed, Feb 14, 2018 at 4:07 AM, Kathleen Moriarty
> wrote:
> > What's the behavior when the middlebox is a proxy, let's say existing
> > a managed network? I presume from from section 3.1 that this
> > negotiation doesn't work in that in
On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni
wrote:
>
>
> Summary as I see it:
>
> * Mandatory DANE:
> MUST Refuse absence of TLSA RRs or failure
> of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs
> are cache and the server does not present the extension.
>
> * "Opportun
Sorry for my belated follow-up. Was temporarily overwhelmed by the
day job ..
On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla wrote:
> On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote:
>
> > > IMPORTANT: I'm not sure that this is actually sufficient to allow an
> > > independent implementation
i think your general point is sound here, but I'll nitpick the statement
that
"if the server recognises an identity but is unable to verify corresponding
binder".
1. The server only picks one identity so you if you send A, B, and C and you
get an abort, you don't know if it recognized one or all.
On Wednesday, 21 February 2018 15:21:58 CET Eric Rescorla wrote:
> On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrote:
> > On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> > > The IESG has received a request from the Transport Layer Security WG
> >
> > (tls)
> >
> > > to consider the
(fixing missed i...@ietf.org)
On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG (tls)
> to consider the following document: - 'The Transport Layer Security (TLS)
> Protocol Version 1.3'
>as Proposed Standard
The cur
On Wed, Feb 21, 2018 at 6:13 AM, Hubert Kario wrote:
> On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> > The IESG has received a request from the Transport Layer Security WG
> (tls)
> > to consider the following document: - 'The Transport Layer Security (TLS)
> > Protocol Version 1.3'
On Wed, Feb 21, 2018 at 6:10 AM, Benjamin Kaduk wrote:
> On 02/21/2018 05:46 AM, Hubert Kario wrote:
> > On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> >> The IESG has received a request from the Transport Layer Security WG
> (tls)
> >> to consider the following document: - 'The Trans
On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG (tls)
> to consider the following document: - 'The Transport Layer Security (TLS)
> Protocol Version 1.3'
>as Proposed Standard
The current draft states that if the s
On 02/21/2018 05:46 AM, Hubert Kario wrote:
> On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
>> The IESG has received a request from the Transport Layer Security WG (tls)
>> to consider the following document: - 'The Transport Layer Security (TLS)
>> Protocol Version 1.3'
>>as Propose
Reviewer: Éric Vyncke
Review result: Has Nits
Reviewer: Eric Vyncke
Review results: has nits
Hello Martin,
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent o
On Friday, 16 February 2018 18:06:41 CET The IESG wrote:
> The IESG has received a request from the Transport Layer Security WG (tls)
> to consider the following document: - 'The Transport Layer Security (TLS)
> Protocol Version 1.3'
>as Proposed Standard
Section 4.1.2 currently states that th
25 matches
Mail list logo
