On Wed, Mar 22, 2017 at 4:50 PM, Viktor Dukhovni
wrote:
>
> > On Mar 22, 2017, at 10:56 AM, Melinda Shore <
> melinda.sh...@nomountain.net> wrote:
> >
> > The draft could definitely benefit from
> > additional review.
>
> I find it ironic that section 4 includes:
>
>The components of the auth
On Thu, Mar 23, 2017 at 12:28 AM, Viktor Dukhovni
wrote:
>
> > On Mar 22, 2017, at 10:56 AM, Melinda Shore <
> melinda.sh...@nomountain.net> wrote:
> >
> > The draft could definitely benefit from additional review.
>
> A more complete walk through:
>
> > 2. Introduction
> >
> >This draft des
> On Mar 23, 2017, at 12:31, Melinda Shore wrote:
>
> On 3/23/17 8:14 AM, Viktor Dukhovni wrote:
>> I don't know how many other folks on the TLS WG list are prepared
>> to do a thorough review the DNSSEC aspects of this draft...
>> Perhaps the TLS and DNS communities overlap sufficiently that my
On 3/23/17 8:14 AM, Viktor Dukhovni wrote:
> I don't know how many other folks on the TLS WG list are prepared
> to do a thorough review the DNSSEC aspects of this draft...
> Perhaps the TLS and DNS communities overlap sufficiently that my
> concern is not warranted?
I think it's quite warranted,
> On Mar 23, 2017, at 11:53 AM, Melinda Shore
> wrote:
>
> Thanks for the thorough review, Viktor. I'll get the straightforward
> bits into the draft over the weekend and plan on discussing the ones
> proposing changes to the extension or to chain construction and
> processing in the working g
Thanks for the thorough review, Viktor. I'll get the straightforward
bits into the draft over the weekend and plan on discussing the ones
proposing changes to the extension or to chain construction and
processing in the working group session.
Melinda
signature.asc
Description: OpenPGP digital
> On Mar 22, 2017, at 10:56 AM, Melinda Shore
> wrote:
>
> The draft could definitely benefit from additional review.
A more complete walk through:
> 2. Introduction
>
>This draft describes a new TLS [RFC5246] extension for transport of a
>DNS record set serialized with the DNSSEC s
The way that the UKS attack is mitigated here is counter-intuitive.
It is via inclusion of the *name* in the handshake transcript and
validation of that name that we get the protection we need.
Victor is right to question this. This isn't a very obvious result
and needs more text than a single si
> On Mar 22, 2017, at 10:56 AM, Melinda Shore
> wrote:
>
> The draft could definitely benefit from
> additional review.
I find it ironic that section 4 includes:
The components of the authentication chain are built by starting at
the target record set and its corresponding RRSIG. Then
> On Mar 22, 2017, at 10:56 AM, Melinda Shore
> wrote:
>
> The draft could definitely benefit from
> additional review.
Quick comment:
3.3. Raw Public Keys
[RFC7250] specifies the use of raw public keys for both server and
client authentication in TLS 1.2. It points out that in ca
Thanks - I've updated those, as well.
Our sense right now is that the pieces that need completion
prior to going to working group last call are to add
some pseudocode to clarify construction of the chain, and
test vectors. The draft could definitely benefit from
additional review.
Thanks,
Melin
> On Mar 21, 2017, at 21:22, Melinda Shore wrote:
>
> On 3/21/17 4:20 PM, Eric Rescorla wrote:
>>
>> EDITORIAL
>> You should replace "client hello" with ClientHello throughout.
>
> Thanks, EKR. I've updated the draft based on these comments and
> will submit it once submissions reopen.
Minor
On 3/21/17 4:20 PM, Eric Rescorla wrote:
> SUBSTANTIVE
>
>Servers receiving a "dnssec_chain" extension in the client hello, and
>which are capable of being authenticated via DANE, SHOULD return a
>serialized authentication chain in the Certificate message, using the
>format describ
SUBSTANTIVE
Servers receiving a "dnssec_chain" extension in the client hello, and
which are capable of being authenticated via DANE, SHOULD return a
serialized authentication chain in the Certificate message, using the
format described below. The authentication chain will be an
ext
14 matches
Mail list logo
