Thanks to some good work from Felix Günther, Marc Fischlin, Christian Janson,
and Kenny Paterson we now have a new result to share about the integrity limits
in QUIC.
There is a long write-up in https://github.com/quicwg/base-drafts/issues/3619,
the conclusion of which is that endpoints need to
On Mon, Apr 27, 2020, at 17:06, Hannes Tschofenig wrote:
> (*): Even if we optimize the CID away with cTLS the question about the
> security implications will surface again.
I think that cTLS is the answer to the size issue. But there, the rule tends
to be that removing from the wire doesn't a
On Sat, Apr 25, 2020, at 01:56, chris - wrote:
> However, the formal
> models of [1,2] assume reliable transport (i.e., TCP): failure to
> deliver packets in order is deemed an attack. Therefore, the
> definitions would need to be changed in order to account for the case
> of DTLS. (I'm not sur
Hi Hannes,
Let me see if I can clarify then :)
On Fri, Apr 24, 2020, at 18:31, Hannes Tschofenig wrote:
> > Say that a connection spans two network paths. CID A is used on path
> A; CID B is used on path B.
> I guess you are considering a scenario where a device, of the lifetime
> of the commu
What makes this case interesting is the non-machine time that might exist
between receiving CertificateRequest and sending Certificate.
In most of the exchanges, we expect there to be an answer that is immediately
available, so that the implicit ACK works. Here we have to recognize that ACK
mi
On Thu, Apr 23, 2020, at 18:11, Hanno Becker wrote:
> You criticize that an implicit CID which is still included in the AAD
> requires state on the receiver when processing multiple records within
> a single datagram, which is true. I'm saying that the same holds for
> the PR 143 which adds the
On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote:
> OK but we would expect the peer to process CID-less records if they are
> coalesced?
I guess so. If we allowed them to drop them, then we're close to saying MUST
NOT omit.
On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote:
> > But Hanno'
On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote:
> On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson wrote:
> > I prefer Ekr's solution, but I would go with that being a recommendation
> > (SHOULD) as opposed to a requirement (MUST).
>
> Can you clarify where you
On Wed, Apr 22, 2020, at 05:31, Yoav Nir wrote:
> > Third, more substantially, and invalidating the above, I don't think that
> > we should make flags introduce a new style of negotiation just because it
> > can. I would strongly prefer that this function as close as possible to
> > "empty Clie
I prefer Ekr's solution, but I would go with that being a recommendation
(SHOULD) as opposed to a requirement (MUST).
I was initially inclined toward doing nothing at all, but there is an attack of
sorts that is worth avoiding here.
Say that a connection spans two network paths. CID A is used
I made a few comments on the pull request, but they are minor. Let's do this.
On Wed, Apr 8, 2020, at 03:07, Sean Turner wrote:
> hi TLS WG,
>
> During the consensus call to determine whether ticket reuse use cases
> should be supported we did not see consensus to add that text, but we
> did s
I like this work, but I don't believe this to be ready yet.
S1
None of the current proposed extensions are such that the server
indicates support without the client first indicating support. So as
not to preclude future extensions that are so defined, this
specification allows the cli
Hi Hanno,
I think that you are assuming a lot about how the loss recovery part of the
sender is operating here.
If you receive ACK { 1, 3 }, then it might be reasonable to assume that 2 got
lost, but it seems to me that assuming anything about 4 is premature.
As you say, delaying ACKs is a goo
On Mon, Mar 23, 2020, at 03:54, Christopher Wood wrote:
> I propose we remove this requirement and add an explicit signal in SH
> that says whether or not ECHO was negotiated.
Here's a spitball signaling option that might not stick out:
Client sends (in the ECHO) a random value, N, with 32(?) <
On Wed, Mar 11, 2020, at 10:45, Benjamin Kaduk wrote:
> For purposes of increased visibility, I note that
> draft-ietf-ntp-using-nts-for-ntp is making an ALPIN ID registration and
> requesting to be marked as "Recommended" in the registry. The
> high-level summary of the NTS-KE protocol is to do a
On Tue, Mar 10, 2020, at 14:17, Watson Ladd wrote:
> One thing I noticed from my reading is there is no gain from knowing
> an extension will be present if one doesn't also know the value.
That is only true if the extension has a value. (See also flags)
> I could imagine SNI being very useful to
On Fri, Mar 6, 2020, at 12:28, Benjamin Kaduk wrote:
> Other than this bit about giving resumption_count of zero additional
> semantics than "I am requesting zero tickets if resumption succeeds", I
> actually think this proposal is quite good. The comments I left on PR
> 18 are effectively advocat
On Fri, Mar 6, 2020, at 07:55, Nico Williams wrote:
> unless both parties agree. It takes two to agree.
RFC 8446 says:
Clients SHOULD NOT reuse a ticket for multiple connections. Reuse of
a ticket allows passive observers to correlate different connections.
Are you arguing that there
On Thu, Mar 5, 2020, at 11:42, Viktor Dukhovni wrote:
> But not in a way that forecloses interoperability with a client that
> tries to negotiate reuse via a to-be specified mechanism in a later
> draft. We can stop short of specifying/supporting/... reuse, but
> deliberately precluding adding it
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
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-
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
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 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 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 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 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, 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
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 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
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 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: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
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 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
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
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
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
> 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
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
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
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
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
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 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 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
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 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
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
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
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
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 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 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
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 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
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 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
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 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
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
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
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
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
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
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 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
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 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.
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
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
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
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
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
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
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 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
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
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
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-
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
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
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
>
> "Example Handshake Traces for TLS 1.3".
> >
> > --
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5720
> >
> > ------
> > Type: Techni
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
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
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
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
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
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
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
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
> 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?
&
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
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
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
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 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
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 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
201 - 300 of 859 matches
Mail list logo
