On Wed, Jul 8, 2020, at 14:22, Benjamin Kaduk wrote:
> Hi all,
>
> There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently
> in IESG Evaluation):
>
>The protocol convention specified in the current document assumes
>there can be no more than one concurrent TLS session per TC
On Tue, Jul 14, 2020, at 22:41, Achim Kraus wrote:
> For me it seems, that an agreement about this message buffer size is
> still missing.
This is a question we dealt with in QUIC by limiting UDP datagram size rather
than the record size (or packet size in QUIC terminology).
In this case, the sp
On Wed, Jul 15, 2020, at 08:53, Ben Schwartz wrote:
> For ease of deployment, I wonder whether the concept of a "scope" needs
> to be pinned down a bit more precisely. In 00 here, the scope is
> entirely implicit; servers are required to know how users might have
> found them, and what other se
I am supportive of this draft. I don't think it's needed now, but
eventually I would like to live in a world where we don't have to tolerate
these kinds of downgrades, and I don't think it's too early to be drawing
up the mechanism to prevent them.
For ease of deployment, I wonder whether the con
Watson:
This does not look right to me. The extensions in the certificate are:
extensions=Extensions:
Extension:
extnID=2.5.29.15
critical=True
extnValue=0x03020780
Extension:
extnID=2.5.29.37
critical=False
extnValue=0x300a06082b06010505070301
Extension:
e
On 08/07/2020 16:07, Nico Williams wrote:
> On Tue, Jul 07, 2020 at 09:22:24PM -0700, Benjamin Kaduk wrote:
>> There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently
>> in IESG Evaluation):
>>
>>The protocol convention specified in the current document assumes
>>there can be
On Tue, Jul 14, 2020 at 3:38 PM Salz, Rich
wrote:
>
> I would love to see a sample cert and private key in “PEM format” and samples
> of the TLS extensions encoded, or even a simplified handshake dump.
https://github.com/tlswg/tls-subcerts/pull/77
>
>
I would love to see a sample cert and private key in “PEM format” and samples
of the TLS extensions encoded, or even a simplified handshake dump.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Rich:
> Sec 4.2 doesn’t seem to agree with the complete ASN1 in Appendix A. The
> latter has DelegatedCredentialExtn which is mentioned in prose and a TBD in
> 4.2 Perhaps a comment or some other words to tie them together? Or does
> that issue just go away when IANA does the registration?
In no particular order. Mostly nits.
Sec 3.2, I understand the concern of ACME being a third-party dependency, while
the origin is not really. Perhaps a sentence of explanation why it is, would
help. Or maybe just say “with an ACME server” And then mention ACME in the
origin?
Sec 4, the “va
Hello list,
implementing a first experimental version of RFC 8449 for DTLS 1.2 in
the Eclipse Open Source Project "Californium", I got some doubts about
statements, which seems for me to be only applicable, if a API for
chunked read/write operations is available.
RFC 8449, Section 3, page 4
“Co
11 matches
Mail list logo
