On Fri, Jan 18, 2019, at 07:23, David Benjamin wrote:
> > while record_size_limit extension sends just one value, it does
> > specifically
> > allow the client to advertise higher values than the protocol versions or
> > extensions would indicate
> >
> > I wonder if sending such values shouldn't be
> I don't feel very strongly either way, though it is odd that it basically
> contradicts the sender's rules in RFC 8449.
>
>Higher values are currently reserved for future
>versions of the protocol that may allow larger records; an endpoint
>MUST NOT send a value higher than the proto
TLS 1.3 is pretty firm about what you can change in a second ClientHello. It
lists a small set of allowed changes to extensions (cookie, PSK binder, key
shares, early data, and padding). For the rest it says that nothing can
change. So clearly a client is in the wrong if it changes, adds, or
On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote:
> given need for GREASE and two dozen flags across OpenSSL history for
> workarounds for bugs in different implementations, the lesson seems to be
> that
> the receiving side should be as strict as it can (within protocol confines)
> or
> we r
What David said.
We implement 7919, which includes an option to only accept server shares from
the 7919 groups. With that option a simple comparison is used to determine if
the group is one from the spec, rejecting all else, but we otherwise just treat
the share as normal. I'm not aware of an
LGTM.
I would strike ", if these privacy properties are important in a given
deployment" from the acknowledgments section (which is an odd place for the
accompanying statement.
I would add an explicit note about the lack of CID update making this
unsuitable for mobility scenarios. That's a c
Thanks to the authors for this survey. I think that it is good to have this
sort of work is extremely valuable in informing decisions.
I would like to see one approach come out of discussion here. I don't want the
protocol to be a tapestry of options. As someone who has to maintain software,
This is quite an interesting idea, and it's good to see a draft starting the
discussion.
I have some interest in this general problem space, but am concerned that this
proposal is operating at the wrong layer of the stack. It's a fairly obvious
design, given that TLS provides the NewSessionTic
I see a substantially similar draft in draft-pauly-quic-address-extension. I'd
like to understand how these might be complementary, or whether the idea is to
pursue only one. The QUIC extension seems superior, if you have QUIC. There
are a lot more plausible reasons to want this information i
I've no real opinion on whether this draft is worth doing, because that depends
on making an assessment about CWT and I keep bouncing off the C part. I guess
that the point of the draft is to start that part of the discussion, which is a
fine thing.
There are a few more mundane, mechanical iss
This needs more space for each flag. 8 bits is a pretty small space. If you
are concerned with the size of the result, we have some variable-length integer
encodings you could try.
On Tue, Mar 26, 2019, at 00:22, Salz, Rich wrote:
>
> That was FAST.
>
>
> Looks good.
>
>
> *From: *Yoav N
We don't trust that the key share or certificate is good either, but once we
have a Finished message, that is retroactively authenticated and can be used.
We rely on this property for a bunch of things.
On Mon, Mar 25, 2019, at 19:12, Hubert Kario wrote:
> On Monday, 25 March 2019 17:02:34 CET
Why not go all in - make this a byte string and start from 0x80 in the first
byte. When we define the 9th flag, we add another byte. Then you have up to
2040 flags (though it might pay to split the space before that).
struct {
opaque<1..255> flags;
} Flags;
Otherwise, the first adopter of t
On Wed, Mar 27, 2019, at 14:47, Eric Rescorla wrote:
> Of course, at some point it starts to make sense to do RLE.
I considered that, but I don't see this being sufficiently sparsely populated.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mail
On Tue, Mar 26, 2019, at 14:30, Hubert Kario wrote:
> On Tuesday, 26 March 2019 09:07:51 CET Martin Thomson wrote:
> > We don't trust that the key share or certificate is good either, but once we
> > have a Finished message, that is retroactively authenticated and can be
> &
Inspired by a few side discussions and Yoav's new draft, I have the pleasure of
announcing the first proposal to use that mechanism:
https://tools.ietf.org/html/draft-thomson-tls-sic-00
I'm sure that there are plenty of opportunities to bike shed on the flags
format, but it's definitely useful
On Thu, Mar 28, 2019, at 14:54, Hubert Kario wrote:
> what about making sure that the legacy and flags remain in-sync? we will have
> to send the legacy encoding for many years to come, so only thing it would
> possibly reduce the size of is ServerHello or EncryptedExtensions
Those are messages
On Thu, Mar 28, 2019, at 14:46, Hubert Kario wrote:
> what about resumption and renegotiation?
No certificates in resumption.
No resumption in TLS 1.3 (and I don't care about TLS 1.2 any more).
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mai
On Fri, Mar 29, 2019, at 11:18, Andrei Popov wrote:
> > No resumption in TLS 1.3...
> You probably mean no renegotiation in TLS 1.3.
Of course, thank you. Not nearly enough sleep this week.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman
On Thu, Mar 28, 2019, at 16:58, Scott Fluhrer (sfluhrer) wrote:
> * 3.3.1. (Shares-concat) Concatenate key shares
> My concern with this is that there may be algorithms with variable key
> share size (I don’t know of any right now, but ‘extensibility’); if we
> do this, we would want internal le
In addition to this, the document would seem to allow a server to set bit k if
the client did not set that bit. (Or more generally, the responder can set bits
the initiator did not set. )
In fitting with the TLS model, I would recommend allowing a responder to set
only bits that the initiator s
On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote:
> > > would possibly reduce the size of is ServerHello or EncryptedExtensions
> >
> > Those are messages where we have size pressure.
>
> why? in what use case?
QUIC. We have 3600 bytes to play with in that flight. And Certificate is often
more
Adopt.
On Tue, Apr 9, 2019, at 10:57, Sean Turner wrote:
> At TLS@IETF104, there was consensus in the room to adopt
> draft-wood-tls-external-psk-importer. This message is to confirm that
> consensus. If you do not support adoption of
> draft-wood-tls-external-psk-importer as WG item please s
On Sat, Mar 30, 2019, at 06:05, John Mattsson wrote:
> And one more
>
> "The 0xTBD flag can only be send in a ClientHello or CertificateRequest
> message. Endpoints that receive a value of 1 in any other handshake
> message MUST generate a fatal illegal_parameter alert."
>
> This goes agai
I like the basic idea, but I don't think that this is the right solution. I
realize that we can adopt and fix, but I my preference is to have a little more
time to discuss solutions before we adopt anything.
On Sat, Apr 13, 2019, at 09:35, Christopher Wood wrote:
> At TLS@IETF104, there was int
Section 1.1 doesn't say *how* those listed documents are updated. Might pay to
include a few works on how.
Section 2 can be cut down a lot. The quote from another document is longer
than the rest of the text. In many ways, saying that the IETF is moving last
is not a great thing to memoriali
> Could an attacker perform some shenanigans with disjoint roots of
> trust, or by finding paths with differing policy constraints (if that
> even makes sense)?
>
> Would it help anything if the server included a digest of the
> certificate chain in its EncryptedExtensions?
&
On Tue, Apr 16, 2019, at 18:36, Erik Sy wrote:
> Hi Martin,
>
> can you please explain, why you think this is not the right solution?
To recap, the draft proposes an empty extension in ClientHello, which the
server, at its discretion, includes in Certificate.
There are two insights that are imp
On Sat, Apr 27, 2019, at 07:29, Viktor Dukhovni wrote:
> The sound-bite version is: first raise the ceiling, *then* the floor.
Yep. We've done the ceiling bit twice now. Once in 2008 when we published TLS
1.2 and then in 2018 with the publication of TLS 1.3. I'd say we're overdue
for the floo
sed:
>
> On Sat, Apr 13, 2019 at 12:16 AM Martin Thomson wrote:
> > Section 1.1 doesn't say *how* those listed documents are updated. Might pay
> > to include a few works on how.
>
> Thank you, that was helpful feedback. I changed the introduction text
> as fo
That's right. You might open an editorial erratum, which I would suggest be
held for document update.
Note that there is no promise that the list of extensions is complete, as this
doesn't show the supported_versions or signature_schemes extension either, but
the omission is probably not great
Two fixes required, but then I think HFDU is appropriate:
1. Misspelling of names.
2. The pre_shared_key extension requires the use of the psk_key_exchange_modes
extension.
On Fri, May 3, 2019, at 11:04, RFC Errata System wrote:
> The following errata report has been submitted for RFC8446,
> "T
On Fri, May 3, 2019, at 12:12, Eric Rescorla wrote:
> MT: why do you not think "confirmed"?
It seems like we use HFDU for this sort of thing and it's not like it's
strictly *wrong* here.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/li
Thanks for noticing that Tobias. I've opened an erratum, but am still waiting
for the RFC editor's email confirming it. I'll pass that along when that comes
through.
(This is the result of a bug in NSS, so in case you are interested:
https://bugzilla.mozilla.org/show_bug.cgi?id=1549225)
On S
Ilari answered your question, but this jumped out:
On Sun, May 5, 2019, at 21:11, geyer.lu...@gmail.com wrote:
> [...] both sides calculate,
> PSK = [...]
> and the server sends back to the client the PSK (unencrypted [...])
The PSK never gets sent. As you say, both sides can calculate the s
> "Example Handshake Traces for TLS 1.3".
> >
> > --
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5720
> >
> > ------
> > Type: Techni
On Sat, May 4, 2019, at 23:01, Kathleen Moriarty wrote:
> WG decision is appreciated on this point and proposed text for RFC 7525.
>
> Proposed: When using RSA, servers SHOULD authenticate using
> certificates with
>at least a 2048-bit modulus for the public key. In addition, the use
>
On Thu, May 9, 2019, at 16:09, Peter Gutmann wrote:
> You could just say "use SHA-2", which covers the whole family. Now in
> practice "SHA-2" means "SHA-256" so it'll be the same as saying SHA-256
> directly, but the more generic SHA-2 leaves it open to interpretation for the
> three people who u
It might pay to spend more time on explaining what you are trying to do.
The goal appears to be to remove a dependency on signature schemes that include
these weaker hash functions. But the introduction just says that the functions
are bad.
You should be very clear about what effect this has o
Unless it is a very subtle hint that the RFC should cite RFC 8174, that is.
On Fri, May 17, 2019, at 21:31, Eric Rescorla wrote:
> Unless I am confused, this has no content, so I think probably we
> should reject it.
>
> On Fri, May 17, 2019 at 2:06 PM RFC Errata System
> mailto:rfc-edi...@rfc-
RSASSA-PKCS1-v1_5 algorithms: Indicates a signature algorithm using
RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm
as defined in [SHS]. These values refer solely to signatures
which appear in certificates (see Section 4.4.2.2) and are not
defined for
On Thu, Jun 27, 2019, at 03:32, Sean Turner wrote:
> The IANA DEs (Designated Experts) think that the registry should
> indicate that the connection_id is DTLS-Only. This is the first
> extension defined that would need this marking. Currently, there is no
> “DTLS-Only” column in the TLS Exte
On Thu, Jun 27, 2019, at 11:33, Salz, Rich wrote:
> No, let's stick with the interesting case before us because, well, it
> shows a problem. We have a problem and lack of clarity in the
> registries, which can even be misleading. Yes the spec is definitive,
> and maybe a prolog in each TLS regi
You might like to coordinate with Martin Duke, who is doing similar (but
different) things with QUIC:
https://tools.ietf.org/html/draft-duke-quic-load-balancers-04
Personally, I find this sort of thing difficult to reason about. I would
rather have a separate TLS connection with each backend t
On Tue, Jul 2, 2019, at 01:12, Ben Schwartz wrote:
> To be clear, are you suggesting TLS-in-TLS, similar to Stephen's
> suggestion? Or are you suggesting a parallel connection to deliver the
> metadata?
I'm thinking that a parallel connection for metadata is going to be more
efficient in the ge
Hey Hannes,
This definitely looks like it needs attention.
This looks fairly lightweight, which is a good goal, but we have lots of
experience with this in QUIC now that suggests that there are trivial denial of
service attacks that can be mounted on simple designs. Have you looked at the
con
These changes look fine. Mostly.
I'm really concerned about shipping a protocol that enables the sorts of
attacks that connection IDs enable. I think that we should discuss that issue
when we meet. I know that Hannes' new draft is an attempt to tackle this
issue, but that's a long way from b
On Tue, Jul 23, 2019, at 21:09, Watson Ladd wrote:
> One note: kc2kdm.com is up and working with NSS clients. Please hit it!
Firefox nightly now has the preference
"security.tls.enable_delegated_credentials" in about:config. I wouldn't
recommend turning that on on a permanent basis, but you can
Hi Yoav,
Thanks for doing this. I personally prefer the flag choice you have.
I think that you need to move from CH,SH,EE (which has a weird duplication that
might be problematic), to CH, EE, CR, C. Critically, I don't think that you
want the ServerHello to carry any of these. Flags are gene
I like this work. It needs work, but I would like to help do that work.
On Wed, Jul 24, 2019, at 09:16, Eric Rescorla wrote:
> I am in favor of adopting this.
>
> On Wed, Jul 24, 2019 at 5:47 AM Christopher Wood wrote:
> > At TLS@IETF105, there was interest in the room to adopt
> > draft-nir-t
On Wed, Jul 24, 2019, at 09:52, Patton,Christopher J wrote:
> Is there any indication in the UI that a DC was negotiated?
There is not. We don't have any other machinery built yet, which is part of
why I don't recommend that people use this just yet.
https://github.com/quicwg/base-drafts/pull/2925 includes the (incomplete)
analysis done by Eric Kinnear.
See also
https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.8 and
subsequent sections
___
TLS mailing list
TLS@ietf.org
ht
On Wed, Jul 31, 2019, at 06:21, Benjamin Kaduk wrote:
> It's clear that anything we do needs to preserve compat with all four
> possibilities in the interop matrix for (old, enhanced) (client,
> server). Your closing note about duplicating payloads is something of a
> different creature, though, a
On Wed, Jul 31, 2019, at 13:54, Ben Schwartz wrote:
> The batch signing idea is very cool. I'm not entirely sure I understand
> the intended use case, though. The intro suggests that this motivated
> by DoS defense, but presumably an attacker who controls their own TLS
> client stack could simpl
On Thu, Aug 22, 2019, at 07:44, David Benjamin wrote:
> That clause was meant to be descriptive of the other bits of the
> document. "[Such-and-such] may not be [such-and-such]ed, so [some
> consequence of this]". Using "must not" reads odd to me: "GREASE values
> must not be negotiated, so the
Which value do they want? As we have previously established in relation to the
discussion on connection IDs and handshake types, there are values that would
be sent in the clear in (D)TLS 1.3, which have very tight constraints, and
those that would be sent under encryption, which might not need
I want to push on this a little harder. Not because I don't think that more
formal protections in the line of key separation are bad (they are great), but
more to dig into the real reasons driving this change. The justification I've
gotten thus far is somewhat superficial, and I want to see if
ed both ways, but I don't think that it's necessarily a good
> idea.
>
> Regards,
>
> Jonathan
>
> * The guarantees it is possible to get from this key-schedule change
> are a little bit nuanced, because a PSK handshake doesn't rely on a
> long-term as
Are you able to use an AEAD?
I agree that EtM is likely a non-starter, but moving to an AEAD is just better.
NSS does the "255 compares" approach, which I think is OK. In particular, if
the record is shorter, that information is public which ensures that the timing
behaviour is dependent on on
On Mon, Sep 16, 2019, at 05:28, Peter Gutmann wrote:
> Just out of curiosity, why do you say EtM is a non-starter? It neatly fixes
> the problems caused my MtE.
I don't know that many stacks implement it. We don't. There's nothing wrong
with it, but it's down to practicalities. My understand
There are two points here to consider:
1. Whether the key that we are feeding into this process is going to be used
exclusively for that purpose, or whether it might be used for something else.
2. How the key that is output from this process might need diversification.
What we learned from TLS
On Tue, Sep 17, 2019, at 11:26, Martin Thomson wrote:
> What we learned from TLS 1.3 is that HKDF is effectively a completely
> different KDF when it is used with a different hash function.
Hugo points out that I should clarify this to add:
One should not use HKDF with two hash functio
On Wed, Sep 18, 2019, at 00:56, Christopher Wood wrote:
> > In thinking about the first point, we might want to consider whether
> > the KDF that is used in the importer might need to be used in other
> > ways.
>
> To be clear, you're referring to HKDF and its role in deriving ipsk
> from eps
On Thu, Sep 19, 2019, at 01:41, Christopher Wood wrote:
> Ah, so, I think this is where the miscommunication is happening! The
> target KDFs I've been envisioning are not protocol specific.
As HKDF and the TLS 1.2 PRF are not the same function, wouldn't it be better to
have separate identifiers
So I agree with Kathleen's conclusion: not to change the goals of the current
document. But there are changes that I think are necessary (and thanks to
Daniel and John for highlighting these).
BTW, I've moved this to the TLS working group, because this is an active topic
there and I don't see
On Fri, Sep 27, 2019, at 10:52, Stephen Farrell wrote:
> >> """The expectation is that TLSv1.2 will continue to be used for
> >> many years alongside TLSv1.3."""
>
> So is your proposed change to only remove that sentence?
I just checked, and it seems like the only thing the document says along t
I think that the discussion Victor started about the number of tickets you
might want to supply being different for a resumed connection is a sensible
one, but I would caution against servers making inferences, especially in light
of a very clear signal from clients. Advice for client implement
On Thu, Oct 10, 2019, at 00:04, Eric Rescorla wrote:
> draft-ietf-rtcweb-security arch doesn't precisely encourage you to
> implement DTLS 1.0; there's no normative language at all (even in the
> non-2119 sense). It makes s factual statement about the history of the
> document and about the impa
I think that the DTLS thing doesn't require as much rewriting as observed.
Just say that when you say "TLS" you mean "TLS or DTLS" somewhere up front.
As to what a transport needs to provide, I think that there is no real text to
add regarding DTLS. You *could* say that as the application prot
These are pretty long strings. That means more hash iterations to get these
values. Are we comfortable with that?
Even excluding the prefix, the first is 39 octets.
On Thu, Oct 3, 2019, at 06:58, Christopher Wood wrote:
> Hi folks,
>
> draft-ietf-tls-exported-authenticator requires some IANA
tl;dr keep the space.
I had a little trouble reproducing the 12 from RFC 8446, so I double-checked.
Working from the base for SHA-256:
The last block of SHA-256 is rounded up to 448 bits (56 bytes), less one to
allow for padding. Therefore we have 55 bytes to use without having to run tw
On Fri, Oct 11, 2019, at 07:57, Ben Schwartz wrote:
> The obvious solution is for the TLS client (i.e. the CDN) to support
> direct entry of ESNI public keys alongside the IP address. Users who
> want to be able to rotate their ESNI keys more easily should use a
> backend identified by a domain
Thanks, that was my mistake. I confirmed with our code and we are indeed right
up to the line.
On Thu, Oct 10, 2019, at 23:37, Eric Rescorla wrote:
>
>
> On Wed, Oct 9, 2019 at 7:01 PM Martin Thomson wrote:
> > tl;dr keep the space.
> >
> > I had a little trou
On Fri, Oct 11, 2019, at 14:07, Viktor Dukhovni wrote:
> * The client has a what it believes to be a valid ticket
> and is willing to re-use it, and would prefer to avoid
> the cost of replacing it on each resumption.
>
> * The server is happy to allow re-use of still valid
> ticke
>
> > On Oct 15, 2019, at 6:34 PM, Nick Sullivan
> > wrote:
> >
> > TLSWG,
> >
> > I'd like some feedback on a potential issue raised by Martin Thomson at the
> > last IETF. The question is about the interaction between the SPKI
On Tue, Oct 15, 2019, at 17:13, Nick Sullivan wrote:
> One may note that no matter what the choice is with respect to RSA,
> this particular wrinkle also applies more broadly. For example, if a
> client advertises support for ed25519 in "signature_algorithms" in
> order to support ed25519 delega
On Thu, Oct 17, 2019, at 14:32, Watson Ladd wrote:
> In TLS 1.3 it seems to have been assumed this wouldn't happen and we
> could split signature algorithms from signature algorithms cert.
>
> If that's not actually the case it affects more than just DCs. DCs are
> a good way to restore extensib
There was a lengthy discussion after the last time this was discussed. Can I
request that an editor (or a chair) summarize that discussion and the resulting
actions (if any)? I was involved in that discussion, but I don't see any
changes from that. I'm totally OK with publication as-is, but I
One belated comment, editorial in nature: The draft now uses the term "packet"
in quite a few places. The older text uses datagram. I suggest that this be
normalized before the publication request is made.
On Tue, Nov 5, 2019, at 03:08, Sean Turner wrote:
> This WGLC has concluded. I will com
It was pointed out to me that the header protection in QUIC and DTLS 1.3 are
different in a non-useful way:
https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#hp-chacha says that the
first 4 bytes of the sample are the counter, i.e., `counter[4] || nonce[12]`.
DTLS 1.3 says that the last
> Omitting the length field MUST only be used for data which is protected with
> one of the application_traffic_secret values, and not for messages protected
> with either [sender]_handshake_traffic_sercret or
> [sender]_early_traffic_secret values. When using an
> [sender]_application_traffic
Since Rob quoted this:
On Tue, Nov 12, 2019, at 09:42, Rob Sayre wrote:
> with the exception that there is no DTLS version of SSLv2 or SSLv3,
also on this list is TLS 1.0. DTLS 1.0 is TLS 1.1.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.or
I think that I am OK with the CertificateRequest-like concept (c). The idea
that CertificateRequest might be used from client to server (a) is something
that I think we might be willing to consider in the fullness of time, but for
now I think that it is probably best to avoid making retroactive
On Tue, Nov 19, 2019, at 10:56, Nick Sullivan wrote:
> The text could be amended to say something like:
> "the allowed extensions for client-generated authenticator requests
> need to have CH listed, and for server-generated authenticator requests
> need to have CR listed"
> The only current ext
On Tue, Nov 19, 2019, at 11:21, Martin Thomson wrote:
> On Tue, Nov 19, 2019, at 10:56, Nick Sullivan wrote:
> > The text could be amended to say something like:
> > "the allowed extensions for client-generated authenticator requests
> > need to have CH listed
If we do the caveman thing and concatenate inputs to HKDF-Extract, what do you
think we should do to the rest of the key schedule to ensure that there is
diversity?
In the PSK importer draft, we use a different binder label. Do we need
diversification if there could be multiple inputs later in
On Thu, Nov 21, 2019, at 11:17, Nick Sullivan wrote:
> https://github.com/tlswg/tls-subcerts/pull/45
Thanks for putting this together Nick. This PR cleanly captures the resolution
of the discussion.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.o
On Thu, Nov 21, 2019, at 11:19, David Schinazi wrote:
> resources. Therefore, the number of NewSessionTicket messages sent
> SHOULD be the minimum of the server's self-imposed limit and
> TicketRequestContents.count.
Thanks for doing this David.
Friendly amendment: remove the SHOULD from this
On Thu, Nov 21, 2019, at 11:54, Nick Sullivan wrote:
> At IETF 106, we discussed adding the ability to advertise specific
> signature algorithms for use in DCs without requiring clients to have
> to support these signature algorithms in leaf certificates.
Is the intent with supporting an empty e
On Thu, Nov 21, 2019, at 13:36, Sean Turner wrote:
> [...] if you believe that the TLS WG should not adopt this as a
> WG item, then please let the chairs know by posting a message to the
> TLS list by 2359 UTC 13 December 2019 (and say why).
I know you want dissent, but I thought I would instea
I support adoption. We can sort out the few tiny issues remaining in the
working group.
On Thu, Nov 21, 2019, at 14:56, Sean Turner wrote:
> At IETF 106 there was support for adoption of "Batch Signing for TLS"
> [0] as a WG item. To confirm this on the list: if you believe that the
> TLS WG
On Thu, Nov 21, 2019, at 14:19, David Schinazi wrote:
> Regarding Viktor's suggestion, I personally believe it would increase the
> complexity of the proposal, and I don't see use-cases compelling enough
> to warrant that complexity. I would rather keep this proposal as simple as
> possible.
I see
On Tue, Jan 21, 2020, at 16:54, Viktor Dukhovni wrote:
> There's no need to exclude valid use-cases. The refined proposal
> is rather non-invasive, and handles this case cost-effectively
> on clients that re-use tickets (and don't use early-data, ...).
I don't find your arguments persuasive. Thi
On Thu, Feb 13, 2020, at 06:26, Douglas Stebila wrote:
> We would like to request the working group adopt
> draft-stebila-tls-hybrid-design, "Hybrid key exchange in TLS 1.3", as
> a working group item. We have updated the draft based on feedback
> we've received over the past few months, including
On Thu, Feb 13, 2020, at 08:44, Blumenthal, Uri - 0553 - MITLL wrote:
> You saw the key sizes that the NIST PQC candidates require? How would
> you suggest dealing with them unless there's support for larger public
> keys?
Only a few of them. Some are OK, but the number is few, I agree. I have
On Thu, Feb 13, 2020, at 10:01, Carrick Bartle wrote:
> I'm brand new to the IETF, so please forgive me if I'm totally off base
> here, but my understanding is that Informational RFCs are explicitly
> not recommendations (let alone mandates)?
This would of course be information, but my comment w
On Fri, Feb 14, 2020, at 06:00, Salz, Rich wrote:
> >I think the draft would be ok to adopt if we don't finish
> it until the outcome from the NIST competition is known.
> Otherwise I would be against adoption.
>
> I think I agree with this, but am not sure. Can we have this on the
On Tue, Mar 3, 2020, at 18:10, Paul Yang wrote:
> In such a case, it's possible to utilize delegated credentials to
> subsititue X.509 certificate in the 'inner' service mesh communication,
> but we found something is missing in current structure of the
> definition of the 'Credential'. In ser
Option A please. Multiple state machines.
It's unavoidable in any case. If you generate your own post-handshake message
and then have to respond to post-handshake authentication, there will be two
concurrent exchanges. We already require acknowledgment for both request and
response in a two-
I have a third option (mu?) which differs from previous proposals.
I have been somewhat convinced by the arguments about how resumption is
different and can tolerate the complexity of the additional counter. That is,
endpoints can request replacement of consumed tickets (1 for when a connection
401 - 500 of 893 matches
Mail list logo
