On 14 July 2015 at 12:30, Andrei Popov wrote:
> The downside is of course that the attacker can easily distinguish
> opportunistic clients from server-authenticating ones. Is this a concern for
> the opportunistic TLS community?
I raised the concern about this previously. Opportunistic MitM
ha
On 14 July 2015 at 13:08, Viktor Dukhovni wrote:
> Yes, and informs the server that the client is skipping authentication,
> which is often useful information on the server end.
The problem here is that the server isn't the only recipient of that signal.
_
On 15 July 2015 at 15:18, Blumenthal, Uri - 0553 - MITLL
wrote:
> I'd rather not lose the 571 curve.
I'd like to understand why you think it's worth keeping.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 21 July 2015 at 04:04, Eric Rescorla wrote:
> - The client indicates configuration ID and cryptographic configuration,
> including the cipher suites and cryptographic extensions. This
> MUST replicate the server's selection from a previous handshake
That's not going to work if there was n
On 21 July 2015 at 04:12, Eric Rescorla wrote:
>
> Yes, that's an issue. Not entirely sure what to do about other than
> have the server provide its negotiation preferences out of band
> in that case.
I think that we could handle that at the point we define an
out-of-band configuration priming me
On 21 July 2015 at 06:08, Ilari Liusvaara wrote:
> Well, if it is about supported ciphers, there could be multiple, and
> the proposal has slot for only one.
The proposal is for what the client selects and uses for its first flight.
___
TLS mailing li
On 21 July 2015 at 08:17, Ilari Liusvaara wrote:
>> > *deadlock*.
>>
>>
>> Is this the case where the server is accepting 0-RTT or rejecting it?
>
> Apparently, only for accepting case.
>
> (If the server rejects, it can reply immediately, avoiding this
> deadlock).
I don't think that this is a
Is table 1 correct?
+---+-++
| Symmetric | ECC | DH/DSA/RSA |
+---+-++
| 80| 163 |1024|
|112| 233 |2048|
I have never understood why 4492 doesn't claim forward secrecy for
ECDH_anon suites. Can someone explain why this doesn't have an 'E'?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 22 July 2015 at 01:50, Kyle Rose wrote:
> I'd like to see the bits of the cipher suite associated entirely with
> ephemeral data tied together roughly by security margin
I've seen this argument several times, but there are reasons why you
might want a non-homogenous strength profile.
The argu
On 22 July 2015 at 02:20, Yoav Nir wrote:
> They both provide forward secrecy.
The draft specifically excludes ECDH_anon from the following
statement, implying otherwise:
The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
secrecy.
It might be a good idea to revise that.
On 22 July 2015 at 02:29, Yoav Nir wrote:
> PR at
> https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml
> ?
https://github.com/tlswg/rfc4492bis/pull/6
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/t
On 22 July 2015 at 19:07, Dave Garrett wrote:
> Could the cipher suite names be officially changed to add the 'E' to them?
> It'd make things simpler to be consistent.
I'd be OK with that. I didn't do it in the PR, but would be happy to
make a new one.
_
On 22 July 2015 at 19:12, Yoav Nir wrote:
> I’d like to hear from the chairs if it’s OK to rename stuff in the IANA
> registry.
>
> That has some implications for implementations that use these names.
>
> Not to mention that the same issue applies to DH(E)_anon
I believe that renaming entries in
Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209
The first expands the ways in which a server can identify
certificates. This is fine. I do wonder whether we can remove
CertificateType entirely for TLS 1.3 though (that can be done
separately).
The second is worrisome.
On 25 July 2015 at 16:13, Eric Rescorla wrote:
> The only question is whether it's legal to concurrently offer RC4 with TLS
> 1.3
> for purposes of using RC4 with TLS 1.2 (just as you can offer AES-CBC
> even though TLS 1.3 does not support it.) I am trying to work through this
> myself, as the in
On 25 July 2015 at 17:48, Salz, Rich wrote:
> "we" meaning browsers. "we" not being everyone who will use TLS 1.3
>
> Ekr has pointed out a problem; if you connect with a protocol range and
> proffer RC4, can we do anything about it except point out multiple times that
> 1.3 servers MUST NOT ac
On 3 August 2015 at 17:21, Andrei Popov wrote:
>> use CertificateRequest within the handshake, and the new content type
>> outside of it
>
> Would the client then also use this new content type for Certificate and
> CertificateVerify messages (when these are sent after the handshake is
> comple
On 4 August 2015 at 05:37, Nikos Mavrogiannopoulos wrote:
> Is there any support for
> switching these ciphersuites to draft-TLS 1.3 nonce mechanism even for
> TLS 1.2? The alternative is to use the TLS 1.2 mechanism with the
> redundant bytes redacted as the draft is now [1].
Personally, I would
On 4 August 2015 at 10:24, Wan-Teh Chang wrote:
> The consistency you want to see seems to be
> consistency with the AES GCM cipher suites, rather than with TLS 1.2.
Yes, this is correct.
RFC 5288:
struct {
opaque salt[4];
opaque nonce_explicit[8];
On 5 August 2015 at 11:13, Wan-Teh Chang wrote:
> Then, define the ChaChaNonce struct as described in the draft-TLS 1.3.
>
>struct {
>opaque nonce[12];
>} ChaChaNonce;
>
> 1. The 64-bit record sequence number is padded to the left with
> zeroes to 96 bits
I've read this draft before, but this is considerably different to
what I read, and I haven't been following the discussion, so consider
this as a review with fresh eyes.
First the high points. I think that this is useful, the right scope,
and reasonably well formulated. I have a couple of minor
Before people get too far down that road, here:
https://tools.ietf.org/html/draft-thomson-httpbis-cant-01
https://tools.ietf.org/html/draft-thomson-tls-care-00
Andrei has made it clear that these do not work for his use case (I'm
not yet convinced that they are inadequate, but I am convinced of t
On 11 August 2015 at 11:25, Karthikeyan Bhargavan
wrote:
> No, a regular ECDSA certificate would do.
> That is, the attack would work as long as
> - a client has an ECDSA certificate, and
> - it enables any static TLS_ECDH_* cipher suite, and
> - its ECDSA private key has been stolen (or chosen) b
On 11 August 2015 at 12:05, Ilari Liusvaara wrote:
>> I don't see how that would work. A client that understands the cert
>> to be ECDSA won't pair the key with the server's ECDH share, they will
>> sign the session transcript with it.
>
> a) ECDSA certs are usable for ECDH (modulo KeyUsage) beca
On 11 August 2015 at 16:38, Clemens Hlauschek
wrote:
>> Maybe I should have been clearer. The certificate might not include a
>> (strong) signal that allows the client to distinguish between ECDSA
>> and fixed ECDH, but the client might be configured with that
>> knowledge.
>
> There is no differ
On 17 August 2015 at 05:02, Ilari Liusvaara wrote:
>
> Actually, I think both should be 256 (256-byte expansion from AEAD
> is already quite much).
Pull request or it didn't happen ;)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/list
trivial, some not. Do you
> expect 15 PRs?
>
> Thanks,
> Yaron
>
> On 08/17/2015 10:37 AM, Martin Thomson wrote:
>
>> On 17 August 2015 at 05:02, Ilari Liusvaara
>> wrote:
>>
>>>
>>> Actually, I think both should be 256 (256-byte expans
Hi Hannes,
On 24 August 2015 at 09:38, Hannes Tschofenig wrote:
>> I'd like to see the document explicitly note that msg_type and length
>> from the handshake message are not covered by the hash. The
>> description of what is covered is a little too terse (and badly
>> formatted).
>
> There are
On 24 August 2015 at 16:30, Stephen Farrell wrote:
>
>
> On 25/08/15 00:22, Tom Ritter wrote:
>> it would be _amazing_ if browser vendors enabled
>> browser extension authors to choose the padding strategy for
>> individual origins. Then we can crowdsource the effort.
>
> Excellent idea!
I belie
On 24 August 2015 at 21:04, Dave Garrett wrote:
> uint16 length = TLSPlaintext.length;
You can't recover the plaintext without knowing how long it is. This
part at a minimum needs to be in the clear. At which point you need
it to be based on TLSCiphertext.length
___
On Aug 25, 2015 7:26 AM, "Kyle Rose" wrote:
>
> >> uint16 length = TLSPlaintext.length;
> >
> > You can't recover the plaintext without knowing how long it is. This
> > part at a minimum needs to be in the clear. At which point you need
> > it to be based on TLSCiphertext.length
>
> Is t
On Aug 25, 2015 7:42 AM, "Viktor Dukhovni" wrote:
> SSH now has ciphersuites where the payload length is encrypted,
> IIRC via a key that is different from the payload key.
Yeah, I'm not that enthusiastic about that feature, but if you want more
complexity, it is possible. The authentication prope
On 26 August 2015 at 14:11, Joseph Salowey wrote:
> "Because certificate validation requires that trust anchors be distributed
> independently, a self-signed certificate that specifies a trust anchor MAY
> be omitted from the chain, provided that supported peers are known to
> possess any omitted
I've been looking at the latest TLS 1.3 spec and there are a lot of
MUSTs that are completely toothless. To pick on a recent changeset:
> The signature algorithm and hash algorithm MUST be a pair offered in the
"signature_algorithms" extension (see {{signature-algorithms}}).
> All implementation
e:
>
>> On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote:
>> > I've been looking at the latest TLS 1.3 spec and there are a lot of
>> > MUSTs that are completely toothless. To pick on a recent changeset:
>> >
>> >
The statement I'd like to see is something like this...
An endpoint that receives an illegal combination of "things" MAY choose to
treat that as a fatal error.
In this case, that means that if you include an ECDHE suite without an
ECDHE named_group, don't expect to have the connection succeed.
On
This seems fine to me, though I'll note that 7250 only really saves
you space when it comes down to it. You can wrap your raw public key
in a certificate, just like we do in WebRTC, and then you don't need
7250 support in your library. Noting you can only do any of these
variations in a context w
On 28 August 2015 at 11:36, Eric Rescorla wrote:
> How does anon-DH have different privacy properties than doing
> RFC 7250 with a fresh signing key for each connection?
Or what we do in WebRTC, which uses a certificate that has no good
information in it?
On 28 August 2015 at 11:33, Viktor Dukhovni wrote:
> On the other hand, it allows servers to detect that a
> client is not planning to authenticate the server, which has forensic
> value, and can be used to grant appropriately restricted access.
I think that these are potentially useful properti
en the client and the server exchange their hello messages.
>
> Ciao
> Hannes
>
> PS: Additing extra text with information about what is included in the
> hash will be added to make sure that implementers compute the hash over
> the correct fields of the message.
>
&g
On 12 September 2015 at 13:49, Eric Rescorla wrote:
> "Nobody must ever be required to send an alert. Any requirement for sending
> an alert should be SHOULD, at most."
This was a point of debate for HTTP/2 as well. The conclusion there
was that you had to be prepared to have the connection disa
This seems like the right set of options...
On 12 September 2015 at 14:26, Eric Rescorla wrote:
> 1. Require termination and say nothing else
I think the mere existence of alerts suggests that this isn't really a
good option.
> 2. Require termination and suggest an alert.
> 3. Require terminati
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
On 15 September 2015 at 20:12, Karthikeyan Bhargavan
wrote:
> I assume the client hello extension still has the certificate digest, yes?
> This means that the analysis probably relied on agreement of the certificate
> hash from the client hello.
This was only in the 1.3 context, and the certific
On 16 September 2015 at 08:02, Peter Gutmann wrote:
>>HTTP-2 did this kind of thing, and IIRC are the first to do so.
>
> Some PKI standards have done it too, but mostly because the base standard was
> such a mess that you needed a profile just to sort out what needed to be
> implemented for anyth
On Sep 21, 2015 7:02 AM, "Ilari Liusvaara"
wrote:
> Under such assumption, even dynamic reauth in HTTP/1.1 is unsafe. If
> one additionally assumes causality, dynamic reauth in non-pipelined
> HTTP/1.1 may be safe, but dynamic reauth in HTTP/2 (or HTTP/1.1 with
> pipelining) is still unsafe.
What
On 4 October 2015 at 21:06, Eric Rescorla wrote:
>
> Yes, if the attacker can provide their own data, it makes matters worse,
> but as the reference I provided indicated, there are potential security
> issues even if the attacker is not able to do so, provided that the data
> is sufficiently redun
On 16 October 2015 at 12:22, Brian Smith wrote:
> Why only protect TLS 1.3 from such a downgrade? I think it is worthwhile to
> protect TLS 1.2 from the downgrade too, in a similar way. Or, is there
> something specific about TLS 1.3 that makes the downgrade worse?
Given that we can't expect TLS
On 16 October 2015 at 13:39, Brian Smith wrote:
> That would be especially true for an implementation that does False Start
> for TLS 1.2.
I don't see how false start plays into this. We could have clients
reject false start if they see this sentinel value. But don't we want
to just treat this
On 17 October 2015 at 12:03, Eric Rescorla wrote:
>> Just a single
>> fixed patter signalling ">= 1.3" would then suffice.
>
>
> If you wanted to cover 1.2 -> 1.1, then you would want this.
The observation is still valuable in the sense that prohibiting values
> 1.3 would reduce the likelihood of
On 19 October 2015 at 08:08, Eric Rescorla wrote:
> overloading the time field
> lowers the risk of false positives because we can choose a sentinel that
> will never
> collide with a conformant TLS 1.2 ServerHello. By contrast, a sentinel in
> the
> randomly generated portion always has a 2^{-n}
On 19 October 2015 at 09:28, Eric Rescorla wrote:
> 1. Don't MAC the version at all.
> 2. MAC the negotiated version (which should be clear at
> this point).
3. Nothing
The version is implicit in the key derivation (yeah, there are lots of
rounds of HMAC between, but it's ther
On 19 October 2015 at 11:12, Eric Rescorla wrote:
>
>
> On Mon, Oct 19, 2015 at 11:06 AM, Martin Thomson
> wrote:
>>
>> On 19 October 2015 at 09:28, Eric Rescorla wrote:
>> > 1. Don't MAC the version at all.
>> > 2. MAC t
On 19 October 2015 at 11:17, Eric Rescorla wrote:
> Yeah, I think that's riding the nonce far too hard.
On what basis? Any change in the nonce will cause the record
decryption to fail. That's the property we're looking for here, isn't
it?
___
TLS mai
This is an exploration of what it might take to bootstrap 0RTT without
a prior TLS connection.
https://tools.ietf.org/html/draft-thomson-tls-offline-config-00
There are two important lessons I've learned from this:
1. authentication is important (and hard to get right)
2. TLS implicitly inclu
The current draft permits the use of SHA-1 in the certificate chain,
which gives SHA-1 a free pass indefinitely. Since we expressly forbid
the use of SHA-1 for signing in TLS itself, we can just permit clients
to include it in "signature_algorithms" and use that to determine
whether SHA-1 is accept
On 21 October 2015 at 12:29, Ilari Liusvaara wrote:
> Bit crazy idea: Have vector of causes handshake went wrong
> (e.g. required share missing, cookie required). Then the
> client verifies that that:
> - There is at least one cause
> - All causes are known (can't retry with unknown error)
> - All
On 21 October 2015 at 12:56, Viktor Dukhovni wrote:
> Each peer MUST try to send a chain that matches an advertised
> signature algorithm if it has a choice of chains, but otherwise
> MUST send whatever it has.
Do, or do not. There is no try.
It's not like any of this is ambiguous in any way.
On 21 October 2015 at 13:43, wrote:
> RFC 7685
>
> Title: A Transport Layer Security (TLS)
> ClientHello Padding Extension
That took longer than I expected. Nice work.
___
TLS mailing list
TLS@ietf.org
https:/
I'm not sure that I follow. Are all the records in 0RTT going to use
a content of handshake, or just the
Certificate/CertificateVerify/Finished? I assume that you meant just
the handshake messages, in which case yes, this is OK. It does make
identification of what goes into the handshake hash ma
On 21 October 2015 at 15:52, Eric Rescorla wrote:
> I don't think this will make the implementation that hard :)
Yeah, you have to actually pay attention to the early_data extension.
That might not be a bad thing in the end.
___
TLS mailing list
TLS@ie
2b. encrypted extensions over ServerHello
If we make this like signature_algorithms, then I think that I prefer
option 1. I don't like that signature_algorithms is built that way, I
think that it's repulsive, but there are some advantages to doing it
that way, especially if we accept the fact tha
On 22 October 2015 at 09:19, Benjamin Kaduk wrote:
>
> % a certificate that specifies a trust anchor MAY be omitted from the chain
>
> The client cannot decide that the signature on the root cert the server
> sent is bad, if the server does not send the root cert.
Yes, that was my thinking.
I ex
On 22 October 2015 at 10:11, Andrei Popov wrote:
> Then my argument would be: why send extra bytes in each ServerHello when TLS
> client auth is not used most of the time? In this case, CertificateRequest
> seems to be a better place.
I think that this is the best argument for CertificateRequest.
On 22 October 2015 at 11:17, Watson Ladd wrote:
> Ideally, yes. Applications never cared about what was happening, but wanted
> a "secure this channel" magic call.
I think that this is conditionally true. If you are using TLS 1.2
with reasonably modern practices, then getting TLS 1.3 should be
It's not entirely clear what you are asking for here, but have you
looked at the key derivation in TLS 1.3?
On 16 October 2015 at 01:27, Phillip Hallam-Baker wrote:
>
> I strongly oppose any new crypto that does not include a fix for the
> ephemeral keygen.
>
> The reason logjam is possible is th
On 3 November 2015 at 08:02, Brian Smith wrote:
>> The major change in this version is that the nonce is constructed
>> using the scheme that's currently in TLS 1.3.
>
>
> Would it be possible to do something similar for the additional data, so
> that there is no additional data in TLS 1.2, just l
On 4 November 2015 at 11:16, Yoav Nir wrote:
> Can’t we just say that all previous uses of tis-unique will instead get an
> exporter generated with the label “tis-unique” ?
That was my thought here: redefine what it means to generate tls-unique.
That's part of why I asked about the size. We s
What is wrong with getTlsUnique2() or getBetterTlsUnique() ? It's not
a drop-in replacement, but it indicates that the app understands the
change. Otherwise, we might have to signal this in TLS 1.2 proper.
1.3 can just be fixed.
On 4 November 2015 at 15:42, Alexey Melnikov wrote:
> On 04/11/201
Nitpicks accepted, pull requests preferred:
https://github.com/tlswg/tls13-spec/pull/317
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
This is good.
I have an editorial comment: can someone please go through and
reconcile all the use of bits and bytes throughout. It actually seems
like someone did a coin flip on every occurrence to decide which one
to use.
___
TLS mailing list
TLS@iet
On 5 November 2015 at 15:53, Dave Garrett wrote:
> "Trusted self-signatures SHOULD be validated before adding to a trust store
> and SHOULD NOT be re-checked at runtime." But we're getting slightly out of
> scope here, which is why I'm thinking that elaborating on this topic exactly
> as sugges
I have to ask why the continued insistence on calling the thing that
forms part of the nonce an "IV". I find it to be misleading.
Also, it might be worth noting that the string "early data key
expansion, server write " is never needed.
On 16 November 2015 at 17:25, Eric Rescorla wrote:
> https:
On 16 November 2015 at 19:52, Eric Rescorla wrote:
>> I have to ask why the continued insistence on calling the thing that
>> forms part of the nonce an "IV". I find it to be misleading.
>
>
> This is the historical terminology that TLS has used.
It was actually accurate when we were using CBC m
>From the issue:
<<<
As far as I can see, the only timestamp used is expiration_date in the
ServerConfiguration (apart from X.509 validity checks which require
synchronised clocks). This is defined as seconds since UNIX epoch, and
will overflow sooner than later. Maybe either use a relative amount
On 23 November 2015 at 10:56, Ilari Liusvaara wrote:
> I got the idea of using 32-bit sequence number arithmetic there too
> (window is -2G to 2G seconds around current time). I don't suppose
> any key will need to have TTL of over ~68 years...
I did too, but decoded that 2^64 is just easier.
__
On 23 November 2015 at 12:56, Yoav Nir wrote:
> It’s been suggested that as long as the CFRG signature curves document is not
> finalized, we should wait with the eddsa_* ones. I don’t believe so. Anything
> in any draft is subject to change up to the time it’s published [...]
In your opinion,
On 23 November 2015 at 14:08, Ilari Liusvaara wrote:
> Also, the prehashes might not be the same for Ed25519ph and Ed448ph,
> plus I consider interfaces that let one use this dangerous (IUF
> signing is dangerous!).
That suggests that the construction of CertificateVerify is dangerous
in the sam
On 26 November 2015 at 18:38, Xuelei Fan wrote:
> What's the consideration to place selected_group out of the extensions filed
> in HelloRetryRequest?
An extension would work, except that I believe that extensions in
HelloRetryRequest are going to carry somewhat different semantics to
those in ot
On 1 December 2015 at 08:22, Bryan A Ford wrote:
> The 2-byte length field in each record's header no longer indicates
> the length of the *current* record but instead indicates the length of
> the *next* record.
Ensuring that you know the length of the *next* record is difficult
and could dramat
There are a lot of inaccuracies in that presentation, so I wouldn't
pin too much on it.
In any case, before we all get too excited about this, there are some
solutions, I've seen a write-up of one of them, but it was a little
hard to follow first time around. Some of the things that are
described
On 8 December 2015 at 14:49, RFC Errata System
wrote:
> TLS 1.1 was first drafted in 2002, but not published until 2006. Similarly,
> TLS 1.2 was drafted in 2006, but not published until 2008.
The date on the documents are indeed wrong.
I recommend holding for document update.
___
I think that the best way to deal with the status_request_v2 extension
is to make it a proper part of the TLS 1.3 messages, probably
Certificate or CertificateVerify. This is a fairly heavily important
extension.
On 12 December 2015 at 05:52, Ilari Liusvaara wrote:
> When looking at stuff some m
On 16 December 2015 at 08:14, Eric Rescorla wrote:
>
> I wanted to get people's opinions on whether that's actually what we want
> or whether we should (as is my instinct) allow people to use ChaCha
> for longer periods.
Whatever the actual limits are, I think that implementatios should be
encou
On 16 December 2015 at 14:01, Brian Smith wrote:
> Martin Thomson wrote:
> Why?
If there were a stupidly high limit, then I would argue for no
rekeying facility.
But the numbers Watson ran suggested that GCM starts to look shaky at
2^36. That's too low for some applications.
For
On 16 December 2015 at 14:57, Dave Garrett wrote:
> In fact, if we're OK with setting this rather low threshold, then we could
> even get rid of the rekey signal entirely and just have an automatic rekey
> after every 4GiB for all ciphers. That'd be one less complexity to deal with.
> Rekeys wo
On 16 December 2015 at 15:08, Dave Garrett wrote:
> We could just make the threshold a configurable parameter, with
> default/maximum at 2^32 bytes. Each endpoint could just provide its threshold
> in a new extension. Both get to specify what they want and it could be
> lowered arbitrarily for
So the actual impact here is that an attacker who has compromised a
key can introduce a gap. Aren't there other options available to such
an attacker? Scarier options?
On 18 December 2015 at 07:01, Cedric Fournet wrote:
>
> We propose to revert this change (that is, to reset the sequence
> numb
On 22 December 2015 at 13:25, Christian Huitema wrote:
>> Unless I'm confused (which is possible given the time of night),
>> the intention, as you say, is to separate out the 0-RTT handshake
>> messages i.e., (cert, cert verify, finished) from the 1-RTT computations.
>
> OK. That does not simplif
On 23 December 2015 at 08:51, Watson Ladd wrote:
> Textbook DH does not ensure contributory behavior. Applications don't
> implement the required checks for poorly designed protocols. If we insert
> checks, applications which fail to make those checks will be vulnerable,
> while fixing protocols c
On 23 December 2015 at 10:23, Brian Smith wrote:
> It may be the case that TLS requires contributory behavior and point
> validation is still unnecessary. Or, it may be the case that TLS doesn't
> really require contributory behavior (though, it seems obvious to me that it
> does, at least for TLS
On 23 December 2015 at 11:09, Brian Smith wrote:
> If an implementation only implements ECDHE cipher suites then implementing
> the session hash extension is not necessary, according to RFC 7627. I
It doesn't really say that as far as I can see, though I guess that
you could infer that from this
On 30 December 2015 at 22:16, Ilari Liusvaara wrote:
>> Would it make sense to have session hash as a requirement in TLS
>> 1.2 when you want to use Curve25519?
>
> I don't think that is reasonable.
I think that is entirely reasonable. TLS 1.2 relies on contributory
behaviour. 25519 doesn't pro
On 31 December 2015 at 17:54, Ilari Liusvaara wrote:
> Zero checks can already be unit-tested/interop-tested just as well.
What ekr said applies, but also this:
Yes, you can test that a given implementation does the right checks,
but you won't be checking during normal operation. If you requir
On 5 January 2016 at 05:03, Eric Rescorla wrote:
> Ask and ye shall receive: http://tlswg.github.io/tls13-spec/#digital-signing
>
> "Following that padding is a context string used to disambiguate signatures
> for different purposes.
> The context string will be specified whenever a digitally-sign
On 12 January 2016 at 05:30, Kurt Roeckx wrote:
> After the SLOTH paper, we should think about starting to deprecate
> TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS
> 1.2.
Let's be clear about this: TLS 1.0 represents far too high a
proportion of our usage to remove it at th
This is in part why I created: https://github.com/tlswg/tls13-spec/pull/402
My understanding is that the server is able to send any data that does
not depend on client authentication at t=0.5 and any data that depends
on client authentication at either t=0.5 if it successfully consumes
the client
On 27 January 2016 at 12:58, David Benjamin wrote:
> If the server needs to send a CertificateRequest (i.e. the client
> mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a
> 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all but
> useless because the first
On 27 January 2016 at 13:11, Eric Rescorla wrote:
> Well, I think we're generally encouraging people to have to explicitly
> enable 0-RTT.
I think that the key point was that you would have to explicitly
enable 0-RTT AND that also meant a commitment not to choke on 0-RTT
data for at least as lon
1 - 100 of 854 matches
Mail list logo
