Hello,
Truncating 20-byte hash to one byte is NOT a good idea since this would result
in ONLY 255 (2^8 - 1) unique certificates to be identified. This will result in
many certificates sharing the same 1-byte hash ie, 2^160 certificates are mapped
to the 255 1-byte hash. This is NOT desirable and c
at it would be equally secure if you removed all mention of
> >>>> certificates from the protocol. And that makes me nervous, because
> >>>> I'm fairly sure that Karthik will tell me that I'm wrong very shortly;
> >>>> since we've put in a lot of work to cover key fields in the handshake
> >>>>
On 09/12/2015 10:49 PM, Eric Rescorla wrote:
> Issue: https://github.com/tlswg/tls13-spec/issues/242
>
> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
>
> "Nobody must ever be *required* to send an alert. Any requirement for
> sending an alert should be SHOULD, at most."
U
> Using full-duplex TCP, it's difficult to get a fatal alert over the wire if
> you want
> to close the connection immediately:
Yes.
But so what. )
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Tue, Sep 15, 2015 at 03:18:30PM +0200, Florian Weimer wrote:
> On 09/12/2015 10:49 PM, Eric Rescorla wrote:
> > Issue: https://github.com/tlswg/tls13-spec/issues/242
> >
> > In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
> >
> > "Nobody must ever be *required* to send an
Perhaps we can simplify the protocol by pulling client auth out of the
handshake as follows:
1. CertificateRequest, client Certificate, CertificateVerify and
NewSessionTicket messages use a new content type distinct from "handshake".
2. The client can send Certificate and CertificateVerify at an
Hannes,
Go ahead and post the -20 version so we can get this ball rolling.
spt
On Aug 24, 2015, at 09:38, Hannes Tschofenig wrote:
> Hi Martin,
>
> thanks for your review.
>
> On 08/06/2015 10:33 PM, Martin Thomson wrote:
>> I've read this draft before, but this is considerably different to
Sorry it's taken me so long to respond, but I'm not convinced that it's not
necessary
to have a secure digest here. Do you have a security analysis that
demonstrates
that that's the case?
-Ekr
On Thu, Sep 10, 2015 at 7:59 AM, Martin Thomson
wrote:
> Hi Hannes,
>
> I've followed a similar chain
I looks like we have consensus to move forward with this PR (PSS), please
apply the change. I think Russ's suggestion improves the text.
Thanks,
Joe
On Thu, Sep 10, 2015 at 1:18 PM, Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/pull/239
>
> Based on the WG discussion, I've create
If I recall correctly we’ve waffled on this a couple of times now; the draft
has gone from requiring SHA-1 to FNV [0] back to SHA-1 and now I think it’s on
SHA-256. The switch away from FNV was primarily because it seemed odd to
include a new algorithm for non-cryptographic purposes [1], i.e. j
> How many Certificate+CertificateVerify messages would a client be permitted
> to send. 1? N?
I don't see a good reason to restrict to 1, although in many cases it would
probably suffice.
> If the answer to the above is N, does the client's
> Certificate+CertificateVerify somehow identify the
In case you’re planning on attending the f2f meeting next week please fill out
the doodle poll (http://doodle.com/ei6px58ip59gr85y) to ensure we’ve got a
badge to get you into the building. See you next week!
spt
On Sep 02, 2015, at 19:39, Sean Turner wrote:
> All,
>
> Andrei has graciously
On 15 September 2015 at 15:03, Andrei Popov wrote:
>> That is, how does the server identify whether this is unilateral or in
>> response to its own request?
>
> The model I'm thinking of is where the server receives a request from the
> client, determines that the request requires authentication
> I'm concerned that this produces an indeterminate state on the server.
> What if that Certificate doesn't conform to the request in some way: was the
> Certificate just a unilateral offer that was sent before the client received
> the CertificateRequest, is the client unable to understand the
> The client is now uncertain about whether the server has remembered their
> certificate. That's bad if there are actions that might be denied to the
> client in the absence of the certificate.
But the server will send a CertificateRequest in this case and the client will
have a chance to aut
There has been some discussion to remove anonymous DH as described in
https://www.ietf.org/mail-archive/web/tls/current/msg17481.html. I think
ekr's message sums up the pros and cons well. I don't think we have
consensus on this issue yet. Please respond on this message by Monday,
September 21,
On 15 September 2015 at 20:42, Tony Arcieri wrote:
> +1 for removing anonymous DH
+1.
Even for the anonymous use cases I like having a long-term key around
for people to optionally remember. (I realize we're not requiring
that.)
-tom
___
TLS mailing
> Sam just ran the analysis. The TLS 1.3 proofs they have work without
> Certificate in the transcript, which is equivalent to a zero-bit
> truncated hash.
I assume the client hello extension still has the certificate digest, yes?
This means that the analysis probably relied on agreement of the c
18 matches
Mail list logo
