> 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
Martin Rex writes:
>I expect TLSv1.3 is going to be in a decade where IPv6 is today.
It'll be interesting to see. This certainly seems to be true for HTTP/2
a.k.a. HTTP4Google, I was expecting usage to be mostly Google-only but from
the little data I could find it appears to be even worse than
All,
-00 of draft-rescorla-tls-dtls13 [0][1] was discussed at IETF 97 [2]. It’s now
at version -01 and GH issues are slowly rolling in. It’s also on our agenda
again at IETF 98, and DTLS a chartered work item, so it seems like it’s time to
get the WG adoption process started for this individu
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 Tue, Mar 21, 2017 at 7:30 PM, Eric Rescorla wrote:
> This proposal seems like a reasonable idea. One question I had is what the
> point of the "uncompressed length" field is:
>
>struct {
> uint24 uncompressed_length;
> opaque compressed_certificate_message<1..2^
Peter Gutmann wrote:
> Thomas Pornin writes:
>>
>>TLS 1.3 is moving away from the IoT/embedded world, and more toward a Web
>>world. This is not necessarily _bad_, but it is likely to leave some people
>>unsatisfied (and, in practice, people clinging to TLS 1.2).
>
> I would go slightly further
> On Mar 22, 2017, at 15:32, Benjamin Kaduk wrote:
>
> On 03/22/2017 02:30 PM, Sean Turner wrote:
>> - TLS 1.2 Update for Long-term Support
>> draft-rescorla-tls-subcerts
>>
>
> Presumably that is actually draft-gutmann-tls-lts?
yes
spt
___
TL
On 03/22/2017 02:30 PM, Sean Turner wrote:
> - TLS 1.2 Update for Long-term Support
> draft-rescorla-tls-subcerts
Presumably that is actually draft-gutmann-tls-lts?
-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
> On Mar 15, 2017, at 19:22, Sean Turner wrote:
>
> Please note that I’ve uploaded the TLS session’s agenda:
>
> https://www.ietf.org/proceedings/98/agenda/agenda-98-tls-01
>
> spt
You should note that the last item on the agenda is "Disposition of additional
drafts discussed on list”. The
> 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
13 matches
Mail list logo
